что такое runner в gitlab
Gitlab-CI
Всем привет.
У нас не так много задач, которым необходим полноценный CI. Некоторое время мы использовали в качестве CI-сервиса Jenkins. Там всё довольно очевидно, он прост и гибок в настройке, имеет кучу плагинов, но пару раз мы столкнулись с OOM-убийцами агентов на слабых машинах и решили рассмотреть в качестве CI-сервиса Gitlab CI, потому что мы любим эксперименты и тем более в комментариях к нашей прошлой статье задавали такой вопрос.
Установка GitLab-CE
Тут всё довольно тривиально, т. к. есть Omnibus package.
Устанавливаем и запускаем необходимые пакеты:
Настраиваем и запускаем Gitlab-CE:
Установка раннера
Кто-то в комментариях к прошлой статье просил рассмотреть Gitlab для тестирования ansible-плейбуков, его и возьмём.
Для обеспечения идентичности среды тестирования и продакшен будем использовать Docker.
Для работы раннера в Docker — сначала необходимо установить docker:
Настройка и подключение раннера к CI-сервису:
Указываем URL нашего Gitlab, и прописываем токен для авторизации.
Также необходимо задать название раннера, способ запуска джоба, в случае с docker — указываем образ который будет запускать раннер.
Конфигурация для раннера указана по урлу example.com/groupname/projectname/runners
Здесь можно редактировать название раннера и метки, с которыми будет собираться проект на этом раннере. Например, нам нужно на разных стадиях протестировать проект сначала в shell, затем запаковать его в docker-контейнер и выкатить куда-нибудь по ssh. Об этом немного позже.
Оттуда необходимо взять URL мастера и токен для авторизации раннера на «мастере».
После этого он должен появиться в списке раннеров проекта:
Установка Container Registry
Не так давно в Gitlab интегрировали Container Registry.
GitLab Container Registry — это защищённый приватный репозиторий для хранения Docker-образов (Docker images).
Ищем в /etc/gitlab/gitlab.rb секцию Container registry settings
Из необходимого:
нужно выставить gitlab_rails[‘registry_enabled’] = true и registry[‘enable’] = true
В registry_external_url указываем доменное имя сервера, на котором будет находится репозиторий.
Также нужно найти следующие настройки:
И указать правильные пути к сертификатам.
Если будут использоваться самоподписные сертификаты, то на стороне docker-daemon, с которого будет проходить вся работа с образами нужно выставить опцию —insecure-registry, в противном случае при попытке залогинится — мы получим ошибку (раннеров тоже касается).
В Debian: /etc/systemd/system/multi-user.target.wants/docker.service
(Да, порт указывать не нужно. Существует API для registry — он висит на localhost:5000 и фронт, через который происходит авторизация и дальнейшая работа с образами. Я же долго искал способ перевесить API с локалхоста 🙂 )
И пробуем зайти под нашей учётной записью gitlab
Ну что, теперь самое время что-нибудь с этим сделать, построить первый пайплайн и посмотреть, как проект будет собираться.
Настройка CI
Приступаем к тестированию ansible-плейбуков:
Я не буду вдаваться в глубины и рассказывать о serverspec и test-kitchen, о них уже было написано в моём прошлом посте.
Первым делом — собираем простой образ с окружением для тестов. Обойдёмся Dry run и ansible-lint.
Окей, собраем образ
и пушим в Registry
Теперь самое время описать пайплайн
Здесь мы указываем стадии сборки проекта. На стадии тестирования — мы проходимся lint’ом на предмет синтаксических ошибок и запускаем Ansible в Dry mode, то есть не применяя изменения на хосте, а просто их показывая. Если вдруг что-то ломается во время проигрывания плейбука — мы об этом узнаем до того, как конфигурация на хосте изменится.
Соответсвенно, если мы сейчас попробуем в плейбук добавить где-нибудь пробелов — то конфигурация не применится, lint сообщит об ошибке и упадёт на этапе тестирования, о чём можно узнать после коммита прямо в веб-интерфейсе gitlab.
У .gitlab-ci.yml очень много различных опций на все случаи стадии жизни проекта. К сожалению, за один вечер со всем ознакомиться не удалось.
Как видите, Gitlab ничем не хуже других CI-сервисов, имеет позитивный и удобный интерфейс, но есть особенности в плане написания сценария тестирования и деплоя.
Спасибо за внимание. Удачной автоматизации!
GitLab Shell Runner. Конкурентный запуск тестируемых сервисов при помощи Docker Compose
Данная статья будет интересна как тестировщикам, так и разработчикам, но рассчитана в большей степени на автоматизаторов, которые столкнулись с проблемой настройки GitLab CI/CD для проведения интеграционного тестирования в условиях недостаточности инфраструктурных ресурсов и/или отсутствия платформы оркестрации контейнеров. Я расскажу, как настроить развертывание тестируемых окружений при помощи docker compose на одном единственном GitLab shell раннере и так, чтобы при развертывании нескольких окружений запускаемые сервисы друг другу не мешали.
Содержание
Предпосылки
В моей практике частенько случалось «лечить» интеграционное тестирование на проектах. И зачастую первой и самой значительной проблемой является CI pipeline, в котором интеграционное тестирование разрабатываемого сервиса(ов) проводится в dev/stage окружении. Это вызывало не мало проблем:
Кто-то скажет, что хорошие автотесты должны чистить данные после себя. У меня есть аргументы против:
По моему мнению, самое оптимальное решение — это динамическое окружение.
У меня есть собственный GitLab раннер для своих проектов и с этими вопросами я столкнулся при разработке Java клиента для TestRail. А точнее при запуске интеграционных тестов. Вот далее и будем решать эти вопросы с примерами из данного проекта.
GitLab Shell Runner
Для раннера рекомендую линуксовую виртуалку с 4 vCPU, 4 GB RAM, 50 GB HDD.
На просторах интернета очень много информации по настройке gitlab-runner, поэтому коротко:
Если у вас менее 8 GB RAM, то рекомендую сделать swap 10 GB, чтобы не приходил OOM killer и не убивал нам задачи из-за нехватки RAM. Такое может случится, когда запускается одновременно более 5 задач. Задачи будут проходить помедленнее, зато стабильно.
И если картина выглядит примерно так, то или добавляйте swap, или докидывайте RAM.
Открываем на редактирование /etc/gitlab-runner/config.toml и добавляем
Это позволит запускать параллельные задачи на одном раннере. Более подробно читать тут.
Если у вас машинка помощнее, например 8 vCPU, 16 GB RAM, то эти цифры можно сделать как минимум в 2 раза больше. Но все зависит от того, что конкретно будет запускаться на данном раннере и в каком количестве.
Подготовка docker-compose.yml
Основная задача — это docker-compose.yml, который будет использован как локально, так и в CI pipeline.
Для запуска нескольких экземпляров окружения будет использоваться переменная COMPOSE_PROJECT_NAME (см. makefile).
Пример моего docker-compose.yml
Подготовка Makefile
Я использую Makefile, так как это весьма удобно как для локального управления окружением, так и в CI.
Автоматическое масштабирование непрерывного развертывания GitLab с помощью GitLab Runner
GitLab – это инструмент с открытым исходным кодом, используемый командами разработчиков программного обеспечения для управления жизненным циклом разработки и доставки. GitLab предоставляет широкий набор функций: отслеживание ошибок, репозитории git, непрерывную интеграцию, реестр контейнеров, развертывание и мониторинг. Эти функции построены с нуля как единое приложение. Вы можете разместить GitLab на своих серверах или использовать GitLab.com, бесплатный облачный сервис для проектов с открытым исходным кодом.
Функции непрерывной интеграции/непрерывной доставки (CI/CD) GitLab – эффективный способ выработать привычку тестировать весь код до его развертывания. GitLab CI/CD также обладает высокой масштабируемостью благодаря дополнительному инструменту GitLab Runner, который автоматизирует масштабирование вашей очереди сборки, что позволяет избежать длительного ожидания перед релизом кода.
Данный мануал поможет настроить масштабируемую инфраструктуру GitLab и автоматизировать ее реакцию на нагрузки (увеличивая и уменьшая доступную мощность сервера).
Мы собираемся создать масштабируемый процесс CI/CD, который автоматически реагирует на спрос, создавая новые серверы и уничтожая их по мере необходимости.
Эти серверы генерируются процессом GitLab Runner и автоматически удаляются при отсутствии заданий, что снижает затраты и административные издержки вашей команды.
В этом мануале вы научитесь определять количество машин, которое сможет создавать GitLab Runner, а также время, в течение которого они будут работать.
Для создания этого проекта мы будем использовать три отдельных сервера. Сначала ознакомьтесь с терминами:
Используя каждый из компонентов GitLab, вы можете масштабировать процесс CI/CD в зависимости от требований. Имея в виду эти цели, можно начать настройку непрерывного развертывания с помощью GitLab.
Требования
Все задачи мануала можно выполнить с помощью не-root пользователя с привилегиями администратора.
1: Импортирование проекта JavaScript
Для начала можно создать новый тестовый проект в GitLab, где уже есть образец приложения Node.js.
Войдите в свой экземпляр GitLab и нажмите значок «плюс», а затем выберите New project в раскрывающемся меню.
На экране нового проекта выберите Import project, затем нажмите Repo by URL, чтобы импортировать образец проекта непосредственно с GitHub.
Вставьте указанный ниже URL-адрес в Git repository URL:
Этот репозиторий – это базовое приложение JavaScript, которое мы будем использовать для демонстрации примеров и не будем запускать в производство. Чтобы завершить импорт, нажмите кнопку New Project.
Теперь у вас есть новый проект GitLab, и можно приступить к настройке CI-конвейера.
2: Настройка инфраструктуры
GitLab Code Runner требует определенной конфигурации, если мы планируем автоматически создавать сервреы для обработки нагрузки CI по мере ее роста и спада.
В этом мануале мы используем два типа машин: экземпляр bastion, который контролирует и запускает новые машины, и экземпляры runner, которые являются временными серверами, порожденными bastion-сервером для сборки кода. Экземпляр bastion использует Docker для создания runner-серверов.
Для начала создайте bastion-сервер. Создайте новый сервер Ubuntu 16.04 наименьшего размера (bastion-сервер не будет выполнять задачи тестирования, а только создавать новые серверы).
Рекомендуем вам использовать хранилища объектов для кэширования данных.
Включите на новом сервере частную сеть и мониторинг.
После этого вам нужно настроить хранилище объектов для кэширования. Запишите его API Key, он понадобится позже.
3: Настройка GitLab Runner
Теперь можно настроить GitLab Runner. усатновите скрипты из репозиториев GitLab и GitHub.
Обязательно проверяйте сценарии, загруженные из интернета, чтобы убедиться, что сценарий не навредит системе.
Подключитесь к серверу по SSH, перейдите в каталог /tmp, затем добавьте официальный репозиторий GitLab Runner в менеджер пакетов Ubuntu:
Затем установите GitLab Runner:
sudo apt-get install gitlab-runner
Также вам нужно установить Docker Machine, инструмент Docker для автоматизации развертывания контейнеров в облаке.
sudo install /tmp/docker-machine /usr/local/bin/docker-machine
После этого можно подключить GitLab Runner к установке GitLab.
4: Токен регистрации GitLab Runner
Чтобы связать GitLab Runner с существующей установкой GitLab, нужно подключить два экземпляра, получив токен, который авторизует GitLab Runner в репозиториях кода.
Войдите в свой экземпляр GitLab в качестве admin, затем щелкните значок гаечного ключа, чтобы войти в область настроек администратора.
Слева выберите Overview и Runners.
На странице Runners в разделе How to setup a shared Runner for a new project скопируйте токен и запишите его вместе с общедоступным URL вашего экземпляра GitLab (раздел 2). Если вы используете HTTPS, убедитесь, что сертификат не является самоподписанным, иначе GitLab Runner не запустится.
5: Настройка GitLab Bastion
Вернитесь в свое SSH-соединение с bastion-сервером и выполните следующую команду:
sudo gitlab-runner register
Это инициирует процесс связки, и вам будет задан ряд вопросов.
На следующем этапе введите URL-адрес экземпляра GitLab из предыдущего раздела:
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com)
Затем введите токен экземпляра GitLab:
Please enter the gitlab-ci token for this runner
Введите описание, которое поможет вам распознать его в веб-интерфейсе GitLab. Мы рекомендуем выбрать уникальное описательное имя, например:
Please enter the gitlab-ci description for this runner
Если это необходимо, вы можете ввести теги кода, который вы будете собирать с помощью runner-сервера. Однако мы рекомендуем на этом этапе оставить это поле пустым. Это можно легко изменить в интерфейсе GitLab.
Please enter the gitlab-ci tags for this runner (comma separated):
Следующий параметр позволяет вам выбрать, должен ли ваш runner-сервер создавать репозитории без каких-либо тегов или же требовать определенных тегов. В этом случае выберите значение true, чтобы runner-сервер мог обрабатывать все репозитории.
Whether to run untagged jobs [true/false]: true
Следующее поле позволяет вам распределить runner-сервер между всеми проектами либо зарезервировать его для одного конкретного проекта.
Whether to lock Runner to current project [true/false]: false
Выберите исполнитель, который будет собирать ваши машины. Поскольку GitLab будет создавать новые серверы с помощью Docker, выберите docker+machine (узнать больше о преимуществах каждого подхода можно в этой таблице совместимости):
Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:
Затем нужно выбрать образ по умолчанию (для проектов, где образ не указан явно). Выберите базовый вариант:
Please enter the Docker image (e.g. ruby:2.1):
Теперь вы закончили настройку основного runner-сервера! На этом этапе он должен появиться на странице GitLab Runner администратора GitLab, к которой вы обращались, чтобы получить токен.
Если вы столкнулись с какими-либо проблемами, обратитесь к документации GitLab Runner.
6: Настройка кэширования и Docker Machine
Чтобы ускорить создание серверов, можно использовать инструменты кэширования Docker на bastion-сервере для хранения образов часто используемых контейнеров.
Для этого обновите Docker Machine в оболочке SSH, используя следующую команду:
Теперь можно добавить токены доступа для GitLab Runner.
7: Добавление учетных данных
Теперь нужно создать учетные данные, с помощью которых GitLab Runner сможет авторизоваться в вашем аккаунте хостинг-провайдера.
Откройте панель управления хостингом и выберите настройки API. Здесь вы должны сгенерировать новый токен.
Выберите описательное имя для нового токена, например, GitLab Runner Access. Убедитесь, что права на чтение и запись включены.
Скопируйте токен в безопасное место, чтобы использовать его на следующем этапе. Вы не сможете снова извлечь этот же токен, поэтому убедитесь, что он в безопасности.
8: Редактирование конфигурационных файлов GitLab Runner
Чтобы объединить все эти компоненты, нужно завершить настройку bastion-сервера и позволить ему взаимодействовать с вашей учетной записью хостинг-провайдера.
На bastion-сервере откройте конфигурационный файл GitLab Runner:
Этот конфигурационный файл отвечает за правила, которые установка CI использует для масштабирования инфраструктуры. Чтобы настроить bastion-сервер на автоматическое масштабирование, вам необходимо добавить следующие строки:
concurrent = 50 # All registered Runners can run up to 50 concurrent builds
token = “existinggitlabtoken” # Note this is different from the registration token used by `gitlab-runner register`
executor = “docker+machine” # This Runner is using the ‘docker+machine’ executor
limit = 10 # This Runner can execute up to 10 builds (created machines)
image = “alpine:latest” # Our secure image
IdleCount = 1 # The amount of idle machines we require for CI if build queue is empty
IdleTime = 600 # Each machine can be idle for up to 600 seconds, then destroyed
MachineName = “gitlab-runner-autoscale-%s” # Each machine will have a unique name (‘%s’ is required and generates a random number)
“image=coreos-stable”, # The system image to use by default
“ssh-user=core”, # The default SSH user
“access-token=ACCESS_TOKEN”, # Access token from Step 7
“region=nyc3”, # The data center to spawn runners in
“size=1gb”, # The size (and price category) of your spawned runners
“private-networking” # Enable private networking on runners
Type = “s3” # The Runner is using a distributed cache with the S3-compatible service
SecretKey = “YOUR_ STORAGE_SECRET”
Insecure = true # We do not have a SSL certificate, as we are only running locally
После того, как вы добавите новые строки, укажите свои данные: токен доступа, регион и размер серверов и т.д.
Вам также необходимо настроить кэш и ввести адрес сервера хранилища объектов, access key, secret key и имя вашего хранилища.
Перезапустите GitLab Runner:
Узнать больше о доступных опциях можно в документации GitLab.
9: Тестирование GitLab Runner
Теперь bastion-сервер настроен и может создавать серверы по мере необходимости. Давайте протестируем его работу.
Чтобы запустить сборку, отредактируйте файл readme.md. Добавьте в файл какой-нибудь текст, затем нажмите Commit changes.
Теперь сборка будет инициирована автоматически.
На этой странице вы увидите запись о конвейере со статусом running. В вашей учетной записи хостинг-провайдера вы увидите несколько серверов, автоматически созданных GitLab Runner, чтобы собрать это изменение.
Это значит, что конвейер CI масштабируется и самостоятельно управляет использованием ресурсов. После указанного времени простоя машины должны быть автоматически уничтожены, но мы рекомендуем проверить это вручную.
Устранение неполадок
В некоторых случаях GitLab может сообщить, что runner недоступен и в результате не выполняет никаких действий, включая развертывание новых runner-серверов. Вы можете устранить это, остановив GitLab Runner, а затем снова запустив его в режиме отладки
gitlab-runner –debug start
Результат должен выдать ошибку, которая поможет определить причину проблемы.
Если ваша инфраструктура создает слишком много машин, и вы хотите удалить их все одновременно, вы можете запустить эту команду:
Больше информации по отладке инфраструктуры можно найти в документации.
Заключение
Вы успешно создали автоматизированный конвейер CI/CD с помощью GitLab Runner и Docker. Теперь вы можете настроить кэширование Docker Registry для оптимизации производительности или изучить возможность использования тегов для конкретных runner-серверов GitLab.
Дополнительную информацию о GitLab Runner вы найдете в документации. Чтобы узнать больше, вы можете прочитать серию статей в блоге GitLab о том, как использовать конвейер максимально продуктивно.
GitLab CI: Часть 1, запуск раннеров (runners)
May 8, 2017 16:23 · 338 words · 2 minute read gitlab gitlab ci
В одной из предыдущих статей, посвященных GitLab — одной из самых популярных систем контроля версий и управления Git-репозиториями, — мы подготовили необходимый фундамент для настройки GitLab Continuous Integration (GitLab CI).
Эта статья начинает цикл публикаций, в которых мы подробно рассмотрим процесс настройки GitLab CI на реальном проекте. Давайте разберемся!
Для функционирования процесса Continuous Integration нам необходимо настроить еще один компонент — раннер (runner). Раннер в GitLab используется для запуска определенных задач (jobs, о них мы поговорим позже), их выполнения и отправки результатов обратно в GitLab.
В этой статье мы добавили docker-контейнер с раннером внутри в конфигурационный файл docker-compose.yml и запустили всю связку. Проверим состояние интересующего нас docker-контейнера:
Теперь нам необходимо зарегистрировать наш раннер, сделать это можно с помощью следующей команды:
Давайте подробнее остановимся на используемых параметрах:
Больше информации о возможных типах раннеров и их специфических настройках доступно здесь.
Раннер успешно зарегистрирован и готов к работе! В следующей статье рассмотрим специфические docker-образы, которые будут использоваться при сборке нашего проекта.
Настройка CI/CD в GitLab для синхронизации проекта с веб-серверами
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):
б) система на базе RPM-пакетов (Red Hat / CentOS):
в) для систем, которые не поддерживаются GitLab, но которые основаны на базе поддерживаемых систем.
Сначала загружаем скрипт:
* в данном примере, загружен скрипт для систем на базе пакетов RPM.
Открываем его на редактирование:
# remove whitespace from OS and dist name
os=»$
dist=»$
И меняем их на что-то подобное:
# remove whitespace from OS and dist name
os=»centos»
dist=»8″
* в данном примере мы указали, что установка будет выполняться как для CentOS 8.
Установка
После настройки репозитория, выполняем установку. Команда также зависит от типа операционной системы.
а) для Debian / Ubuntu (системы на основе deb-пакетов):
apt-get install gitlab-runner
б) для Red Hat / CentOS (системы на основе RPM):
yum install gitlab-runner
После установки gitlab-runner разрешаем автозапуск сервиса и стартуем его:
Регистрация
Находим раздел Runners:
Справа от названия кликаем по Expand:
Находим параметры для регистрации нового раннера:
. и оставляем страницу открытой — она понадобиться на следующем шаге.
В командной строке нашего сервера GitLab вводим:
* установить и запустить 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:
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:
И так, обработчик зарегистрирован и настроен. Переходим к созданию CI/CD.
Создание CI/CD для проекта
На первоначальном этапе, мы создадим простой сценарий, который просто будет выводить путь до каталога на сервере, в котором находится проект.
Переходим в GitLab на страницу проекта и кликаем по Set up CI/CD:
* данной кнопки может и не быть.
. или можно просто в корне проекта создать файл:
Задаем содержимое нашего сценария:
* Из расширения файла понятно, что формат текста должен быть yml, а значит, отступы имеют значения. В данном примере мы создаем pipeline с одним единственным этапом, которое называется test. По данному заданию будет запускаться скрипт вывода значения переменной $CI_PROJECT_DIR — путь, по которому клонируется проект и где выполняется задание (если установлен $builds_dir, эта переменная устанавливается относительно данного значения. Список возможных переменных можно посмотреть на официальном сайте в разделе документации GitLab CI/CD environment variables.
После сохранения файла ждем несколько секунд и перезапускаем страницу — мы должны увидеть успешный результат выполнения сценария CI/CD:
Кликнем по значку зеленой галочки и в открывшейся странице кликаем по нашей единственной стадии:
Мы должны увидеть ход процесса выполнения задания и результат его работы:
На этой же странице справа можно вручную запустить задание еще раз:
CI/CD создан. Теперь необходимо подготовить систему к синхронизации данных.
Настройка Rsyncd
Наша синхронизация будет выполняться с помощью Rsyncd. Это удобный инструмент, с помощью которого можно поддерживать актуальное состояние двух и более каталогов. Также у нас не возникнет проблем с правами — rsync после копирования будет задавать файлам нужного владельца и нам не нужно будет выдавать права root для runner с помощью файла sudoerst. Подробнее об установке и настройке Rsyncd.
Настройки нужно выполнить как на веб-серверах, так и сервере с GitLab.
Настройка на веб-серверах
Данные действия нужно выполнить на каждом веб-сервере. Мы должны установить и настроить в качестве сервиса rsyncd. Сначала установим его. В зависимости от типа Linux, наши действия будут различаться.
а) Ubuntu / Debian:
apt-get install rsync
Открываем следующий файл:
systemctl enable rsync
systemctl start rsync
б) CentOS 7
в) CentOS 8
yum install rsync rsync-daemon
После установки и запуска rsyncd, открываем его конфигурационный файл:
И добавим в него следующие настройки:
[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
#pre-xfer exec =
#post-xfer exec =
hosts allow = localhost 192.168.0.10
hosts deny = *
* наибольший интерес для нас имеют следующие опции:
Создадим файл, в котором должны быть логин и пароль для проверки подлинности rsync:
* в данном примере мы задали логин rsync_dmosk и пароль password.
Необходимо задать минимально необходимые права на файл с аутентификационными данными:
chmod 600 /etc/rsyncd.scrt
Убедимся, что у целевого каталога выставлен правильный владелец:
Можно перезапускать сервис:
systemctl restart rsyncd || systemctl restart rsync
Также необходимо создать правила в брандмауэре для разрешения TCP-порта 873, на котором работает rsyncd.
а) для систем на базе deb-пакетов (Ubuntu, Debian):
apt-get install iptables-persistent
б) для систем на базе RPM-пакетов (Red Hat, CentOS):
Данные настройки выполняем на всех веб-серверах. После переходим к настройке сервера GitLab.
Настройка GitLab
На стороне сервера GitLab мы должны настроить подключение к сервисам rsyncd. Для начала устанавливаем rsync.
а) для систем на базе deb:
apt-get install rsync
б) для RPM-систем:
После создаем файл, в котором будем хранить пароль для подключения к rsyncd:
* это тот пароль, который мы задали в аналогичном файле на стороне веб-серверов.
Задаем права минимально необходимые для чтения файла с паролем:
chmod 640 /etc/rsyncd.scrt
Задаем в качестве группы владельца файла с паролем нашего пользователя gitlab-runner:
chown :gitlab-runner /etc/rsyncd.scrt
Создаем файл, который отправим на серверы веб в качестве теста:
Выполняем команду для синхронизации данного файла с веб-серверами:
* обратите внимание, что в моем примере веб-серверы имеют имена web-01, web-02 и так далее, поэтому, чтобы не выполнять все 5 команд по отдельности, мы используем цикл, в котором подставляем разные цифры в названия серверов.
В итоге, на стороне веб-серверов должен появиться файл testfile. Теперь остается последний шаг — настроить созданный ранее CI/CD для синхронизации.
Настройка синхронизации в CI/CD
Переходим на страницу нашего проекта и кликаем по CI/CD configuration:
Чтобы открылся редактор, кликаем по Edit:
Меняем содержимое нашего файла:
* мы заменили наш этап test на copy. В данном примере мы выполняем команду для запуска синхронизации с веб-серверами с помощью rsync. В качестве источника данных мы используем переменную $CI_PROJECT_DIR, в которой находится наш проект. В качестве экземпляра, куда синхронизируем данные используем dmosk.
Готово. Пробуем выполнить git push в наш проект. Данные должны разойтись по всем веб-серверам.
Дополнительно
Дополнительная информация, которая может быть полезна.
Запуск runner внутри контейнера Docker
Выше мы рассмотрели регистрацию раннера, который будет запускать выполнение команд в системной оболочке (shell). Но если мы хотим, чтобы задания pipeline выполнялись внутри контейнера Docker, то пошагово мы должны сделать следующее:
1. При регистрации раннера на последнем этапе, где предлагается выбрать средство запуска (Enter an executor), выбираем docker:
.
Enter an executor: parallels, virtualbox, docker+machine, docker-ssh+machine, kubernetes, custom, docker, docker-ssh, shell, ssh:
docker
2. При написании pipeline мы должны добавить опцию image с указанием образа, который хотим использовать:
.
copy:
stage: copy
image: dmosk/ubuntu:latest
.
3. По умолчанию, runner всегда будет пытаться скачать образ Docker с внешнего источника. Если на целевом компьютере, где запускается runner у нас уже есть нужный образ и мы хотим, чтобы использовался именно он, открываем файл:
. находим созданный раннер (определяем по описанию, которое мы задавали при регистрации) и в нем также находим [runners.docker]. Добавим опцию pull_policy:
[[runners]]
.
[runners.docker]
.
pull_policy = «if-not-present»
systemctl restart gitlab-runner
Возможные ошибки
status couldn execute post against certificate signed by unknown authority
Ошибка возникает при попытке зарегистрировать Runner, а при отправке curl-запроса на сервер:
. мы получаем сообщение о неправильном сертификате:
Причина: нужна полная цепочка сертификатов.
Решение: подробнее, процесс настройки https описан в инструкции Правильная настройка SSL в NGINX.
@ERROR: chroot failed
Ошибка появляется при попытке синхронизировать файлы с применением команды rsync.
Причины:
1. На целевом сервере нет целевого каталога (указан в опции path), в который необходимо синхронизировать данные.
2. Доступ к целевой папке запрещен политикой selinux.
Решение: для обоих причин опишим соответствующие решения.
1. Проверяем наличие каталога, который мы указали в конфигурационном файле /etc/rsyncd.conf (опция path). Если его нет, создаем, например:
2. Для начала пробуем отключить разово selinux:
Если это решило проблему, либо отключаем его совсем, либо настраиваем командами:
* в данном примере мы разрешам контекст безопасности rsync_data_t для всего содержимого каталога, где находятся наши сайты.