Selectel разобрал установку Jenkins на облачном сервере: от ресурсов до пайплайна

Ручная сборка и деплой перестают работать там, где проект растёт быстрее команды. Каждое изменение в кодовой базе тянет за собой одни и те же шаги: собрать, прогнать тесты, выкатить. Чем их больше, тем выше шанс ошибки. Фронтенд-разработчик Selectel Завур выложил на Хабре руководство, как закрыть эту проблему через Jenkins на облачном виртуальном сервере: от выбора ресурсов до работающего пайплайна.

Материал вышел в корпоративном блоге Selectel, и сервер в нём заказывается в панели этого провайдера. Но сама схема от провайдера почти не зависит. Её можно перенести на любую виртуальную машину с Linux.

Почему Jenkins, а не встроенный CI

У GitHub Actions и GitLab CI есть очевидное преимущество: они живут рядом с репозиторием. Расплата — привязка к платформе. Jenkins устроен иначе. Это отдельный open-source сервер автоматизации, который тянет код из любого Git-репозитория и не интересуется, где он хостится.

У проекта длинная история. Он появился в 2011 году как ответвление Hudson и с тех пор оброс экосистемой из более чем 1800 плагинов. Через них подключаются системы сборки, сканеры кода, уведомления в мессенджеры и облачные API. Для команд со смешанным стеком или закрытым контуром это часто решающий довод.

По описанию автора, Jenkins умеет:

• собирать проекты из любого Git-репозитория;
• запускать автоматические тесты;
• собирать Docker-образы;
• разворачивать приложения на целевых серверах.

Что в руководстве

Статья идёт по порядку, в каком обычно поднимают CI-сервер:

• оценка ресурсов под разные сценарии, от небольшого проекта до нагруженных сборок;
• заказ виртуального сервера в панели Selectel;
• подготовка системы к установке;
• установка и первичная настройка Jenkins;
• простой пайплайн для автоматической сборки приложения.

Разбор ресурсов здесь полезнее, чем кажется. Jenkins написан на Java, и в документации проекта для небольших команд рекомендуют от 4 ГБ оперативной памяти и около 10 ГБ диска. Минимум в 256 МБ годится разве что для эксперимента. Сборки с Docker и тяжёлыми тестами добавляют требования к процессору и диску. Если сэкономить на сервере, пайплайн будет падать с нехваткой памяти в самый неудобный момент.

Где подводные камни

Установка Jenkins занимает считаные минуты. Проблемы начинаются после неё. Современные версии требуют актуальную Java (17 или 21), а веб-интерфейс по умолчанию открывается на порту 8080 без HTTPS. Если оставить так, сервер окажется доступен всем, у кого есть его адрес. Плагины тоже нужно обновлять: именно через них регулярно закрывают уязвимости.

Ещё одна ловушка — хранение конфигурации. Пайплайн, собранный кликами в интерфейсе, невозможно ревьюить и откатывать. Поэтому его лучше описывать в Jenkinsfile и держать в репозитории рядом с кодом.

Что делать с этим на практике

Для команды из нескольких человек такая связка закрывает базовую потребность в CI/CD без лишней инфраструктуры. Порядок действий разумный:

• начните с небольшого сервера и следите за памятью во время сборок;
• закройте доступ к интерфейсу через HTTPS и ограничение по IP или VPN;
• описывайте пайплайн в Jenkinsfile и храните его в Git;
• выносите тяжёлые сборки на отдельные агенты, когда один сервер перестанет справляться.

Материал не про ИИ и не про новый релиз. Это прикладная инструкция, полезная начинающим DevOps-инженерам и фронтендерам, которые хотят перестать деплоить руками. Любой современный ИИ-ассистент для кода всё равно упирается в тот же вопрос: куда и как выкатывать результат. Без автоматической сборки и тестов вся скорость генерации кода быстро уходит в ручную проверку.