Установка и регистрация GitLab Runner

В статье расскажу про установку и регистрацию GitLab Runner, рассмотрев некоторые проблемы, с которыми возможно придется столкнуться. Для новичков могут быть интересны также некоторые теоретические концепы, на рассмотрение которых я обязательно буду давать ссылки.


Хочется задать вопросы или поделиться знаниями? Приходи в наш закрытый Telegram-чат.


Установка и регистрация GitLab Runner

Инструкция ниже актуальна для Centos 7.

Предварительные требования

Было бы странно не воспользоваться функционалом Docker в задачах CI/CD, а потому первым делом займемся его установкой. Поставить наиболее свежую версию можно с помощью официальной инструкции – Install Docker Engine on CentOS (доступна и для других дистрибутивов). Если версия вам не важна, просто выполните команду:

Но надо включить автозагрузку и запустить демон, потому что по умолчанию он остановлен:

Теперь переходим непосредственно к установке приложения GitLab Runner.

Установка

Установка доступна с помощью пакетов или путем простого скачивания исполняемого файла. Я остановлюсь на последнем варианте. Помимо официального ресурса – Install GitLab Runner manually on GNU/Linux – инструкция доступна также на вашем экземпляре GitLab. Для этого нужно зайти в проект (или группу, если ваши проекты объединены логически), далее Settings / CI/CD / Runners. Слева увидите следующее:

Установка и регистрация GitLab Runner

Нажимайте на Show Runner installation instructions и увидите пошаговую инструкцию. Очень удобно. А теперь выполним её по порядку.

Выкачиваем бинари:

Выставляем права на исполнение:

Добавляем пользователя:

Устанавливаем раннер и сразу его запускаем:

Сохраняем токен (см. на скриншоте выше) на будущее:

Он понадобится на следующем этапе.

Регистрация

Теперь пришло время зарегистрировать раннеры. Для одного хоста может быть зарегистрировано множество раннеров, но например с разными исполнителями (executors 1). Перерегистрировать можно многократно, при этом не забывая удалять их в интерфейсе GitLab, если они вдруг стали не нужны или вы хотите изменить их область действия (например сделать доступными для конкретного проекта, а не для группы).

Примечание: например может потребоваться сделать отдельные раннеры для конкретного проекта, а не для группы проектов. Или появится потребность в расшаренных раннерах. Подробнее читайте в статье The scope of runners.

Итак, приступим:

Команды две, поскольку мы регистрируем два исполнителя на одном раннере. Некоторые задачи лучше выполнять напрямую в оболочке хоста (например сборку докер-образов), а для других постоянно будет требоваться дополнительное ПО и тогда логично запускать задачи внутри докер-контейнеров

Примечание: на счет сборки докер-образов есть разные мнения. С одной стороны подход docker-in-docker достаточно распространен и это видно из документации – Use the Docker executor with the Docker image (Docker-in-Docker) – а с другой есть очень много подводных камней – Хорошо подумайте, прежде чем использовать Docker-in-Docker для CI или тестовой среды. Вернемся к основной теме статьи.

На самом хосте информация о конфигурации раннеров доступна в файле /etc/gitlab-runner/config.toml. Вот его пример:

Регистрация исполнителей проста, но не всегда может пойти по плану.

Certificate signed by unknown authority

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

Если сертификат самозаверенный, то его легко прочитать и сразу скопировать в локальное хранилище доверенных сертификатов:

Сложнее будет, если сертификат GitLab содержит в себе промежуточные. В таком случае придется их склеивать вместе, совсем как описано в официальной статье 2:

Ну а после этих манипуляций перечитайте сертификаты из хранилища:

Выполнять описанные действия придется для каждого хоста, который планируется использовать для запуска раннеров, а потому лучше их автоматизировать в виде роли Ansible. Благо уже есть готовый модуль 3. Если нет опыта с Ansible, могу помочь изучить и подсказать сценарии использования.

Яндекс.Метрика