UMGUM.COM 

GitLab Runner + SSL error ( Обходное решение проблемы с невозможностью повторного подключения "runner"-а к серверу "GitLab". )

2 апреля 2019

OS: "Linux Ubuntu 18.04.1 LTS (Bionic Beaver)".
Apps: "GitLab Runner v10.1+ (до v10.5 точно)".

Задача: решить проблему с невозможностью повторного, в рамках сеанса, подключения "runner"-а к серверу "GitLab".


Начиная с "v10.1" (и до "v10.5" включительно, а может и далее) CI/CD-агент "GitLab Runner" стал сбоить при повторном подключении к серверу "GitLab" - на этапе актуализации уже полученного репозитория запросом "git fetch". Сбой прерывал последовательную отработку "pipelines" и сопровождался сообщениями об ошибке доступа к SSL-сертификату, подписывающему сеанс связи с сервером хранения репозитория:

Running with gitlab-runner 10.5.0
....
fatal: unable to access 'https://gitlab-ci-token:xx...xx@gitlab.example.net/group/repo.git/': Problem with the SSL CA cert (path? access rights?)
ERROR: Job failed: exit status 1

Недолгое расследование выявило, что проблема заключается в дублировании части пути в файловой системе к SSL-сертификату, зафиксированном в динамически формируемом конфигурационном файле загруженного "runner"-ом Git-репозитория, объединяющем в себе настройки как самого репозитория, так и агента:

# cat /var/tmp/build/.builds/1234567/0/group/repo/.git/config

....
[http "https://gitlab.example.net"]
  sslCAInfo = /var/tmp/build/.builds/1234567/0/group/repo/.builds/1234567/0/group/repo.tmp/CI_SERVER_TLS_CA_FILE
....

Можно заметить, что указанный в конфигурационном файле путь к сертификату отличается от реального лишними строчными данными "/.builds/1234567/0/group/repo".

Сразу приходит в голову попробовать вырезать из строки лишнее на каком-то этапе отработки "pipelines" - но это грубое вмешательство в работу приложения, о котором нужно будет помнить при каждом обновлении конфигурации, и оно будет незаметно непосвящённым.

Поиски более практичного решения показали, что аутентификация посредством SSL-сертификата используется только для уточняющих (повторных) запросов "git fetch" - то есть она не является обязательной, после уже проведённой проверки регистрации "runner"-а по выделенному ему "токену". Если схема локальна, доступ к серверам ограничен и осуществляется по HTTPS/SSH, то можно просто отказаться от дополнительной проверки подлинности при повторных обращениях к центральному репозиторию, взведя в YAML-файле автоматизации соответствующий флаг:

$ vi .gitlab-ci.yml

variables:
  # (bypass bug "git fetch": "problem with the SSL CA cert path")
  GIT_SSL_NO_VERIFY: true
....

Как я упомянул выше, дополнительная аутентификация SSL-сертификатом запрашивается только при актуализации загруженного уже репозитория посредством "git fetch". Отсюда для репозиториев небольших объёмов напрашивается второй вариант обхода проблемы - самым топорным образом принудительно перевести "runner" в режим загрузки полной копии данных посредством "git clone" на каждом этапе автоматизации, без использования "git fetch":

$ vi .gitlab-ci.yml

variables:
  # (bypass bug "git fetch": "problem with the SSL CA cert path")
  GIT_STRATEGY: clone
....

Оба приведённых варианта работают, и до поры можно ими пользоваться. Насколько я уловил, в "GitLab Runner v11+" ошибку сохранения некорректного пути к SSL-сертификату исправили, но на стабильных системах до сих пор эксплуатируется "v10.x".


Заметки и комментарии к публикации:


Оставьте свой комментарий ( выразите мнение относительно публикации, поделитесь дополнительными сведениями или укажите на ошибку )