В статье расскажу про установку и регистрацию GitLab Runner, рассмотрев некоторые проблемы, с которыми возможно придется столкнуться. Для новичков могут быть интересны также некоторые теоретические концепы, на рассмотрение которых я обязательно буду давать ссылки.
Хочется задать вопросы или поделиться знаниями? Приходи в наш закрытый Telegram-чат.
Содержание
Установка и регистрация GitLab Runner
Инструкция ниже актуальна для Centos 7.
Предварительные требования
Было бы странно не воспользоваться функционалом Docker в задачах CI/CD, а потому первым делом займемся его установкой. Поставить наиболее свежую версию можно с помощью официальной инструкции – Install Docker Engine on CentOS (доступна и для других дистрибутивов). Если версия вам не важна, просто выполните команду:
1 |
yum install docker |
Но надо включить автозагрузку и запустить демон, потому что по умолчанию он остановлен:
1 2 |
systemctl enable docker systemctl start docker |
Теперь переходим непосредственно к установке приложения GitLab Runner.
Установка
Установка доступна с помощью пакетов или путем простого скачивания исполняемого файла. Я остановлюсь на последнем варианте. Помимо официального ресурса – Install GitLab Runner manually on GNU/Linux – инструкция доступна также на вашем экземпляре GitLab. Для этого нужно зайти в проект (или группу, если ваши проекты объединены логически), далее Settings / CI/CD / Runners. Слева увидите следующее:
Нажимайте на Show Runner installation instructions и увидите пошаговую инструкцию. Очень удобно. А теперь выполним её по порядку.
Выкачиваем бинари:
1 |
curl -L --output /usr/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64 |
Выставляем права на исполнение:
1 |
chmod +x /usr/bin/gitlab-runner |
Добавляем пользователя:
1 |
useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash |
Устанавливаем раннер и сразу его запускаем:
1 2 |
gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner gitlab-runner start |
Сохраняем токен (см. на скриншоте выше) на будущее:
1 |
REGISTRATION_TOKEN="wbsAQsH5TviZSXocoBLs" |
Он понадобится на следующем этапе.
Регистрация
Теперь пришло время зарегистрировать раннеры. Для одного хоста может быть зарегистрировано множество раннеров, но например с разными исполнителями (executors 1). Перерегистрировать можно многократно, при этом не забывая удалять их в интерфейсе GitLab, если они вдруг стали не нужны или вы хотите изменить их область действия (например сделать доступными для конкретного проекта, а не для группы).
Итак, приступим:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
gitlab-runner register \ --url https://gitlab.domain.com/ \ --registration-token $REGISTRATION_TOKEN \ --executor shell \ --tag-list "shared,shell" \ --description shell-executor-01 gitlab-runner register \ --url https://gitlab.domain.com/ \ --registration-token $REGISTRATION_TOKEN \ --executor docker \ --tag-list "shared,docker" \ --docker-image "ansible/ansible" \ --description docker-executor-01 |
Команды две, поскольку мы регистрируем два исполнителя на одном раннере. Некоторые задачи лучше выполнять напрямую в оболочке хоста (например сборку докер-образов), а для других постоянно будет требоваться дополнительное ПО и тогда логично запускать задачи внутри докер-контейнеров
На самом хосте информация о конфигурации раннеров доступна в файле /etc/gitlab-runner/config.toml. Вот его пример:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
concurrent = 1 check_interval = 0 [session_server] session_timeout = 1800 [[runners]] name = "shell-runner-01" url = "https://gitlab.domain.com/" token = "wbsAQsH5TviZSXocoBLs" executor = "shell" [runners.custom_build_dir] [runners.cache] [runners.cache.s3] [runners.cache.gcs] [runners.cache.azure] [[runners]] name = "docker-runner-01" url = "https://gitlab.bissquit.com/" token = "wbsAQsH5TviZSXocoBLs" executor = "docker" [runners.custom_build_dir] [runners.cache] [runners.cache.s3] [runners.cache.gcs] [runners.cache.azure] [runners.docker] tls_verify = false image = "ansible/ansible" privileged = false disable_entrypoint_overwrite = false oom_kill_disable = false disable_cache = false volumes = ["/cache"] shm_size = 0 |
Регистрация исполнителей проста, но не всегда может пойти по плану.
Текст из названия главы вы можете встретить в ошибке, которая вылезет в ответ на выполнение запроса о регистрации раннера на вашем экземпляре GitLab, если он использует сертификат от недоверенного источника (самозаверенный сертификат или подписанный локальным центром сертификации). Полный текст ошибки:
1 2 |
ERROR: Registering runner... failed runner=jPf_3Qj1 status=couldn't execute POST against https://gitlab.domain.com/api/v4/runners: Post https://gitlab.domain.com/api/v4/runners: x509: certificate signed by unknown authority PANIC: Failed to register the runner. You may be having network problems. |
Если сертификат самозаверенный, то его легко прочитать и сразу скопировать в локальное хранилище доверенных сертификатов:
1 |
openssl s_client -connect gitlab.domain.com:443 -showcerts </dev/null 2>/dev/null | sed '/-----BEGIN/,/-----END/!d' > /etc/pki/ca-trust/source/anchors/gitlab-domain-com.crt |
Сложнее будет, если сертификат GitLab содержит в себе промежуточные. В таком случае придется их склеивать вместе, совсем как описано в официальной статье 2:
1 2 3 4 5 6 7 8 9 |
-----BEGIN CERTIFICATE----- (Your primary SSL certificate) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- (Your intermediate certificate) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- (Your root certificate) -----END CERTIFICATE----- |
Ну а после этих манипуляций перечитайте сертификаты из хранилища:
1 |
update-ca-trust |
Выполнять описанные действия придется для каждого хоста, который планируется использовать для запуска раннеров, а потому лучше их автоматизировать в виде роли Ansible. Благо уже есть готовый модуль 3. Если нет опыта с Ansible, могу помочь изучить и подсказать сценарии использования.