Выделенный сервер для Jenkins и GitLab CI/CD

Зачем использовать выделенный сервер для CI/CD?

Рабочие нагрузки непрерывной интеграции и непрерывной доставки требуют значительных ресурсов, поскольку один конвейер может компилировать исходный код, собирать образы контейнеров, запускать тесты, сканировать зависимости, упаковывать артефакты и развёртывать сервисы. Несколько одновременно работающих конвейеров могут занять все потоки CPU, заполнить временное хранилище и создать высокую нагрузку на диски.

Выделенный сервер предоставляет Jenkins или GitLab Runner эксклюзивный доступ к физическим ядрам CPU, оперативной памяти, NVMe-хранилищу и сетевой ёмкости. Это повышает стабильность времени сборки и предотвращает влияние стороннего арендатора на производительность компиляции или тестов. Физический сервер особенно полезен для конвейеров с интенсивным использованием Docker, сборок Android, крупных монорепозиториев, браузерного тестирования, пакетов машинного обучения, а также проектов, которым необходимы привилегированная виртуализация или пользовательские модули ядра.

VPS или выделенный сервер для Jenkins и GitLab Runner

Когда достаточно VPS

VPS хорошо подходит небольшой команде разработчиков с короткими конвейерами и ограниченным числом параллельных задач. VPS с 4 vCPU, 8 ГБ RAM и 160 ГБ NVMe может обрабатывать примерно 1–4 активные задачи, если сборки не слишком ресурсоёмкие и runner не компилирует одновременно несколько крупных проектов.

От одной до четырёх параллельных задач.
Небольшие проекты на Node.js, Python, PHP, Go или Java.
Лёгкие модульные тесты и нечастые сборки контейнеров.
Хранилище артефактов объёмом менее 100 ГБ.
Сборки, которым не нужны вложенная виртуализация, пользовательские ядра или длительное использование всех ядер CPU.

Используйте отдельные runners или автоматически масштабируемые workers, если учётные данные для развёртывания в продакшене, непроверенные pull request и доверенные задачи выпуска не должны выполняться в одной среде.

Когда выделенное оборудование — лучший выбор

Переходите на физический сервер, если сборки регулярно полностью загружают VPS, время ожидания в очереди становится больше времени выполнения или производительность различается между запусками. Выделенный сервер также предпочтителен, когда runner выполняет непроверенный код, собирает крупные образы контейнеров, запускает базы данных для интеграционных тестов или обрабатывает множество задач с высокой дисковой активностью.

Более 4–6 параллельных задач на регулярной основе.
Более 20 минут непрерывной компиляции на одну задачу.
Крупные сборки Docker или OCI-образов с использованием нескольких гигабайт временных слоёв.
Сборки Android, Chromium, Rust, C++, Unreal Engine и другие ресурсоёмкие задачи.
Постоянные базы данных для интеграционных тестов, кластеры Kubernetes или виртуальные машины на runner.
Строгие требования к изоляции исходного кода, секретов или клиентских сборок.

Рекомендуемые характеристики выделенного сервера

CPU

Выбирайте современное серверное оборудование на базе AMD EPYC или Intel Xeon как минимум с 8 физическими ядрами для универсального CI/CD-хоста. Физические ядра важнее большого числа виртуальных потоков, поскольку компиляция и наборы тестов часто одновременно запускают множество процессов, интенсивно использующих CPU. Сервер с 16 ядрами лучше подходит для 20–40 параллельных задач или команд, которым нужно минимальное время ожидания в очереди.

Отдавайте приоритет стабильной производительности при загрузке всех ядер, достаточному охлаждению и предсказуемому распределению CPU, а не максимальным результатам однопоточных тестов. Число исполнителей Jenkins и параллелизм GitLab Runner следует определять исходя из физических ресурсов, а не просто из количества логических потоков.

Память

Начните с 32 ГБ RAM для сервера сборки с 8 ядрами. Выделяйте примерно 2–4 ГБ на обычную задачу, затем добавляйте объём для операционной системы, кэша страниц Docker, тестовых баз данных и языковых инструментов. Используйте 64 ГБ для 16 ядер, крупных сборок Java или Android, большого числа браузерных тестов или нескольких контейнеров на одну задачу.

Нехватка памяти вызывает использование swap, из-за чего сборки могут замедлиться в несколько раз, а контейнеры могут быть завершены механизмом Linux OOM killer. Отслеживайте максимальное потребление памяти перед увеличением параллелизма runner.

Хранилище

Используйте корпоративное NVMe-хранилище вместо вращающегося диска или недорогого SATA SSD. CI/CD создаёт множество небольших файлов, распаковывает зависимости, записывает промежуточные файлы компилятора и создаёт слои контейнеров. Диск NVMe на 960 ГБ — практичная отправная точка для исходных копий, образов Docker, рабочих пространств и кэшированных зависимостей.

Используйте 1,92 ТБ или больше, если сборки сохраняют артефакты локально, репозитории содержат крупные двоичные файлы или образы Docker пересобираются часто. Оставляйте свободными как минимум 20–30% файловой системы. Для важной инфраструктуры сборки используйте зеркальное хранилище, например RAID 1, а готовые артефакты храните в отдельном реестре или объектном хранилище.

Сеть и пропускная способность

Порта 1 Гбит/с достаточно для большинства команд при условии, что сервер предоставляет не менее 10 ТБ ежемесячного трафика для загрузки зависимостей, образов контейнеров, обмена с репозиториями и выгрузки артефактов. Выбирайте сеть 10 Гбит/с для крупных двоичных артефактов, реестров контейнеров с большим объёмом трафика или более 25 параллельных задач, одновременно передающих данные.

Пропускная способность — не то же самое, что задержка. Runner, расположенный рядом с Git-репозиторием, реестром пакетов, реестром контейнеров и целевыми системами развёртывания, может сократить длительность конвейера даже при неизменной максимальной скорости порта.

Быстрый выбор

Ищете сервер, который просто работает?

Valebyte VPS — NVMe, поддержка 24/7, запуск за 60 секунд.

Тарифы VPS

Таблица соответствия масштаба CI/CD характеристикам

Для 4 и менее параллельных задач достаточно VPS с 4 vCPU; при превышении 10 задач используйте выделенный сервер с 8 ядрами, а для 20–40 задач выбирайте 16 физических ядер и 64 ГБ RAM.

Параллельные задачи CI/CD	vCPU или ядра CPU	RAM	Диск	Ежемесячный трафик
1–4 задачи	4 vCPU	8 ГБ	160 ГБ NVMe	5 ТБ
5–12 задач	8 физических ядер	32 ГБ	960 ГБ корпоративного NVMe	10 ТБ
13–24 задачи	12 физических ядер	48 ГБ	1 920 ГБ корпоративного NVMe	20 ТБ
25–40 задач	16 физических ядер	64 ГБ	3 840 ГБ NVMe RAID 1	30 ТБ

Пошаговая настройка

1. Установите поддерживаемую операционную систему

Используйте актуальный выпуск Ubuntu LTS или Debian с минимальным набором пакетов. Создайте отдельного административного пользователя, отключите прямой вход root и установите обновления до установки Jenkins или GitLab Runner.

sudo apt update && sudo apt full-upgrade -y
sudo adduser cicd
sudo usermod -aG sudo cicd

2. Настройте SSH и брандмауэр

Установите SSH-ключ для административной учётной записи, затем отключите аутентификацию по паролю после проверки доступа по ключу. Разрешите только необходимые сервисы. Jenkins обычно использует TCP 8080 за обратным прокси, тогда как GitLab Runner обычно требуется исходящий доступ без публичного входящего порта.

sudo apt install -y ufw fail2ban
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from YOUR_ADMIN_IP to any port 22 proto tcp
sudo ufw enable

3. Установите Docker для изолированных задач

Docker делает среды сборки воспроизводимыми, однако добавление пользователя в группу Docker предоставляет права, эквивалентные root. Используйте выделенные хосты runner, доверенные задачи и краткоживущие агенты при обработке непроверенного кода. Установите Docker из репозитория, поддерживаемого поставщиком, и проверьте его сервис.

sudo apt install -y docker.io
sudo systemctl enable --now docker
sudo docker run --rm hello-world

4. Установите Jenkins или GitLab Runner

Установите на хосте один основной сервис оркестрации или выделите отдельные узлы для контроллера и workers. Контроллеры Jenkins должны планировать работу, а не напрямую выполнять непроверенные сборки. GitLab Runner следует использовать с Docker executor или другим изолированным executor для воспроизводимых задач.

sudo apt install -y openjdk-17-jre
sudo systemctl enable --now jenkins
sudo systemctl status jenkins

Для GitLab Runner зарегистрируйте машину с помощью токена проекта, группы или экземпляра и выберите Docker executor. Защищайте токены регистрации и используйте защищённые runners для конвейеров выпуска.

sudo apt install -y gitlab-runner
sudo gitlab-runner register
sudo systemctl enable --now gitlab-runner

5. Обдуманно настройте параллелизм

Не устанавливайте параллелизм равным числу всех логических потоков CPU. Начните с 6–8 задач на машине с 8 ядрами и 32 ГБ памяти и измеряйте ожидание CPU, использование RAM, ожидание ввода-вывода и время в очереди. Для хоста с 16 ядрами и 64 ГБ начните с 12–16 задач и увеличивайте это значение только при сохранении отзывчивости сборок.

sudoedit /etc/gitlab-runner/config.toml
sudo systemctl restart gitlab-runner

В Jenkins настройте число исполнителей в параметрах узла и применяйте метки, например docker, android или release, чтобы ресурсоёмкие задачи выполнялись на подходящих workers.

6. Добавьте мониторинг и ротацию журналов

Установите node-exporter, Netdata, Prometheus или другой агент мониторинга. Отслеживайте загрузку CPU, среднюю нагрузку, доступную память, активность swap, задержку диска, заполненность файловой системы, сетевой трафик, неудачные задачи и время ожидания в очереди. Настройте journald и ротацию журналов приложений, чтобы диагностический вывод не заполнил корневую файловую систему.

df -h
free -h
iostat -xz 1 5
uptime

7. Проверьте восстановление до использования в продакшене

Создавайте резервные копии конфигурации Jenkins, метаданных учётных данных, определений задач и конфигурации runner, не раскрывая значения секретов. Проверьте восстановление контроллера, повторное подключение workers, пересборку проекта в чистом рабочем пространстве и восстановление после полного заполнения диска или замены сервера.

Советы по оптимизации производительности

Безопасно кэшируйте зависимости

При необходимости кэшируйте зависимости Maven, Gradle, npm, pip, Go, Composer и Cargo. Используйте lock-файлы и ключи кэша, основанные на операционной системе, архитектуре и контрольной сумме зависимостей. Устаревший или общий кэш может привести к некорректным сборкам, поэтому предусмотрите возможность ручной очистки кэша.

Используйте чистые одноразовые рабочие пространства

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

docker system df
sudo docker image prune --filter "until=168h"

Разделяйте классы сборок

Используйте метки и теги runners, чтобы разделять ресурсоёмкую компиляцию, браузерные тесты, задачи развёртывания и проверку кода с низким потреблением ресурсов. Это не позволит крупной сборке C++ лишить ресурсов задачу выпуска. Если у разных команд противоречивые требования к безопасности, используйте отдельных выделенных workers вместо одной лишь зависимости от меток.

Сокращайте ненужный трафик артефактов

Сжимайте крупные артефакты, загружайте только файлы, необходимые последующим этапам, и устанавливайте сроки хранения. Храните образы контейнеров в реестре, а долгосрочные результаты сборок — в объектном хранилище, вместо сохранения каждого артефакта на локальном NVMe-диске runner.

Оптимизируйте сборки контейнеров

Используйте многоэтапные Dockerfile, фиксируйте версии базовых образов, размещайте стабильные слои зависимостей перед часто изменяющимися слоями исходного кода и включайте BuildKit, если это совместимо с вашей конфигурацией. Сохраняйте контексты сборки небольшими с помощью точного файла .dockerignore. Локальное кэширование работает быстро, но общие удалённые кэши проще воспроизводить на нескольких workers.

Быстрый выбор

Ищете сервер, который просто работает?

Valebyte VPS — NVMe, поддержка 24/7, запуск за 60 секунд.

Тарифы VPS

Распространённые ошибки, которых следует избегать

Запуск всего на контроллере: контроллеры Jenkins не должны выполнять произвольный код из pull request. Используйте агентов с ограниченными разрешениями.
Чрезмерный параллелизм: сорок задач на 8 физических ядрах могут увеличить время ожидания и общее время выполнения. Измеряйте пропускную способность вместо стремления к большому числу исполнителей.
Использование корневого сокета Docker для непроверенного кода: доступ к сокету может предоставить управление на уровне хоста. Используйте изолированные workers, rootless-альтернативы, где это возможно, или одноразовые машины.
Игнорирование ёмкости диска: слои Docker, кэши пакетов, тестовые базы данных и рабочие пространства могут быстро заполнить диск на 160 ГБ. Настройте оповещение при заполнении на 70% и примите меры до достижения 85%.
Хранение секретов в журналах задач: маскируйте учётные данные, ограничивайте конвейеры pull request, заменяйте раскрытые токены и не допускайте вывода переменных среды подробными командами.
Зависимость от одного сервера без резервных копий: выделенный хост не является резервной копией. Храните конфигурацию и артефакты во внешнем хранилище, из которого их можно восстановить, и проверяйте восстановление.
Пропуск управления обновлениями: планируйте обновления операционной системы, Jenkins, runner, Docker и зависимостей. Проверяйте обновления на промежуточном worker перед изменением единственного рабочего runner.
Смешивание доверенных и непроверенных сборок: pull request из fork-репозиториев могут выполнять изменённые определения конвейеров. Используйте отдельные метки, разрешения, учётные данные и, желательно, отдельные хосты workers.

Выбор подходящей архитектуры

Небольшая команда может запускать Jenkins или GitLab Runner на VPS с 4 vCPU и 8 ГБ RAM, если задачи выполняются нечасто, а сборки лёгкие. Выделенный сервер с 8 ядрами — практичный средний вариант для ежедневных сборок контейнеров, 5–12 параллельных задач и предсказуемой производительности. Командам, выполняющим мобильные сборки, работающим с крупными монорепозиториями и фермами браузеров или обрабатывающим более 20 параллельных задач, следует использовать выделенный хост с 16 ядрами или больше, при необходимости разделив его на специализированные workers.

Для максимальной изоляции держите контроллер оркестрации отдельно от workers сборки и создавайте одноразовых агентов для непроверенного кода. Такая архитектура стоит дороже одного сервера, но ограничивает раскрытие учётных данных и упрощает масштабирование ресурсов. Начните с измеренных данных конвейеров — средней длительности, пиковой параллельности, процессорного времени, максимального потребления RAM, размера артефактов и времени ожидания в очереди, — затем корректируйте оборудование на основе фактов.