Виділений сервер для Jenkins і CI/CD-пайплайнів GitLab

Навіщо використовувати виділений сервер для CI/CD?

Системи безперервної інтеграції та безперервної доставки компілюють код, запускають тести, збирають образи контейнерів, сканують залежності та публікують артефакти. Ці завдання часто створюють короткочасні періоди дуже високого навантаження на CPU, пам’ять, дискове введення-виведення та мережу. Агенти Jenkins і GitLab Runner також виконують код із багатьох гілок, тому конкуренція за ресурси може зробити тривалість конвеєрів непередбачуваною.

Виділений сервер надає CI-системі винятковий доступ до ядер CPU, пам’яті, NVMe-накопичувача та мережевого порту. Така ізоляція зменшує вплив сусідніх навантажень і спрощує оцінювання часу збірки. Вона також дає змогу адміністратору налаштувати операційну систему, сховище Docker, кешування, політику використання swap і засоби безпеки з урахуванням навантаження runner.

VPS чи виділений сервер?

VPS достатньо, якщо

• Команда запускає менше ніж 5 паралельних завдань.
• Більшість збірок завершується менш ніж за 10 хвилин і не компілює великі проєкти.
• Образи контейнерів і залежності достатньо малі, щоб уміститися у 80–160 ГБ NVMe-сховища.
• Збої збірки, спричинені конкуренцією за CPU або диск, не мають істотного впливу на бізнес.
• CI-сервіс відокремлений від виробничих баз даних і застосунків, доступних клієнтам.

VPS із 4 vCPU, 8 ГБ ОЗП і 160 ГБ NVMe-сховища може підтримувати невеликий контролер Jenkins, один легкий агент або GitLab Runner для вебзастосунків і репозиторіїв інфраструктури. За можливості розділяйте контролер і завдання збірки; контролери Jenkins мають планувати роботу, а не виконувати важку компіляцію.

Переходьте на bare metal, якщо

• Одночасно виконується понад 10 завдань або затримка в черзі регулярно перевищує 5 хвилин.
• Збірки тривалий час використовують усі виділені vCPU.
• Проєкти компілюють великі кодові бази на Java, Rust, C++, Android або .NET.
• Збірки образів Docker створюють багато гігабайтів тимчасових шарів.
• Кільком командам потрібні ізольовані runner’и або виділені виконавці.
• Для випусків, тестування або вікон розгортання потрібен передбачуваний час виконання збірок.
• Система зберігає великі кеші артефактів, дзеркала пакетів або реєстри контейнерів.

Bare metal також добре підходить для привілейованих навантажень. Docker-in-Docker, вкладена віртуалізація, тестування обладнання та високооб’ємні інтеграційні тести можуть створювати проблеми із «галасливими сусідами», безпекою або введенням-виведенням на спільному віртуальному хості.

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

Для спільного хоста Jenkins або GitLab Runner почніть із 8 фізичних ядер, 32 ГБ ECC-пам’яті та 480 або 960 ГБ корпоративного NVMe-сховища. Обирайте сучасний серверний процесор із високою продуктивністю одного потоку, а також достатньою кількістю ядер для паралельних завдань. Компіляція та набори тестів виграють від обох цих властивостей.

• CPU: від 8 до 16 фізичних ядер для середніх команд; від 16 до 32 ядер для великих ферм збірки. Не визначайте конфігурацію лише за кількістю потоків, оскільки багатопоточність не дорівнює другому фізичному ядру.
• ОЗП: 32 ГБ для 10–20 паралельних завдань, 64 ГБ для 20–40 завдань і 128 ГБ або більше для великих мовних збірок, збірок Android, браузерного тестування або великої кількості контейнерів.
• Сховище: перевагу слід надавати NVMe SSD. Використовуйте 480 ГБ для компактного runner і 960 ГБ–1,92 ТБ для локальних кешів, артефактів і шарів контейнерів. RAID 1 захищає доступність, але не замінює резервне копіювання за межами сервера.
• Мережа: 1 Гбіт/с достатньо для більшості команд. Обирайте 10 Гбіт/с, якщо runner’и завантажують великі образи, дзеркалять пакети або часто передають артефакти розміром у кілька гігабайтів. Щомісячний ліміт трафіку 10 ТБ — практична відправна точка.
• Операційна система: Debian 12, Ubuntu Server 24.04 LTS або інший підтримуваний дистрибутив Linux. Тримайте хост мінімальним, а сервіси застосунків розміщуйте на окремих машинах.

Не розміщуйте Jenkins, GitLab, реєстр контейнерів і виробничу базу даних на одному сервері лише тому, що CPU має вільні ядра. Завдання CI виконують змінюваний код і повинні мати чітку межу довіри із системами керування вихідним кодом і виробничими системами.

Для 10 або меншої кількості паралельних завдань зазвичай достатньо VPS із 4 vCPU; за понад 20 паралельних завдань або тривалої компіляції використовуйте виділений сервер із 16 ядрами, 64 ГБ ОЗП і 960 ГБ NVMe.

Швидкий вибір

Потрібен виділений сервер?

Bare metal з NVMe у 70+ локаціях — налаштування й замовлення за кілька хвилин.

До серверів

Покрокове налаштування

1. Підготуйте DNS, доступ і чистий хост

Створіть окремий DNS-запис, наприклад ci.example.com, і використовуйте SSH-ключі замість автентифікації за паролем. Встановіть підтримуваний образ Linux і створіть адміністратора без прав root. Обмежте SSH за допомогою міжмережевого екрана та дозвольте доступ лише з довірених офісних, VPN- або адміністративних адрес.

2. Оновіть операційну систему

Встановіть оновлення безпеки до додавання Jenkins або GitLab Runner:

sudo apt update && sudo apt full-upgrade -y

Встановіть правильний часовий пояс і ввімкніть автоматичні оновлення безпеки, якщо це допускається вашою політикою змін. Перезавантажте систему після оновлень ядра.

3. Налаштуйте міжмережевий екран

Відкрийте лише необхідні порти. Jenkins зазвичай використовує TCP 8080 за зворотним проксі, тоді як GitLab Runner зазвичай встановлює вихідні з’єднання і не потребує вхідного сервісного порту.

sudo apt install -y ufw
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

4. Встановіть Docker для ізольованих завдань

Завдання на основі Docker забезпечують відтворювані залежності та спрощують очищення. Встановіть Docker із репозиторію, який підтримує дистрибутив, або з офіційного репозиторію Docker, потім перевірте роботу демона:

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

Не надавайте ненадійним користувачам необмежений доступ до сокета Docker. Членство в групі docker фактично означає root-доступ до хоста. Для менш довіреного коду використовуйте довірені репозиторії, захищені гілки, ізольовані runner’и або альтернативи без прав root.

5. Встановіть і зареєструйте GitLab Runner

Встановіть пакет runner за допомогою репозиторію постачальника, потім зареєструйте його за допомогою токена проєкту або групи. Використовуйте такі теги, як docker, linux або privileged, лише коли вони потрібні конвеєру.

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash
sudo apt install -y gitlab-runner
sudo gitlab-runner register

Коли з’явиться запит, виберіть виконавця Docker. Встановіть обмеження паралелізму в /etc/gitlab-runner/config.toml, щоб на хості зберігався запас пам’яті та CPU для системних завдань.

6. Встановіть Jenkins на окремому контролері або агенті

Для невеликої інсталяції Jenkins може працювати на тому самому хості, що й один агент. Для великих інсталяцій розмістіть контролер на невеликому VPS, а виділений сервер використовуйте як вхідний або вихідний агент збірки. Встановіть Java, підтримувану вибраним випуском Jenkins, потім встановіть Jenkins із підписаного репозиторію.

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

Розмістіть Jenkins за зворотним HTTPS-проксі, увімкніть обов’язкову автентифікацію, вимкніть анонімні збірки та обмежте права агентів. Для ненадійних запитів на злиття віддавайте перевагу ефемерним агентам або одноразовим контейнерам.

7. Додайте кешування та зберігання артефактів

Кешуйте залежності пакетів і результати компіляції лише тоді, коли інвалідація кешу є надійною. Налаштуйте правила зберігання журналів збірки й артефактів; безстрокове зберігання всіх артефактів зрештою заповнить NVMe-том. Зберігайте артефакти випусків в об’єктному сховищі або виділеному реєстрі з політиками життєвого циклу.

8. Перевірте паралелізм до використання в робочому середовищі

Одночасно запустіть кілька показових конвеєрів і виміряйте завантаження CPU, тиск на пам’ять, затримку диска, передавання даних мережею та час очікування в черзі:

sudo apt install -y sysstat iotop
mpstat -P ALL 5
iostat -xz 5
free -h

Збільшуйте кількість виконавців лише після підтвердження того, що обсяг ОЗП і затримка диска залишаються в допустимих межах.

Оптимізація продуктивності

Зіставте виконавців із фізичними ресурсами

Занадто велика кількість виконавців створює конвеєри без черг, але з низькою швидкістю. Почніть з одного виконавця на фізичне ядро для ресурсомісткої компіляції, потім ретельно протестуйте конфігурацію. Браузерні тести, мережеві тести та завдання з інтенсивним введенням-виведенням можуть підтримувати більший паралелізм, тоді як збіркам Android і великим збіркам C++ може знадобитися кілька гігабайтів ОЗП на одного виконавця.

Використовуйте швидке контрольоване сховище Docker

Розмістіть кореневий каталог даних Docker на NVMe та контролюйте використання за допомогою docker system df. Очищайте невикористовувані шари за розкладом, а не під час пікових збірок:

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

За потреби використовуйте дзеркала реєстрів або проксі залежностей GitLab. Не видаляйте активні томи й ніколи не запускайте широкі команди очищення без підтвердження вимог до зберігання.

Захистіть пам’ять і дисковий простір

Встановіть обмеження пам’яті на рівні завдань для контейнерів, зарезервуйте ОЗП для операційної системи та налаштуйте сповіщення, коли файлова система заповнюється більш ніж на 80 відсотків. Невеликий swap-файл може запобігти аварійному завершенню процесу, але swap не замінює достатній обсяг ОЗП:

sudo fallocate -l 8G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

Скоротіть непотрібну роботу конвеєра

• Використовуйте lock-файли залежностей і зафіксовані базові образи.
• Запускайте модульні тести під час кожного коміту, а дорогі інтеграційні тести — у захищених гілках або за розкладом.
• Використовуйте поверхневе клонування Git, якщо повна історія не потрібна.
• Збирайте один раз, потім переміщуйте протестований артефакт між середовищами.
• Розпаралелюйте незалежні етапи, зберігаючи паралелізм нижче перевіреної продуктивності сервера.

Контролюйте хост CI

Відстежуйте тривалість очікування в черзі, тривалість завдань, використання виконавців, середнє навантаження, тиск на пам’ять, затримку диска, ємність файлової системи та невдалі завдання. Налаштуйте сповіщення у разі стабільного навантаження, що перевищує доступну кількість фізичних ядер, використання диска понад 80 відсотків і повторюваних подій нестачі пам’яті. Централізуйте журнали, щоб збій хоста не знищив дані, потрібні для діагностики.

Поширені помилки, яких слід уникати

• Запуск збірок на контролері Jenkins: залиште виконавців контролера вимкненими або встановіть їх невелику кількість, а важку роботу призначайте агентам.
• Надмірна кількість виконавців: 32 логічні потоки не гарантують 32 швидких завдання компіляції. Тестуйте конфігурацію на реальних репозиторіях.
• Використання одного спільного привілейованого runner: розділяйте довірені завдання випуску та завдання запитів на злиття, обмежуйте привілейований доступ до Docker.
• Ігнорування зростання дискового простору: шари контейнерів, каталоги робочих просторів, звіти тестів і артефакти можуть швидко заповнити диск обсягом 480 ГБ.
• Відмова від резервного копіювання: створюйте резервні копії конфігурації Jenkins, метаданих облікових даних, визначень конвеєрів і конфігурації runner, зберігаючи секрети в зашифрованому вигляді.
• Відкриті інтерфейси керування: розмістіть Jenkins за HTTPS, увімкніть MFA через постачальника ідентифікації та обмежте адміністративні шляхи.
• Використання залежностей без фіксації версій: пакети та базові образи без фіксації версій ускладнюють відтворення збірок і можуть створювати ризики для ланцюга постачання.
• Змішування CI і робочого середовища: скомпрометоване завдання збірки не повинно мати прямого мережевого доступу до виробничих баз даних або облікових даних для розгортання.

Швидкий вибір

Потрібен виділений сервер?

Bare metal з NVMe у 70+ локаціях — налаштування й замовлення за кілька хвилин.

До серверів

Коли додавати додаткові сервери

Один великий сервер не завжди є найкращим рішенням. Додавайте окремі агенти, якщо проєктам потрібні різні операційні системи, архітектури CPU, доступ до GPU або рівні довіри. Контролер і два або більше виділених агентів можуть скоротити час очікування в черзі та дозволити виконувати обслуговування без зупинки всіх конвеєрів. Використовуйте мітки й теги runner, щоб спрямовувати завдання Android, ARM, браузерного тестування, випуску та сканування безпеки на відповідне обладнання.

Для високої доступності незалежно створюйте резервні копії системи керування вихідним кодом і метаданих CI, підтримуйте образ для заміни runner та документуйте процедури реєстрації й ротації секретів. Доступність CI визначається не лише часом роботи сервера, а й можливістю відтворити чисту збірку після збою.