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

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

Навантаження безперервної інтеграції та безперервної доставки є ресурсоємними, оскільки один конвеєр може компілювати вихідний код, збирати образи контейнерів, запускати тести, сканувати залежності, пакувати артефакти та розгортати сервіси. Кілька конвеєрів, що працюють одночасно, можуть споживати всі потоки CPU, заповнювати тимчасове сховище та створювати високе дискове I/O.

Виділений сервер надає Jenkins або GitLab Runner ексклюзивний доступ до фізичних ядер CPU, RAM, NVMe-сховища та мережевої пропускної здатності. Це покращує стабільність часу збірки та не дозволяє сторонньому орендарю впливати на продуктивність компіляції або тестування. Bare metal особливо корисний для конвеєрів із активним використанням 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 або працівників з автоматичним масштабуванням, якщо облікові дані для розгортання в production, недовірені pull request-и та довірені завдання релізу не повинні використовувати спільне середовище.

Коли виділене обладнання є кращим вибором

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

• Понад 4–6 одночасних завдань на регулярній основі.
• Понад 20 хвилин безперервної компіляції на завдання.
• Великі збірки образів Docker або OCI, що використовують кілька гігабайтів тимчасових шарів.
• Android, Chromium, Rust, C++, Unreal Engine або інші CPU-інтенсивні збірки.
• Постійні бази даних для інтеграційних тестів, кластери Kubernetes або віртуальні машини на runner.
• Суворі вимоги до ізоляції вихідного коду, секретів або клієнтських збірок.

Рекомендовані специфікації виділеного сервера

CPU

Для універсального CI/CD-хоста вибирайте сучасне серверне обладнання AMD EPYC або Intel Xeon щонайменше з 8 фізичними ядрами. Фізичні ядра важливіші за велику кількість віртуальних потоків, оскільки компіляція та набори тестів часто одночасно запускають багато процесів, обмежених 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 ГБ є практичною початковою точкою для checkout-ів вихідного коду, образів Docker, робочих просторів і кешованих залежностей.

Використовуйте 1,92 ТБ або більше, якщо збірки зберігають артефакти локально, репозиторії містять великі бінарні файли або образи Docker часто перебудовуються. Залишайте щонайменше 20–30% файлової системи вільними. Для важливої інфраструктури збірки використовуйте дзеркальне сховище, наприклад RAID 1, і зберігайте кінцеві артефакти в окремому реєстрі або системі об’єктного сховища.

Мережа та пропускна здатність

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

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

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

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

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

До серверів

Таблиця відповідності масштабу CI/CD специфікаціям

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

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

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 за reverse proxy, тоді як 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

Встановіть на хості одну основну службу оркестрації або виділіть окремі вузли для контролера та працівників. Контролери Jenkins повинні планувати роботу, а не безпосередньо виконувати недовірені збірки. GitLab Runner повинен використовувати виконавець Docker або інший ізольований виконавець для повторюваних завдань.

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

Для GitLab Runner зареєструйте машину за допомогою токена проєкту, групи або інстансу та виберіть виконавець Docker. Захищайте токени реєстрації та використовуйте захищені 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, очікування I/O та час у черзі. Для хоста з 16 ядрами та 64 ГБ почніть із 12–16 завдань і збільшуйте лише за умови, що збірки залишаються чутливими.

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

У Jenkins налаштуйте кількість виконавців у параметрах вузла та застосуйте мітки, такі як docker, android або release, щоб ресурсоємні завдання потрапляли на відповідних працівників.

6. Додайте моніторинг і ротацію журналів

Встановіть node-exporter, Netdata, Prometheus або інший агент моніторингу. Відстежуйте використання CPU, середнє навантаження, доступну пам’ять, активність swap, затримку диска, місткість файлової системи, мережевий трафік, невдалі завдання та час у черзі. Налаштуйте ротацію журналів journald і застосунків, щоб діагностичний вивід не міг заповнити кореневу файлову систему.

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

7. Перевірте відновлення перед використанням у production

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

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

Безпечно кешуйте залежності

Кешуйте залежності Maven, Gradle, npm, pip, Go, Composer і Cargo там, де це доречно. Використовуйте lockfiles і ключі кешу на основі операційної системи, архітектури та контрольної суми залежностей. Застарілий або спільний кеш може створювати некоректні збірки, тому забезпечте можливість ручного очищення кешу.

Використовуйте чисті одноразові робочі простори

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

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

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

Використовуйте мітки та теги runner для розділення CPU-інтенсивної компіляції, браузерних тестів, завдань розгортання та linting із низьким споживанням ресурсів. Це не дозволяє великій C++-збірці блокувати завдання релізу. Якщо різні команди мають суперечливі вимоги безпеки, використовуйте окремих виділених працівників замість покладання лише на мітки.

Зменшуйте непотрібний трафік артефактів

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

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

Використовуйте багатостадійні Dockerfile, фіксуйте версії базових образів, розміщуйте стабільні шари залежностей перед шарами вихідного коду, що часто змінюються, та вмикайте BuildKit там, де це сумісно. Зберігайте контексти збірки малими за допомогою точного файлу .dockerignore. Локальне кешування швидке, але спільні віддалені кеші легше відтворювати на кількох працівниках.

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

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

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

До серверів

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

• Запуск усього на контролері: Контролери Jenkins не повинні виконувати довільний код pull request-ів. Використовуйте агентів з обмеженими дозволами.
• Надмірна паралельність: Сорок завдань на 8 фізичних ядрах можуть збільшити час у черзі та загальний час завершення. Вимірюйте пропускну здатність замість гонитви за великою кількістю виконавців.
• Використання root-сокета Docker для недовіреного коду: Доступ до сокета може надати контроль на рівні хоста. Використовуйте ізольованих працівників, безroot-альтернативи там, де це практично, або одноразові машини.
• Ігнорування місткості диска: Шари Docker, кеші пакетів, тестові бази даних і робочі простори можуть швидко заповнити диск на 160 ГБ. Налаштуйте сповіщення за 70% використання та вживайте заходів до досягнення 85%.
• Зберігання секретів у журналах завдань: Маскуйте облікові дані, обмежуйте конвеєри pull request-ів, замінюйте скомпрометовані токени та не дозволяйте докладним командам друкувати змінні середовища.
• Покладання на один сервер без резервних копій: Виділений хост не є резервною копією. Зберігайте конфігурацію та артефакти у зовнішньому сховищі, яке можна відновити, і перевіряйте відновлення.
• Пропуск керування виправленнями: Плануйте оновлення операційної системи, Jenkins, runner, Docker і залежностей. Перевіряйте оновлення на staging-працівнику перед зміною єдиного production-runner.
• Змішування довірених і недовірених збірок: Pull request-и на основі fork можуть виконувати змінені визначення конвеєрів. Використовуйте окремі мітки, дозволи, облікові дані та, бажано, окремі хости працівників.

Вибір правильної архітектури

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

Для найсильнішої ізоляції тримайте контролер оркестрації окремо від працівників збірки та виділяйте одноразових агентів для недовіреного коду. Така архітектура коштує дорожче за один сервер, але обмежує розкриття облікових даних і полегшує масштабування потужності. Почніть із виміряних даних конвеєра — середньої тривалості, пікової паралельності, часу CPU, пікового використання RAM, розміру артефактів і часу в черзі — а потім коригуйте обладнання на основі доказів.