Настройка CI/CD в GitLab для синхронизации проекта с веб-серверами

Обновлено Обновлено: Опубликовано Опубликовано:

Используемые термины: GitLab, CI/CD, веб-сервер, Linux.

Runner в GitLab позволяют автоматизировать рутинные задачи при обновлении проектов в репозитории. В нашем примере мы рассмотрим ситуацию, когда у нас используется сервер GitLab для хранения проекта и 5 веб-серверов, куда должны попадать изменения после выполнения git push. Мы настроим наш CI/CD на синхронизацию файлов с помощью rsyncd. Предполагается, что у нас уже установлен GitLab на Linux, в противном случае, воспользуйтесь инструкцией для Ubuntu или CentOS.

Нам потребуется выполнить:

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

Runner — это отдельное приложение, которое запускается для выполнения заданий CI/CD. Его можно установить любой компьютер под управлением любой популярной операционной системы (Linux, Windows, BSD, Mac OS и так далее). Также доступны различные варианты установки — из репозитория, скачивание бинарника или запуск как приложения в Docker или кластере Kubernetes. Мы выполним установку из репозитория Linux на тот же сервер, где работает наш GitLab.

Установка

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

а) система на базе deb-пакетов (Debian / Ubuntu):

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

б) система на базе RPM-пакетов (Red Hat / CentOS):

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

После настройки репозитория, выполняем установку. Команда также зависит от типа операционной системы.

а) для Debian / Ubuntu:

apt-get install gitlab-runner

б) для Red Hat / CentOS:

yum install gitlab-runner

После установки gitlab-runner разрешаем автозапуск сервиса и стартуем его:

systemctl enable gitlab-runner --now

Регистрация

Для корректной работы Runner его нужно связать с нашим проектом в GitLab. Для этого сначала заходим на портал последнего - переходим на страницу проекта - в меню слева выбираем Settings - CI / CD:

Переходим к настройкам CI/CD нашего проекта

Находим раздел Runners:

Находим Runners в настройках CI/CD проекта

Справа от названия кликаем по Expand:

Раскрываем настройки для раннеров

Находим параметры для регистрации нового раннера:

Находим параметры для регистрации Runner

... и оставляем страницу открытой — она понадобиться на следующем шаге.

В командной строке нашего сервера GitLab вводим:

gitlab-runner register

* установить и запустить Runner можно не только на локальном сервере GitLab, но мы рассмотрим только данный способ.

Система в интерактивном режиме запросит данные для регистрации — вводим их:

Enter the GitLab instance URL (for example, https://gitlab.com/):
https://gitlab.dmosk.ru/
Enter the registration token:
zX_Kvkxk7ywrgwYHsod5
Enter a description for the runner:
[git-server.dmoks.ru]: DMOSK Metrics API
Enter tags for the runner (comma-separated):
dmosk, metrics, api
Registering runner... succeeded                     runner=zX_Kvkxk
Enter an executor: parallels, virtualbox, docker+machine, docker-ssh+machine, kubernetes, custom, docker, docker-ssh, shell, ssh:
shel

* где:

  • https://gitlab.dmosk.ru/ — адрес нашего сервера GitLab. Его можно увидеть на странице с параметрами, которую мы оставили открытой на предыдущем шаге. В моем случае, на данной странице ссылка была типа http, однако, при регистрации Runner мы ее должны поменять на https (если наш сервер использует его).
  • zX_Kvkxk7ywrgwYHsod5 — токен для регистрации раннера. Его смотрим на странице с параметрами, которые мы открывали выше.
  • DMOSK Metrics API — произвольное описание для нашего раннера.
  • dmosk, metrics, api — теги. Рекомендуется максимально точно описывать раннер тегами.
  • shell — выбираем исполнителя из предложенных вариантов. В нашем случае это просто командный интерпретатор.

В конце мы должны увидеть:

Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

* если мы получим ошибку «status couldn execute post against certificate signed by unknown authority», переходим к решению ниже.

Обновим страницу с параметрами для регистрации раннера — ниже мы должны увидеть, что у нас появился один новый элемент. Кликаем по изображению редактирования справа от токена:

Переходим к редактированию только что созданного раннера

Выставляем следующие галочки для настройки Runner:

Настраиваем Runner

* где:

  • Paused Runners don't accept new jobs — если наш обработчик заданий приостановлен, он не принимает новые задания.
  • This runner will only run on pipelines triggered on protected branches — Runner должен запускаться только на защищенных ветках.
  • Indicates whether this runner can pick jobs without tags — раннер может запускать задания без тегов.
  • When a runner is locked, it cannot be assigned to other projects — если обработчик заблокирован, его нельзя назначать для других проектов.

И так, обработчик зарегистрирован и настроен. Переходим к созданию CI/CD.

Создание CI/CD для проекта

На первоначальном этапе, мы создадим простой сценарий, который просто будет выводить путь до каталога на сервере, в котором находится проект.

Переходим в GitLab на страницу проекта и кликаем по Set up CI/CD:

На странице проекта нужно кликнуть по Set up CI/CD

* данной кнопки может и не быть.

... или можно просто в корне проекта создать файл:

vi .gitlab-ci.yml

Задаем содержимое нашего сценария:

stages:
  - test

test:
  stage: test
  script: echo $CI_PROJECT_DIR/

* Из расширения файла понятно, что формат текста должен быть yml, а значит, отступы имеют значения. В данном примере мы создаем pipeline с одним единственным этапом, которое называется test. По данному заданию будет запускаться скрипт вывода значения переменной $CI_PROJECT_DIR — путь, по которому клонируется проект и где выполняется задание (если установлен $builds_dir, эта переменная устанавливается относительно данного значения. Список возможных переменных можно посмотреть на официальном сайте в разделе документации GitLab CI/CD environment variables.

После сохранения файла ждем несколько секунд и перезапускаем страницу — мы должны увидеть успешный результат выполнения сценария CI/CD:

Задание CI/CD выполнено успешно

Кликнем по значку зеленой галочки и в открывшейся странице кликаем по нашей единственной стадии:

Кликаем по названию нашей стадии pipeline

Мы должны увидеть ход процесса выполнения задания и результат его работы:

Наш CI/CD показал нампуть до каталога на сервере, где хранится проект

На этой же странице справа можно вручную запустить задание еще раз:

Повторяем запуск задания

CI/CD создан. Теперь необходимо подготовить систему к синхронизации данных.

Настройка Rsyncd

Наша синхронизация будет выполняться с помощью Rsyncd. Это удобный инструмент, с помощью которого можно поддерживать актуальное состояние двух и более каталогов. Также у нас не возникнет проблем с правами — rsync после копирования будет задавать файлам нужного владельца и нам не нужно будет выдавать права root для runner с помощью файла sudoerst. Подробнее об установке и настройке Rsyncd.

Настройки нужно выполнить как на веб-серверах, так и сервере с GitLab.

Настройка на веб-серверах

Данные действия нужно выполнить на каждом веб-сервере. Мы должны установить и настроить в качестве сервиса rsyncd. Сначала установим его. В зависимости от типа Linux, наши действия будут различаться.

а) Ubuntu / Debian:

apt-get install rsync

Открываем следующий файл:

vi /etc/default/rsync

Находим запись:

RSYNC_ENABLE=false

И меняем на:

RSYNC_ENABLE=true

Запускаем:

systemctl enable rsync

systemctl start rsync

б) CentOS 7

yum install rsync

systemctl enable rsyncd --now

в) CentOS 8

yum install rsync rsync-daemon

systemctl enable rsyncd --now

После установки и запуска rsyncd, открываем его конфигурационный файл:

vi /etc/rsyncd.conf

И добавим в него следующие настройки: 

max connections = 10
exclude = lost+found/ .gitlab-ci.yml
dont compress   = *.gz *.tgz *.zip *.z *.Z *.rpm *.deb *.bz2 *.rar *.7z *.mp3 *.jpg

[dmosk]
    path = /var/www/dmosk/www/
    comment = Site dmosk.ru
    uid = apache
    gid = apache
    read only = no
    list = yes
    auth users = rsync_dmosk
    secrets file = /etc/rsyncd.scrt
    hosts allow = localhost 192.168.0.10
    hosts deny = *

* наибольший интерес для нас имеют следующие опции:

  • [dmosk] — название для экземпляра синхронизации. К нему мы будем обращаться при выполнении команды rsync.
  • path — путь до каталога, в котором находятся файлы для синхронизации. Это путь до папки проекта на самом веб-сервере.
  • uid/gid — пользователь и группа, от которых будет выполнена синхронизация для конкретного ресурса. Именно они будут назначены в качестве владельца файлов. 
  • auth users — проверка подлинности, вводом логина с паролем.
  • secrets file — файл, в котором размещены логин и пароль, который будет использоваться для проверки подлинности при выполнении синхронизации.
  • hosts allow — узлы, с которых разрешено подключение для синхронизации. Тут должен быть IP-адрес нашего сервера GitLab.

Создадим файл, в котором должны быть логин и пароль для проверки подлинности rsync:

vi /etc/rsyncd.scrt

rsync_dmosk:password

* в данном примере мы задали логин rsync_dmosk и пароль password.

Необходимо задать минимально необходимые права на файл с аутентификационными данными:

chmod 600 /etc/rsyncd.scrt

Можно перезапускать сервис:

systemctl restart rsyncd || systemctl restart rsync

Также необходимо создать правила в брандмауэре для разрешения TCP-порта 873, на котором работает rsyncd.

а) для систем на базе deb-пакетов (Ubuntu, Debian):

iptables -I INPUT 1 -p tcp --dport 873 -j ACCEPT

apt-get install iptables-persistent

netfilter-persistent save

б) для систем на базе RPM-пакетов (Red Hat, CentOS):

firewall-cmd --permanent --add-port=873/tcp

firewall-cmd --reload

Данные настройки выполняем на всех веб-серверах. После переходим к настройке сервера GitLab.

Настройка GitLab

На стороне сервера GitLab мы должны настроить подключение к сервисам rsyncd. Для начала устанавливаем rsync.

а) для систем на базе deb:

apt-get install rsync

б) для RPM-систем:

yum install rsync

После создаем файл, в котором будем хранить пароль для подключения к rsyncd:

vi /etc/rsyncd.scrt

password

* это тот пароль, который мы задали в аналогичном файле на стороне веб-серверов.

Задаем права минимально необходимые для чтения файла с паролем:

chmod 640 /etc/rsyncd.scrt

Задаем в качестве группы владельца файла с паролем нашего пользователя gitlab-runner:

chown :gitlab-runner /etc/rsyncd.scrt

Создаем файл, который отправим на серверы веб в качестве теста:

touch testfile

Выполняем команду для синхронизации данного файла с веб-серверами:

for i in 1 2 3 4 5; do rsync -rult --password-file=/etc/rsyncd.scrt testfile rsync_dmosk@web-0$i::dmosk; done

* обратите внимание, что в моем примере веб-серверы имеют имена web-01, web-02 и так далее, поэтому, чтобы не выполнять все 5 команд по отдельности, мы используем цикл, в котором подставляем разные цифры в названия серверов.

В итоге, на стороне веб-серверов должен появиться файл testfile. Теперь остается последний шаг — настроить созданный ранее CI/CD для синхронизации.

Настройка синхронизации в CI/CD

Переходим на страницу нашего проекта и кликаем по CI/CD configuration:

Переходим к настройке CI/CD нашего проекта

Чтобы открылся редактор, кликаем по Edit:

Открываем редактор для изменения CI/CD

Или из командной строки, можно открыть на редактирование наш файл .gitlab-ci.yml:

vi .gitlab-ci.yml

Меняем содержимое нашего файла:

stages:
  - copy

copy:
  stage: copy
  script: for i in 1 2 3 4 5; do rsync -rult --delete-after --exclude=.git/ --exclude=.gitlab-ci.yml --password-file=/etc/rsyncd.scrt $CI_PROJECT_DIR/ rsync_dmosk@web-0$i::dmosk; done

* мы заменили наш этап test на copy. В данном примере мы выполняем команду для запуска синхронизации с веб-серверами с помощью rsync. В качестве источника данных мы используем переменную $CI_PROJECT_DIR, в которой находится наш проект. В качестве экземпляра, куда синхронизируем данные используем dmosk.

Готово. Пробуем выполнить git push в наш проект. Данные должны разойтись по всем веб-серверам.

Возможные ошибки

status couldn execute post against certificate signed by unknown authority

Ошибка возникает при попытке зарегистрировать Runner, а при отправке curl-запроса на сервер:

curl https://gitlab.dmosk.ru

... мы получаем сообщение о неправильном сертификате:

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.

Причина: нужна полная цепочка сертификатов.

Решение: подробнее, процесс настройки https описан в инструкции Правильная настройка SSL в NGINX.

# Linux # Серверы # DevOps
Дмитрий Моск — частный мастер
Была ли полезна вам эта инструкция?

Да            Нет