Как настроить CI/CD GitLab Runner на облачном сервере
Практическое руководство по развертыванию собственного исполнителя GitLab Runner в облаке. Рассматриваем настройку виртуальной машины, ручную установку deb-пакетов, регистрацию раннера через токен и запуск первого пайплайна.
Разработка программного обеспечения — многоступенчатый процесс проектирования, написания кода и тестирования продукта. Часть шагов можно автоматизировать с помощью процессов непрерывной интеграции (CI) и непрерывной доставки (CD).
В этом материале расскажем про установку Gitlab Runner — исполнителя пайплайнов в среде совместной разработки Gitlab.
Gitlab — это платформа для совместной разработки ПО, в основе которой лежат Git-репозитории. Помимо простого управления репозиториями, Gitlab позволяет выполнять автоматические однотипные действия, например, собирать «ночные сборки» программного обеспечения и выполнять автотесты для каждого коммита. За это отвечает компонент GitLab CI/CD. Последовательность действий в CI/CD называется пайплайном (pipeline), а один шаг пайплайна – джобой (job).
По умолчанию Gitlab использует собственное оборудование для запуска пайплайнов. В бесплатном тарифном плане ежемесячно дается 400 минут вычислительного времени, а премиум-подписка расширяет это ограничение до 10 000 минут в месяц.
Если этого недостаточно, есть альтернатива — развернуть собственный сервер и запустить GitLab Runner. В этом случае число пайплайнов ограничено только вычислительной мощностью вашего сервера.
GitLab Runner можно подключить как к gitlab.com, так и к self-hosted версиям GitLab. Сегодня рассмотрим подключение к облачному GitLab.
Подготовка инфраструктуры
Gitlab Runner не предъявляет особых требований к аппаратному обеспечению сервера. Выбор конфигурации напрямую зависит от сложности пайплайнов и количества параллельных задач.
Более того, Gitlab Runner запускается не только на Linux, но и на macOS, FreeBSD, Windows и z/OS. Также поддерживаются восемь архитектур, от ожидаемых x86 и AMD64 до ARM, RISC-V и даже IBM-мейнфреймов.
В облаке Selectel действует модель оплаты Pay-as-You-Go — средства списываются только за фактическое потребление ресурсов, поэтому брать их «про запас» нет смысла. В любой момент можно добрать необходимое за пару кликов в панели управления.
Масштабирование работает и в обратную сторону: если нагрузка спадет, можно вернуть неиспользуемые ресурсы в облако и не переплачивать.
Начнем с сервера конфигурации 1 vCPU, 2 GB RAM, 50 GB SSD.
Заходим в панель управления Selectel: Продукты → Облачные серверы → Создать сервер. Выбираем 1 vCPU, 2 GB RAM, 50 GB Универсальный SSD и Ubuntu 26.04 в Санкт-Петербурге, ru-9a.
В этой версии Ubuntu SSH-ключ обязателен, поэтому добавляем свой ключ. Когда вся информация заполнена, нажимаем Создать сервер. После появления сервера в его карточке будет инструкция по подключению. Проверяем.
$ ssh root@136.234.X.X
# Удалено для краткости
Welcome to Ubuntu 26.04.1 LTS (GNU/Linux 7.0.0-38-generic x86_64)
# Удалено для краткости
root@runner:~#
Сервер доступен.
Развертывание Gitlab Runner
Runner можно развернуть «на железе» и в контейнерах. Для развертывания «на железе» доступна установка отдельного пакета или установка через репозитории. Для контейнеризации доступны Docker-контейнер, Helm Chart, Agent и Operator для Kubernetes.
Для демонстрации простоты установки выберем наименее автоматизированный путь — установку отдельного пакета. При заказе сервера отмечено, что конфигурации на процессорах AMD, отсюда понимаем, что архитектура процессора — amd64. Иногда ее называют x86_64 (это значение видно в выводе команды uname -a), но GitLab понимает только amd64.
Скачиваем пакет, подставляя архитектуру по шаблону gitlab-runner_${arch}.deb:
curl -LJO "https://s3.dualstack.us-east-1.amazonaws.com/gitlab-runner-downloads/latest/deb/gitlab-runner-helper-images.deb"
curl -LJO "https://s3.dualstack.us-east-1.amazonaws.com/gitlab-runner-downloads/latest/deb/gitlab-runner_amd64.deb"
Устанавливаем скачанные пакеты:
dpkg -i gitlab-runner-helper-images.deb gitlab-runner_amd64.deb
Для работы GitLab Runner нужна единственная зависимость — git. Если она уже есть в системе, то пакеты успешно установятся. Если же ее нет, то пакетный менеджер сообщит об этом:
dpkg: dependency problems prevent configuration of gitlab-runner:
gitlab-runner depends on git; however:
Package git is not installed.
Ошибка исправляется одной командой:
apt --fix-broken install
GitLab Runner установлен. Осталось связать его с проектом в GitLab.
Подключение к Gitlab
В левом меню переходим в Build → Runners в левом меню и нажимаем Create Group Runner.
Настройки раннера минимальны: можно задать теги, по которым runner будет выбирать себе задания, или разрешить принимать неразмеченные задания. Также можно сделать выделенный runner для защищенных веток или вовсе временно приостановить его работу при создании, чтобы он не брал джобы до завершения настройки.
После создания «карточки» нужно связать процесс на сервере с GitLab. Для этого выполняем команду, которая передает URL сервера и секретный токен (команда указана на странице регистрации). Токен не следует передавать третьим лицам, поэтому в статье он обрезан:
gitlab-runner register --url https://gitlab.com --token glrt-Ogchk0qL9W...
При выполнении этой команды gitlab-runner попросит уточнить конфигурацию.
root@runner:~# gitlab-runner register --url https://gitlab.com --token glrt-Ogchk0qL9WM…
Runtime platform arch=amd64 os=linux pid=1681 revision=66ad5002 version=19.5.2
Running in system-mode.
Enter the GitLab instance URL (for example, https://gitlab.com/):
[https://gitlab.com]:
Verifying runner... is valid correlation_id=a542785d8994de0d-HEL runner=Ogchk0qL9 runner_name=runner
Enter a name for the runner. This is stored only in the local config.toml file:
[runner]: runner-vm
Enter an executor: parallels, custom, instance, docker-windows, virtualbox, shell, docker, docker-autoscaler, docker+machine, kubernetes, ssh:
shell
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!
Configuration (with the authentication token) was saved in "/etc/gitlab-runner/config.toml"
Наиболее важный параметр конфигурации — режим выполнения (executor). Он определяет, в каком окружении будут выполняться задания из GitLab. В статье выбран shell, в этом случае все команды исполняются непосредственно в операционной системе, где установлен gitlab-runner.
shell является наиболее простым и понятным режимом запуска заданий, однако исполняемые задания имеют доступ к серверу и слабо изолированы друг от друга. Это может привести к конфликтам при параллельном выполнении. Этот способ подходит для сборки ОС-специфическими инструментами, например, на Windows или macOS.
Второй «простой» режим выполнения — docker. Каждое задание будет изолированно запускаться в собственном контейнере. Однако это потребует установки Docker на сервер. Несмотря на удобство изоляции, Docker-контейнеры ограничены ОС Linux, а запуск Docker внутри задания в этом режиме потребует настойки Docker-in-Docker (DinD).
Универсального режима нет: выбор полностью зависит от выполняемых задач и действующих политик безопасности.
После регистрации статус раннера можно увидеть на странице Build → Runners. Обратите внимание на идентификатор #58254123 (Ogchk0qL), это пригодится позже.
Теперь заходим в настройки проекта: Settings → CI/CD и отключаем переключатель Enable instance runners for this group. Этим действием мы отказываемся от «официальных» раннеров GitLab. Воспользоваться ими все равно не получится: GitLab требует идентификацию по иностранному номеру телефона.
Теперь можем проверить работоспособность.
Тестирование
Создаем в корне репозитория файл .gitlab-ci.yml такого содержания:
stages:
- test
- build
test:
stage: test
script:
- echo "Hello from GitLab Runner!"
- echo "Runner is working!"
- echo "Hostname:"
- hostname
- echo "Test passed!"
build:
stage: build
script:
- echo "Starting build..."
- mkdir -p dist
- echo "Hello GitLab CI" > dist/result.txt
- cat dist/result.txt
- echo "Build completed!"
artifacts:
paths:
- dist/
expire_in: 1 day
Выполняем git commit и git push.
Успешно выполненное задание.
Если все сделано правильно, задания пайплайна будут выполнены на развернутом нами GitLab Runner. Это идентифицируется по имени хоста (hostname) runner и по идентификатору #58254123 (Ogchk0qL) в правом меню.
