Автоматическое масштабирование непрерывного развертывания 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-образы, которые будут использоваться при сборке нашего проекта.
Настройка GitLab CI/CD
Если вы используете Git и GitLab для хранения кода, то можете упростить и автоматизировать разворачивание вашего кода на сервере сразу же, при появлении новых изменений в GitLab репозитории. Этот процесс называется CI/CD (Continuous Integration, Continuous Delivery или Непрерывная интеграция и доставка). С помощью этой технологии вы можете выполнять тесты, собирать проект, а затем помещать результат сборки или исходники в нужное место.
В этой небольшой статье будет рассмотрена настройка GitLab CI CD для небольшого проекта на PHP без сборки и тестов, а только с копированием исходников в директорию веб-сервера на сервере проекта.
Настройка GitLab CI/CD
1. Установка GitLab Runner
Для того чтобы у GitLab был доступ к серверу, на этот сервер необходимо установить службу gitlab-runner. Именно эта программа будет забирать новые исходники с GitLab, выполнять с ними нужные действия и разворачивать на сервере. Установить её в Ubuntu можно из официальных репозиториев. Сначала добавьте репозиторий в систему:
Обратите внимание, что поддерживаются Ubuntu 16.04, 18.04 и 20.04, если у вас другая версия, после установки репозитория вам надо будет изменить его на версию для ближайшего поддерживаемого дистрибутива. После этого можно установить пакет:
sudo apt install gitlab-runner
Так выполняется установка GitLab runner Ubuntu. В CentOS и других Red Hat дистрибутивах процедура установки похожая. Сначала добавьте репозиторий:
Затем установите пакет:
sudo yum install gitlab-runner
Возможно, в будущем процедура или ссылки на пакеты изменятся. Смотрите официальную документацию.
После установки запустите сервис с помощью systemd и добавьте его в автозагрузку:
2. Регистрация GitLab Runner
Откройте репозиторий на GitLab, для которого вы хотите настроить CI/CD, затем кликните по шестеренке (пункт Settings) в меню, а потом выберите CI/CD:
Возле пункта Runners нажмите кнопку Expand:
Общие раннеры от GitLab можно отключить для того чтобы они вам не мешали и не забирали задачи у вашего раннера. Для этого под надписью Enable shared runners for this project установите значение выключателя в положение выключено:
Необходимая вам информация находится в левой части окна, в разделе Specific runners. Тут вам надо узнать URL сервиса и токен авторизации, с которым вы будете регистрировать раннер:
Теперь возвращайтесь на сервер, на котором был установлен runner и выполните такую команду:
sudo gitlab-runner register
Программа спросит URL и токен, которые вы узнали на GitLab.
Затем надо ввести описание и теги для раннера. Теги будут использоваться в будущем для того чтобы отправлять этому раннеру задания. Далее останется только выбрать способ выполнения команд. Для того чтобы просто запускать командную оболочку можно выбрать shell.
Обратите внимание, что команду надо выполнять именно с sudo. Поскольку демон выполняется от имени пользователя root, то и авторизацию нужно выполнять от имени этого пользователя, иначе работать не будет, но и ошибок не выдаст.
Для того чтобы убедится, что всё настроено и работает нормально выполните такую команду:
sudo gitlab-runner verify
Она должна показать сообщение is_alive. Настройка gitlab runner на сервере завершена.
3. Настройка GitLab Runner
После того как раннер был зарегистрирован, обновите страницу настроек CI на GitLab. Новый раннер должен появится в списке и кружок возле него должен быть зелёным:
Кликните по значку карандаша (Edit) возле раннера и выставьте такие настройки:
Все остальные опции можно не трогать.
После завершения настройки на забудьте нажать кнопку Save Changes. Дальше можно переходить к созданию файла .gitlab-ci.yml.
4. Создание gitlab-ci.yml
Именно в этом файле описываются все задачи, а также команды, которые gitlab-runner будет выполнять на сервере. Вы можете создать его вручную или же, если такого файла ещё нет, то на главной странице проекта нажмите кнопку Setup CI/CD:
После этого кликните по кнопке Create New CI/CD Pipeline:
Дальше перед вами откроется редактор файла .gitlab-ci.yml.
Раздел stages описывает этапы разворачивания приложения и очередность их выполнения. Затем описываются задачи, которые будут выполняться в рамках каждого этапа. У задачи должен быть указан этап: stage и script со списком команд, которые будут выполняться на сервере. Во время разворачивания gitlab-runner автоматически создает на сервере (по умолчанию в домашней папке) директорию build, клонирует туда свежие исходники проекта и переходит в папку с исходниками. А дальше с помощью команд в секции script вы можете делать всё, что нужно с этими исходниками.
Для этого примера можно оставить только секцию deploy. Самый простой конфигурационный файл будет выглядеть вот так:
stages:
— deploy
deploy-job:
stage: deploy
script:
— echo «Deploying application. »
— echo «Application successfully deployed.»
Сохраните этот файл. Для этого пролистайте вниз страницы и нажмите кнопку Commit Changes.
5. Проверка работы Pipeline
Если всё было сделано правильно, то ваш раннер получит эту задачу, склонирует исходники и выведет две строчки в терминал. Для того чтобы убедится что это всё произошло, в боковом меню выберите значок ракеты (CI/CD) а затем Pipelines:
Здесь отображаются все задачи CI/CD. В данном случае у вас должна быть одна задача.
Если всё прошло успешно перед ней будет зеленая кнопка Passed. Для того чтобы посмотреть лог выполнения задачи, кликните по этой кнопке, а затем выберите непосредственно задачу из списка:
В результате откроется лог выполнения раннера для этой задачи:
Поскольку внизу зелёным написано Job succeeded, значит задача выполнилась успешно. В самом верху лога вы можете видеть какой раннер использовался для выполнения, убедитесь, что это именно ваш раннер, а не один из стандартных.
6. Разворачивание исходников
Программа уже скачивает исходники на сервер, но дальше вы можете сделать с ними всё что хотите. Настраивать раннер загружать исходники прямо в папку веб-сервера не стоит, программа для этого не предназначена. Для копирования исходников лучше использовать rsync. Эта утилита позволяет копировать только изменившиеся файлы. Например, для копирования файлов из репозитория в /var/www/project необходимо добавить такую команду в секцию script:
sudo chown gitlab-runner:gitlab-runner /var/www/project
Если всё было сделано верно на этот раз, то файлы появятся в папке:
Аналогичным образом вы можете добавлять другие команды, которые необходимо выполнить с исходниками на сервере. Можно даже загружать их на другие сервера с помощью того же rsync. Вообще говоря, локально можно было бы и обойтись без этой утилиты и воспользоваться cp. Но rsync позволяет именно синхронизировать изменения, что очень удобно.
Выводы
Теперь вы знаете как выполняется настройка GitLab CI CD, а также GitLab-runner. Как видите, это довольно полезные инструменты. Теперь на сервере будут оказываться все новые коммиты и у вас больше не будет необходимости выгружать их туда вручную.
Настройка 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 для всего содержимого каталога, где находятся наши сайты.
