Стаття також доступна російською (перейти до перегляду).

Фактично весь CI/CD у GitLab тримається на GitLab Runner — саме він запускає збірки, тести та деплой. І поки пайплайни прості, здається, що немає різниці, де він працює: на локальній машині, на сервері GitLab чи десь “під рукою”. Але щойно проєкт росте — починаються типові проблеми: збірки гальмують через нестачу ресурсів, кеш і Docker-образи засмічують систему, а доступи до приватної мережі перетворюються на головний біль і ризик для безпеки.

У цій статті розберемо, чому зовнішній GitLab Runner на окремому VPS з Docker executor дає більше контролю, стабільності та безпеки, і як його налаштувати так, щоб пайплайни працювали передбачувано — включно з кейсом, коли runner має доступ до приватної мережі, а GitLab не доводиться “обвішувати” зайвими інтерфейсами.

Що собою представляє GitLab Runner

GitLab Runner є додатком, котрий працює із GitLab CI/CD та забезпечує запуск та виконання завдань у пайплайні. Існує два його різновиди в залежності від місця розгортання:

• GitLab-hosted runners: агенти розміщені на платформі GitLab та керуються лише нею;

• Self-managed runners: самокеровані агенти, котрі встановлюються, налаштовуються та керуються Адміністраторами хостів у межах власної мережевої інфраструктури.

Процес роботи раннера можна описати наступним чином:

1. Спочатку Runner реєструється в GitLab – цим забезпечується постійне з’єднання між ним таGitLab;

2. Після ініціалізації роботи конвеєру, GitLab формує чергу із завдань (jobs) та перевіряє всі зареєстровані у системі раннери на відповідність визначеним умовам;

3. Агенти, котрі відповідають умовам (тип, відповідність вказаному у сценарії тегу, статус та можливості), отримують одне з завдань та виконують його;

4. Результати виконання завдання у режимі реального часу передаються до GitLab. 

Виділимо лише декотрі із властивостей агентів:

• Розповсюджується у вигляді єдиного виконавчого файлу без додаткових вимог;

• Підтримує Bash та PowerShell;

• Сумісний із macOS, Windows та GNU/Linux системами;

• Дозволяє налаштовувати середовище виконання завдань;

• Працює із багатьма виконавцями завдань (executor): Shell, Docker та Kubernetes;

• Забезпечує кешування Docker-контейнерів;

• Можливість запуску у якості служби на всіх системах, котрі підтримуються;

• Pull-модель підключення до GitLab;

• Інтегрований із HTTP-сервером метрик Prometheus.

Чому краще обирати зовнішній runner

В залежності від ситуації та типу проекту іноді доводиться обирати між GitLab-hosted та Self-managed раннерами. Насправді це є ключовим питанням, котре визначає спосіб організації роботи пайплайну, можливості керування ресурсами та рівень захисту.

GitLab-hosted раннери зазвичай обирають у наступних випадках:

• Пайплайн не вимагає будь-якого обслуговування;

• Немає потреби в управлінні інфраструктурою;

• Використовуються стандартні середовища для збірки проектів;

• Існує необхідність в ізоляції завдань у проміжках між запусками;

• При використанні GitLab Dedicated або GitLab.com.

Self-managed раннери будуть незамінними у випадках:

• Є необхідність у запуску завдань в межах приватної мережі;

• Існує потреба в ізоляції CI від GitLab;

• Важливі користувацькі налаштування;

• Для можливості масштабування, коли існує потреба в спеціальних раннерах для окремих проектів або груп;

• Для оптимізації швидкості роботи конвеєру за рахунок кешування або повторного використання Runner;

• Для управління власною інфраструктурою та контролю виділення ресурсів – CPU, RAM,disk I/O тощо;

• У разі підвищених вимог до безпеки, коли існує потреба у використанні secrets, доступів, розділенні зон.

Чому краще обирати Docker executor

Для запуску завдань на Docker-шаблонах, GitLab Runner використовує Docker executor, що є цілком зрозуміло. У свою чергу, Executor використовує Docker Engine для запуску кожного job-а в ізольованому контейнері.

Docker executor найкраще підходить для застосування у наступних випадках:

• Для забезпечення одного й того ж середовища збірки для кожного окремого завдання;

• Надійної ізоляції середовища виконання та забезпечення його «чистоти»;

• Використання одного й того ж image для локального тестування команд без запуску завдання на CI-сервері;

• Кросплатформність та простота обслуговування.

Для підключення до Docker EngineExecutor використовує шаблони та сервіси, котрі  визначені у файлі .gitlab-ci.yml, а також використовує конфігурації із файлу config.toml.

Важливість використання тегів GitLab CI/CD

Раннери можуть обробляти завдання у режимах із використанням тегів або без них. У другому випадку один і той самий раннер може обробити будь-яке завдання з черги пайплайну. У цьому режимі відсутня вибірковість, і тому не можна «прив’язати» Runner до визначеного завдання, що у багатьох випадках незручно та може призвести до зниження продуктивності виконання завдань пайплайну.

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

• Контроль списку завдань, котрі може обробляти раннер;

• Дає змогу обрати для завдання певний агент зі списку доступних для проекту, наприклад, якщо для нього визначені потрібні для виконання завдання залежності;

• Збільшує керованість процесом завдяки використанню змінних CI/CD у сценаріях;

• Підвищує продуктивність роботи пайплайну за рахунок гнучкості управління процесом 

Все це досягається застосуванням тегів GitLab CI/CD, котрі, у загальному випадку, відрізняються від тегів Git. Перші прив’язуються до раннерів, другі – до коммітів. 

Підтримуються наступні значення тегів:

• Масив імен тегів, залежних від регістру символів, список доступних версій тегів можна переглянути за адресою;

• Змінні CI/CD.

У якості значень тегів зазвичай використовуються назви платформ, технологій, мов програмування тощо, наприклад, docker,ruby, windows.

Система управління job-ми побудована таким чином, що теги прописуються окремо різними способами для раннерів та job-ів.

Наприклад, щоб прописати теги для раннера проекту, у котрому ви маєте статус власника, слід виконати наступні дії у вікні керування проектами GitLab:

1. У верхньому меню обрати Пошук або перейти до розділу Знайти проект;

2. Обрати команду Налаштування >CI/CD;

3. Розгорнути блок Runners;

4. Навпроти потрібного раннера обрати команду Редагувати;

5. У поле Теги потрібно ввести через кому теги завдань;

6. Відключити опцію Запускати завдання без тегів;

7. Натиснути кнопку Зберегти зміни.

У свою чергу, теги для job-ів прописуються у файлі .gitlab-ci.yml, наприклад

job:

  tags:
- ruby
- macos
- postgres

Це означає, що завдання буде виконуватися лише тими раннерами, для котрих прописані ті ж самі теги. Runner може мати й інші теги, але присутність зазначених є обов’язковою. У іншому випадку, job «зависне» та ніколи не виконається.

У випадку, якщо включена опція Запускати завдання без тегів та прописані всі співпадаючі із job-ом теги, завдання також виконається, а також виконаються всі інші завдання, котрі не мають тегів. Така гнучкість в управлінні процесом, зокрема, дозволяє для різних платформ використовувати відповідні раннери та уникати плутанини.

Встановлення та налаштування

Для нашого завдання буде використано дваVPS-сервери (Ubuntu/Debian) із однаковими базовими налаштуваннями. Перший сервер (VPS-1) потрібний для розгортання GitLab CE – це зніме існуючі обмеження безкоштовних репозиторіїв та збільшить рівень безпеки та керованість процесом. На іншому сервері (VPS-2) буде розгорнуто Self-managedRunner. 

Розіб’ємо процес на декілька етапів.

Виконання базових налаштувань VPS-серверів

Оновимо індекс пакетів та виконаємо оновлення системи:

 $ sudo apt update && sudo apt upgrade -y

Створимо окремого користувача та додамо його до групи sudo: 

$ adduser pipeline_user
$ usermod -aG sudo pipeline_user

Налаштуємо SSH:

$ sudo nano /etc/ssh/sshd_config
PermitRootLogin no //забороняємо root-доступ
Port 2222 //задаємо потрібний порт (як приклад)
Перезавантажимо службу:
$ sudo systemctl restart sshd
Налаштуємо Брандмауер:
$ sudo ufw allow 2222/tcp
$ sudo ufw allow https
$ sudo ufw allow http
$ sudo ufw enable

Встановлюємо Docker:

$ sudo apt install -y apt-transport-https ca-certificates curl software-properties-common
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
$ sudo apt update
$ sudo apt install -y docker-ce

Розгортання GitLab CE на VPS-1

Встановлюємо GitLab CE у контейнері Docker (це забезпечить легке оновлення та кросплатформність середовища):

$ docker run --detach \
  --hostname gitlab.myproject.com \
  --publish 443:443 --publish 80:80 --publish 2222:22 \
  --name gitlab \
  --restart always \
  --volume /srv/gitlab/config:/etc/gitlab \ 
  --volume /srv/gitlab/logs:/var/log/gitlab \
  --volume /srv/gitlab/data:/var/opt/gitlab \
  gitlab/gitlab-ce:latest

Тут замість gitlab.myproject.com слід вказатиIP-адресу серверу або його доменне ім’я. Каталоги /srv/... використовуються для зберігання даних поза контейнером.

Розгортання GitLab Runner на VPS-2

Встановлюємо GitLab Runner на окремий VPS-сервер:

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

Реєстрація Runner-а

На VPS-2 введемо в терміналі наступну команду:

$ sudo gitlab-runner register

При цьому ініціюється процес реєстрації раннера, під час якого необхідно буде ввести наступні дані:

Адресу розміщення свого GitLab (див. вище);

• Токен для раннера, котрий можна знайти у вікні GitLab, обравши команду: Admin > Runners.

В налаштуваннях раннера (див. вище) необхідно обрати Docker executor, включити опцію specific (проектний Runner) та ввести теги відповідно до завдань, котрі будуть виконуватися, наприклад, це можуть бути теги docker та php.

Приклад файлу .gitlab-ci.yml

На завершальній стадії підготовки пайплайну слід створити новий проект у нашому GitLab та додати у корінь репозиторію файл із ім’ям .gitlab-ci.yml.

Розміщений у .gitlab-ci.yml сценарій може бути наступним:

stages:

  - build
  - test

build:

  stage: build
  tags: [docker]
  script:
- php -v
  tags:
    - php

test:

  stage: test
  tags: [docker]
  script:
- echo "Тестування успішно завершено!"
  tags:
    - php

Само собою, теги docker та php повинні бути прописані для відповідного проектного Runner-а, як було продемонстровано вище.

Якщо все налаштовано вірно – кожний push буде запускати пайплайн.

Питання безпеки

Використання конфігурації з двома VPS-серверами для GitLab та Runner-ів дозволить отримати наступні переваги:

• Повний контроль над даними, кодом та пайплайном;

• Гнучкість в налаштуваннях та незалежність від обмежень SaaS-сервісів – пайплайни можна налаштувати під будь-які завдання;

• Розмежування раннерів по завданням;

• Окремі правила firewall для кожного з серверів;

• Міінімізація privileged;

• Зберігання токенів / секретів у GitLab CI змінних, а не в репозиторії.

Однак, для забезпечення повного захисту системи слід дотримуватися наступних правил:

• Використовувати окреме сховище даних для GitLab – це спрощує створення бекапів та підвищує рівень кросплатформності;

• Застосовувати для HTTPS;

• Вчасно оновлювати GitLab та GitLab Runner для зменшення кількості вразливостей;

• У випадку приватного проекту обмежити доступ до GitLab через брандмауер та VPN;

• Виконувати регулярне створення бекапів.

Висновки

Конфігурація з GitLab та GitLab Runner на окремих VPS-серверах все частіше стає звичайною практикою для продакшн не тільки великих команд розробників, а й для груп із 3-5 девелоперів. Розгорнути все це та налаштувати для своїх потреб можна протягом 3-х годин. В результаті, отримуємо стабільність, високий рівень безпеки та повну керованість ресурсами та пайплайном. Продуктивні VPS-сервери під CI і не тільки можна замовити в один клік на FREEhost.UA.

Підписуйтесь на наш телеграм-канал https://t.me/freehostua, щоб бути в курсі нових корисних матеріалів.

Дивіться наш канал Youtube на https://www.youtube.com/freehostua.

Ми у чомусь помилилися, чи щось пропустили?

Напишіть про це у коментарях, ми з задоволенням відповімо та обговоримо Ваші зауваження та пропозиції.

Дата: 30.12.2025 Автор: Олександр Ровник #devops#gitlab

Голосування 1 2 3 4 5