Установка и регистрация gitlab-runner в docker контейнере

Gitlab-runner — это программа — агент, которая выполняет инструкции указанные в файлах .gitlab-ci.yml ваших репозиториев. Проще говоря — агент, который выполняет инструкции ваших pipeline, без которого вам не обойтись, если вы настраиваете ci\cd своего проекта, с помощью gitlab.

Прежде чем вы сможете использовать всю мощь gitlab-ci, вам нужно будет установить и зарегистрировать ваш(и) gitlab-runner в gitlab, будь то ваш персональный инстанс или gitlab.com

Перейдем к установке и настройке

Прежде всего вам потребуется установить docker, как это сделать я уже писал ранее в статье: Установка Docker в Linux

После установки Docker приступаем к установке gitlab-runner, который будет крутится в docker контейнере, выполняем в терминале:

docker run -d --name gitlab-runner --restart always \
  -v /srv/gitlab-runner/config:/etc/gitlab-runner \
  -v /var/run/docker.sock:/var/run/docker.sock \
  gitlab/gitlab-runner:latest

Как только процедура загрузки образа и запуска контейнера закончится — переходим к регистрации. Выполняем команду:

docker exec -it gitlab-runner gitlab-runner register

Вы увидите приглашение для ввода URL вашего gitlab инстанса

Вводим адрес вашего гитлаб

https://your-gitlab-url.com

Следующим шагом вас попросят ввести registration token, получить его можно в админке гитлаб, в разделе runners.

Переходим Menu — Admin — Runners и жмем на синюю кнопку Register an instance runner

Копируем и вставляем в консоль.

Далее он по порядку предложит ввести вам:

• Enter a description for the runner: Вводим произвольное описание, или оставляем пустым
• Enter tags for the runner (comma-separated): Вводим тег(и) для вашего ранера, нужны для запуска тегированных заданий и разделения ранеров по ролям. Можно оставить пустым и заполнить потом в интерфейсе самого gitlab
• Enter optional maintenance note for the runner: это поле в общем случае должно содержать информацию относящуюся к другим разработчикам управляющим этим ранером. Например характеристики системы (ЦПУ\ОЗУ\ОС). Но в большинстве случаев это поле никто не заполняет. Оставляем пустым.
• Enter an executor: docker+machine, kubernetes, custom, docker-ssh, shell, virtualbox, docker, parallels, ssh, docker-ssh+machine: вводим docker. Выбор способа выполнения вашего pipeline.
  • docker+machine — Предназначен больше для облачных решений и ЦОД. Создает виртуальные машины, устанавливает на них docker, и настраивает docker клиент для дальнейшей работы
  • kubernetes — использует для сборок кластер kubernetes, подключаясь к kubernetes API
  • custom — как следует из названия — custom executor, нужен для работы со средами, которые гитлаб не поддерживает «нативно», например Подман
  • docker-ssh — с версии 10 висит в deprecated, устарел и скоро будет выпилен
  • shell — как из названия — выполняет все действия локально на машине, не подходит для использования gitlab-runner в docker контейнере. Бывает полезен в некоторых случаях, когда вам нужно внести изменения непосредственно в самой системе, или если у вас монолитное, не микросервисное, приложение.
  • virtualbox — создает из образа или снапшота виртуальную машину в vitrualbox, подключается к ней по ssh и выполняет действия указанные в .gitlab-ci.yml. По завершении машина удаляется
  • docker — Подключается к docker-engine машины и выполняет все действия в изолированных контейнерах, которые по окончании уничтожаются (наиболее удобный вариант)
  • parallels — работает аналогично virtualbox, только в качестве виртуализации использует parallels
  • ssh — не поддерживает сборочные кэши, выполняет сборки на удаленных машинах. Поддерживает только bash команды
  • docker-ssh+machine — как и docker-ssh устарел и будет выпелен.
• Enter the default Docker image (for example, ruby:2.7): указываем используемый образ по умолчанию. Пишем docker:latest

В результате вы должны увидеть сообщение об успешной регистрации gitlab-runner

А так же в админке, в разделе runners вы увидите ваш новый gitlab-runner

Для сборок docker-in-docker

Для сборки docker-in-docker, которую я очень рекомендую использовать, в связи с тем, что такой способ не оставляет кучи мусора на машине, рекомендую заново добавить docker.sock в runner volume. Иначе при сборке вы получите сообщение что docker не найден. Для этого:

Переходим в каталог с конфигурационным файлом docker-runner

cd /srv/gitlab-runner/config

Открываем для редактирования config.toml и приводим переменную volume к такому виду и сохраняем:

volumes = ["/cache", "/var/run/docker.sock:/var/run/docker.sock"]

Остается только перезапустить контейнер командой:

docker restart gitlab-runner

Полезные материалы по теме:

• Установка Gitlab в Docker
• Установка shell gitlab runner
• Обновление Gitlab развернутого в Docker
• Переменные Gitlab-Ci
• Настройка работы Gitlab с registry без ssl
• Установка и регистрация gitlab-runner в docker контейнере
• Шпаргалка по работе с Docker
• Установка Docker в Linux
• Gitlab runner reference