Используемые термины: GitLab, CI/CD, веб-сервер, Linux.
Runner в GitLab позволяют автоматизировать рутинные задачи при обновлении проектов в репозитории. В нашем примере мы рассмотрим ситуацию, когда у нас используется сервер GitLab для хранения проекта и 5 веб-серверов, куда должны попадать изменения после выполнения git push. Мы настроим наш CI/CD на синхронизацию файлов с помощью rsyncd. Предполагается, что у нас уже установлен GitLab на Linux, в противном случае, воспользуйтесь инструкцией для Ubuntu или CentOS.
Нам потребуется выполнить:
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:
Находим раздел Runners:
Справа от названия кликаем по Expand:
Находим параметры для регистрации нового раннера:
… и оставляем страницу открытой — она понадобиться на следующем шаге.
В командной строке нашего сервера GitLab вводим:
gitlab-runner register
* установить и запустить Runner можно не только на локальном сервере GitLab, но мы рассмотрим только данный способ.
Система в интерактивном режиме запросит данные для регистрации — вводим их:
Enter the GitLab instance URL (for example, https://gitlab.com/): https://gitlab.admins24.com/ 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): admins24, 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
* где:
В конце мы должны увидеть:
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:
И так, обработчик зарегистрирован и настроен. Переходим к созданию CI/CD.
На первоначальном этапе, мы создадим простой сценарий, который просто будет выводить путь до каталога на сервере, в котором находится проект.
Переходим в GitLab на страницу проекта и кликаем по 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 создан. Теперь необходимо подготовить систему к синхронизации данных.
Наша синхронизация будет выполняться с помощью 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
После установки и запуска 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
[admins24] path = /var/www/admins24/www/ comment = Site admins24.com uid = apache gid = apache read only = no list = yes auth users = rsync_admins24 secrets file = /etc/rsyncd.scrt hosts allow = localhost 192.168.0.10 hosts deny = *
* наибольший интерес для нас имеют следующие опции:
Создадим файл, в котором должны быть логин и пароль для проверки подлинности rsync:
vi /etc/rsyncd.scrt
rsync_admins24:password
* в данном примере мы задали логин rsync_admins24 и пароль 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 мы должны настроить подключение к сервисам rsyncd. Для начала устанавливаем rsync.
а) для систем на базе deb:
б) для RPM-систем:
После создаем файл, в котором будем хранить пароль для подключения к rsyncd:
* это тот пароль, который мы задали в аналогичном файле на стороне веб-серверов.
Задаем права минимально необходимые для чтения файла с паролем:
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 [email protected]$i::admins24; done
* обратите внимание, что в моем примере веб-серверы имеют имена web-01, web-02 и так далее, поэтому, чтобы не выполнять все 5 команд по отдельности, мы используем цикл, в котором подставляем разные цифры в названия серверов.
В итоге, на стороне веб-серверов должен появиться файл testfile. Теперь остается последний шаг — настроить созданный ранее CI/CD для синхронизации.
Переходим на страницу нашего проекта и кликаем по CI/CD configuration:
Чтобы открылся редактор, кликаем по Edit:
Или из командной строки, можно открыть на редактирование наш файл .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/ [email protected]$i::admins24; done
* мы заменили наш этап test на copy. В данном примере мы выполняем команду для запуска синхронизации с веб-серверами с помощью rsync. В качестве источника данных мы используем переменную $CI_PROJECT_DIR, в которой находится наш проект. В качестве экземпляра, куда синхронизируем данные используем admins24.
Готово. Пробуем выполнить git push в наш проект. Данные должны разойтись по всем веб-серверам.
Ошибка возникает при попытке зарегистрировать Runner, а при отправке curl-запроса на сервер:
curl https://gitlab.admins24.com
… мы получаем сообщение о неправильном сертификате:
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.
Продолжая использовать данный сайт вы принимаете политику конфиденциальности и cookies
