Настройка, использование GitLab CI/CD

GitLab – это программный инструмент, созданный с целью хранения и управления репозиториями Git. Концепция непрерывной интеграции (Continuous Integration — CI) на примере использования GitLab CI/CD. Сервис Gitlab предоставляет возможность получить не только бесплатный приватный GIT репозиторий, но и бесплатный CI/CD.

Для самостоятельной установки ПО GitLab на свой сервер используйте ссылки официальную документацию. Основной функционал GitLab:

• Планирование и управление разрабатываемыми проектами;
• Создание, просмотр и управление кодом и данными проектов;
• Проверка кода благодаря автоматическому тестированию и отчетности;
• Мониторинг ресурсов и просмотр метрик;
• Использование готовых шаблонов моделей.

На этом список функционала не заканчивается. Это лишь основная часть, необходимая для понимания важности использования этого ПО в проектной деятельности. В этой статье будет рассмотрена настройка GitLab CI CD для тестового проекта.

Подразумевается что вы уже создали проект на GitLab.

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

Установить её в Linux можно из официальных репозиториев Gitlab.

Рассмотрим установку Runner для Debian/Ubuntu/Mint, в моем случае Debian 11 (bullseye):

curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash
apt install gitlab-runner

Будет добавлен пользователь gitlab-runner

gitlab-runner:x:999:999:GitLab Runner:/home/gitlab-runner:/bin/bash

Проверим состояние раннера и если нужно добавим runner в автозагрузку и сразу запустим

systemctl status gitlab-runner
systemctl enable --now gitlab-runner

Схема как работает Git раннер:

В репозитории на GitLab, для которого вы хотите настроить CI, выберите пункт меню Settings подменю CI/CD. Возле пункта Runners нажмите кнопку Expand.

Общие раннеры от GitLab можно отключить для того чтобы они вам не мешали и не забирали задачи у вашего раннера. Для этого под надписью Enable shared runners for this project установите значение выключателя в положение выключено.

Необходимая информация находится в левой части окна, в разделе Specific runners. Тут вам надо узнать URL сервиса и токен авторизации, с которыми нужно регистрировать раннер.

На сервер, на котором был установлен runner и выполните команду для регистрации раннера в Gitlab:

sudo gitlab-runner register

Программа запросит URL, token, которые вы узнали на GitLab в разделе Specific runners и попросит ввести описание и теги. Теги будут использоваться в будущем для того чтобы отправлять этому раннеру задания. Далее останется только выбрать способ выполнения команд. Для того чтобы просто запускать командную оболочку можно выбрать shell.

Для того чтобы убедится, что всё настроено и работает нормально выполните такую команду:

sudo gitlab-runner verify
...
Verifying runner... is alive

Она должна показать сообщение is_alive. Настройка gitlab runner на сервере завершена.

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

gitlab-runner verify --delete  --url https://gitlab.com/ --token H2RRJd

Скорей всего у вас раннер работать не будет. GitLab Runner при запуске в качестве службы запускает все сценарии оболочки от имени непривилегированного пользователя: gitlab-runner. Если вы хотите использовать команды системного уровня, например, apt-get вам нужно выполнить их с помощью sudo.

Зададим нужные привилегии пользователю gitlab-runner - добавим его в группу sudo и разрешим запуск команд без пароля:

usermod -aG sudo gitlab-runner

и меняем строки в файле /etc/sudoers, используя команду visudo

# visudo
 
#%sudo  ALL=(ALL:ALL) ALL
%sudo ALL=(ALL) NOPASSWD:ALL

Если нужно ограничит пользователя gitlab-runner в запуске команд, смотрите пример ниже

gitlab-runner ALL= (root) NOPASSWD: /usr/bin/mkdir
gitlab-runner ALL= (root) NOPASSWD: /usr/bin/touch

Создаем ключ SSH для пользователя gitlab-runner и добавляем в gitlab

su - gitlab-runner
ssh-keygen

Обновите страницу настроек CI на GitLab. Новый раннер должен появится в списке и кружок возле него должен быть зелёным.

Кликните по значку карандаша (Edit) возле раннера и выставьте такие настройки:

• Active - должно быть включено, иначе раннер не сможет выполнять задания;
• Protected - должно быть включено, для того чтобы раннер брал задания из всех веток, а не только защищённых;
• Run untagged jobs - должно быть включено, позволяет раннеру брать задачи без тегов;
• Lock to current projects - если включено, этот раннер доступен только для этого проекта.

Все остальные опции можно не трогать.

В файле gitlab-ci.yml описываются все задачи, а также команды, которые gitlab-runner будет выполнять на сервере. Вы можете создать его вручную или же, если такого файла ещё нет, то нажмите кнопку Editor в меню CI/CD вашего проекта.

Файл в формате YAML, поэтому отступы перед значениями очень важны.

stages: 
  - название_этапа_1
  - название_этапа_2
название_задачи_1-job
  stage: название_этапа_1
  script:
    - команда_1
    - команда_2

Раздел stages описывает этапы разворачивания приложения и очередность их выполнения. Затем описываются задачи, которые будут выполняться в рамках каждого этапа. У задачи должен быть указан этап: stage и script со списком команд, которые будут выполняться на сервере.

Во время разворачивания gitlab-runner автоматически создает на сервере (по умолчанию в домашней папке) директорию build, клонирует туда свежие исходники проекта и переходит в папку с исходниками. А дальше с помощью команд в секции script вы можете делать всё, что нужно с этими исходниками.

Сохраните этот файл. Для этого пролистайте вниз страницы и нажмите кнопку Commit Changes.

Простой пример gitlab-ci.yml создающий файлы. Параметр only жестко задает для какой ветки, какой код должен выполняться.

stages:          # List of stages for jobs, and their order of execution
  - master
  - develop
  - staging
 
master-job:       # This job runs in the build stage, which runs first.
  stage: master
  only:
    - master
  script:
    - echo "Compiling the code..."
    - echo `date +'%m/%d/%Y'` >> /tmp/master777
    - echo "Compile complete."
 
staging-job:      # This job runs in the deploy stage.
  stage: staging  # It only runs when *both* jobs in the test stage complete successfully.
  only:
    - staging
  script:
    - echo "Deploying application..."
    - echo `date +'%m/%d/%Y'` >> /tmp/staging
    - echo "Application successfully deployed."
 
develop-job:
  stage: develop
  only:
    - develop
  script:
    - echo "Deploying application..."
    - echo `date +'%m/%d/%Y'` >> /tmp/develop
    - echo "Application successfully deployed."

Если всё было сделано правильно, то ваш раннер получит эту задачу, склонирует исходники. Для того чтобы убедится что это всё произошло, в боковом меню выберите значок ракеты (CI/CD) а затем Pipelines.