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

Фактически весь CI/CD в GitLab держится на GitLab Runner – именно он запускает сборки, тесты и деплой. И пока пайплайны просты, кажется, что нет разницы, где он работает: на локальной машине, на сервере GitLab или где-то под рукой. Но как только проект растет — начинаются типичные проблемы: сборки тормозят из-за нехватки ресурсов, кэш и Docker-образы засоряют систему, а доступы к частной сети превращаются в головную боль и риск безопасности.

В этой статье разберем, почему внешний GitLab Runner на отдельном VPS с исполнителем Docker дает больше контроля, стабильности и безопасности, и как его настроить так, чтобы пайплайны работали предсказуемо - включая кейс, когда runner имеет доступ к частной сети, а GitLab не приходится "увешивать" лишними интерфейсами.

Что собой представляет GitLab Runner

GitLab Runner является приложением, работающим с GitLab CI/CD и обеспечивает запуск и выполнение заданий в пайплайне. Существует две его разновидности в зависимости от места развертывания:

• GitLab Runner, размещенные в GitLab: агенты размещены на платформе GitLab и руководствуются только ею;

• Self-managed runners: самоуправляемые агенты, устанавливаемые, настраиваемые и управляемые Администраторами хостов в пределах собственной сетевой инфраструктуры.

Процесс работы раннера можно описать следующим образом:

 Сначала Runner регистрируется в GitLab – этим обеспечивается постоянное соединение между ним и GitLab;

1. После инициализации работы конвейера, GitLab формирует очередь из задач (работа) и проверяет все зарегистрированные в системе раннеры на соответствие определенным условиям;

2. Агенты, отвечающие условиям (тип, соответствие указанному в сценарии тегу, статус и возможности), получают одну из задач и выполняют ее;

3. Результаты выполнения задания в режиме реального времени передаются в 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.

Самостоятельно управляемый раннеры будут незаменимыми в случаях:

• Есть необходимость в запуске задач внутри частной сети;

• Существует потребность в изоляции CI от GitLab;

• Важны пользовательские настройки;

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

• Для оптимизации скорости работы конвейера за счет кэширования или повторного использования Runner;

• Для управления собственной инфраструктурой и контроля выделения ресурсов – CPU, RAM,disk I/O и т.п.;

• В случае повышенных требований к безопасности, когда существует потребность в использовании secrets, доступов, разделении зон.

Почему лучше выбирать Docker executor

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

Docker executor лучше всего подходит для применения в следующих случаях:

• Для обеспечения одной и той же среды сборки для каждой отдельной задачи;

• Надежной изоляции среды выполнения и обеспечения ее «чистоты»;

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

• Кроссплатформенность и простота обслуживания.

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

Важность использования тегов GitLab CI/CD

Раннеры могут обрабатывать задачи в режимах с использованием тегов или без них. Во втором случае один и тот же раннер может обработать любую задачу из очереди пайплайна. В этом режиме отсутствует избирательность, поэтому нельзя «привязать» Runner к определенной задаче, что во многих случаях неудобно и может привести к снижению производительности выполнения задач пайплайна.

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

• контроль списка задач, которые может обрабатывать раннер;

• Позволяет выбрать для задания определенный агент из списка доступных для проекта, например, если для него определены необходимые для выполнения задания зависимости;

• Увеличивает управляемость процессом благодаря использованию переменных CI/CD в сценариях;

• Повышает производительность пайплайной работы за счет гибкости управления процессом. 

Все это достигается применением тегов GitLab CI/CD, которые, в общем случае, отличаются от меток Git. Первые привязываются к раннерам, вторые – к коммитам.

Поддерживаются следующие значения тегов:

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

• Переменные CI/CD. 

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

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

Например, чтобы прописать теги для раннера проекта, в котором вы имеете статус владельца, следует выполнить следующие действия в окне управления проектами GitLab:

1. В верхнем меню выбрать Поиск или перейти к разделу Найти проект;

2. Выбрать команду Настройки >CI/CD;

3. Развернуть блок Runners;

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

5. У поле Ярлык нужно ввести через запятую теги задач;

6. Отключить опцию Запускать задачи без меток;

7. Нажать кнопку Сохранить изменения.

В свою очередь, теги для работа-ов прописываются в файле .gitlab-in.yml, например

job:

  tags:
- ruby
- macos
- postgres

Это означает, что задача будет выполняться только теми раннерами, для которых прописаны те же теги. Runner может иметь и другие теги, но присутствие указанных является обязательным. В противном случае, job «зависнет» и никогда не выполнится.

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

Установка и настройка

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

Разобьем процесс на несколько этапов.

Выполнение базовых настроек VPS-серверов

Обновим индекс пакетов и выполним обновление системы:

$ sudo apt update && sudo apt upgrade -y
Создадим отдельного пользователя и добавим его в группу судо:
$ adduser pipeline_user
$ usermod -aG sudo pipeline_user

Настроим SSH:

$ sudo nano /etc/ssh/sshd_config
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, включить опцию специфический (проектный Runner) и ввести теги в соответствии с заданиями, которые будут выполняться, например, это могут быть теги docker и php.

Пример файла .gitlab-in.yml

На завершающей стадии подготовки пайплайна следует создать новый проект в нашем GitLab и добавить в корень репозитория файл с именем .gitlab-in.yml.

Размещен в .gitlab-in.yml сценарий может быть следующим:

Само собой, теги 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.

Смотрите наш канал Youtube на https://www.youtube.com/freehostua.

Мы в чем ошиблись, или что-то пропустили?

Напишите об этом в комментариях, мы с удовольствием ответим и обсудим Ваши замечания и предложения.

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

Голосование 1 2 3 4 5