Gitlab-CI
Всем привет.
У нас не так много задач, которым необходим полноценный CI. Некоторое время мы использовали в качестве CI-сервиса Jenkins. Там всё довольно очевидно, он прост и гибок в настройке, имеет кучу плагинов, но пару раз мы столкнулись с OOM-убийцами агентов на слабых машинах и решили рассмотреть в качестве CI-сервиса Gitlab CI, потому что мы любим эксперименты и тем более в комментариях к нашей прошлой статье задавали такой вопрос.
Установка GitLab-CE
Тут всё довольно тривиально, т. к. есть Omnibus package.
Устанавливаем и запускаем необходимые пакеты:
Настраиваем и запускаем Gitlab-CE:
Установка раннера
GitLab Runner — это агент, который собственно и занимается выполнением инструкций из специального файла .gitlab-ci.yml.
В отличие от Jenkins раннеры гитлаба написаны на Go, поэтому они очень маленькие и быстрые. И умеют запускать задачи совершенно различными способами: локально, в докер-контейнерах, в различных облаках или через ssh-коннект к какому либо серверу. Подробности, как всегда, в документации
Кто-то в комментариях к прошлой статье просил рассмотреть 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.
vim Dockerfile
Окей, собраем образ
и пушим в Registry
Теперь самое время описать пайплайн
В корне нашего проекта создаём файл .gitlab-ci.yml (опять YAML, ага) и описываем шаги сборки проекта.
Здесь мы указываем стадии сборки проекта. На стадии тестирования — мы проходимся lint’ом на предмет синтаксических ошибок и запускаем Ansible в Dry mode, то есть не применяя изменения на хосте, а просто их показывая. Если вдруг что-то ломается во время проигрывания плейбука — мы об этом узнаем до того, как конфигурация на хосте изменится.
Соответсвенно, если мы сейчас попробуем в плейбук добавить где-нибудь пробелов — то конфигурация не применится, lint сообщит об ошибке и упадёт на этапе тестирования, о чём можно узнать после коммита прямо в веб-интерфейсе gitlab.
У .gitlab-ci.yml очень много различных опций на все случаи стадии жизни проекта. К сожалению, за один вечер со всем ознакомиться не удалось.
Как видите, Gitlab ничем не хуже других 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 – ваш экземпляр GitLab, где хранятся репозитории кода.
- GitLab Bastion – ядро этой инфраструктуры. Этот экземпляр позволяет взаимодействовать с API вашего хостинг-провайдера для создания необходимых серверов. Он не должен обрабатывать другие задачи.
- GitLab Runners – это временные серверы, которые создаются bastion-сервером для обработки задач CI/CD вашей очереди сборки. Эти серверы являются одноразовыми, на них выполняется или тестируется код до сборки.
Используя каждый из компонентов GitLab, вы можете масштабировать процесс CI/CD в зависимости от требований. Имея в виду эти цели, можно начать настройку непрерывного развертывания с помощью GitLab.
Требования
- Настроенный GitLab на вашем сервере.
- Сервер Ubuntu 16.04 (читайте Установка и настройка GitLab в Ubuntu 16.04).
- Включенная частная сеть (читайте мануал Как включить частную сеть на рабочем сервере?).
Все задачи мануала можно выполнить с помощью не-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:
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash
Затем установите GitLab Runner:
sudo apt-get install gitlab-runner
Также вам нужно установить Docker Machine, инструмент Docker для автоматизации развертывания контейнеров в облаке.
curl -L https://github.com/docker/machine/releases/download/v0.14.0/docker-machine-`uname -s`-`uname -m` >/tmp/docker-machine && \
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, используя следующую команду:
curl -L https://github.com/docker/machine/releases/download/v0.14.0/docker-machine-`uname -s`-`uname -m` >/tmp/docker-machine && sudo install /tmp/docker-machine /usr/local/bin/docker-machine
Теперь можно добавить токены доступа для 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
Результат должен выдать ошибку, которая поможет определить причину проблемы.
Если ваша инфраструктура создает слишком много машин, и вы хотите удалить их все одновременно, вы можете запустить эту команду:
docker-machine rm $(docker-machine ls -q)
Больше информации по отладке инфраструктуры можно найти в документации.
Заключение
Вы успешно создали автоматизированный конвейер CI/CD с помощью GitLab Runner и Docker. Теперь вы можете настроить кэширование Docker Registry для оптимизации производительности или изучить возможность использования тегов для конкретных runner-серверов GitLab.
Дополнительную информацию о GitLab Runner вы найдете в документации. Чтобы узнать больше, вы можете прочитать серию статей в блоге GitLab о том, как использовать конвейер максимально продуктивно.
GITLAB runner
GITLAB runner — сервер, который выполняет тесты при каждом коммите в отдельном Docker контейнере. За счет него реализуется автоматическое тестирование кода.
Использование Docker необязательно, есть и другие варианты, однако этот — самый распространенный.
GITLAB runner — регистрация и использование
runner-ы могут существовать для проектов индивидуально или быть быть общими для нескольких проектов. Во втором случае к репозиторию требуется ограничивать доступ или задавать тип Private.
runner-ы запускаются в Docker контейнерах для изоляции. На сервере нужен Docker.
Docker устанавливается обычно с официального сайта.
add-apt-repository \»deb [arch=amd64] https://download.docker.com/linux/ubuntu \$(lsb_release -cs) \stable»
apt-get update && apt-get install docker-engine
Однако, для конкретного дистрибутива лучше выполнять установку по инструкции. Инструкция для Ubuntu 18.
На сервере, который используется для примера установлен Gitlab и Docker. На нем же будет runner.
Скачивание скрипта, который добавит репозиторий для Debian
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh -o /tmp/gl-runner.deb.sh
Сам скрипт запускается с указанием интерпретатора /bin/bash из коносли
Теперь можно устанавливать runner (от имени root)
runner служит для того чтобы обеспечивать связь между Docker и gitlab в обоих направлениях.
По пакету в консоли можно вызвать справку
Первой необходимой командой для того чтобы наладить связь между CI/CD и Docker является регистрация
В диалоге будет последовательно выведено несколько вопросов.
Нужно указать coordinator (адрес, по которому доступен Gitlab или домен), токен, описание, gitlab-ci тэги( такие как stage, qa, build, deploy). Образ Docker можно взять минимальный alpine:ltest
Токен для регистрации runner-а можно увидеть в настройках проекта. Потребуется перейти в Settings, CI/CD, Runners, нажать Expand. Токен будет указан нас странице. На скриншоте приведена нужная страница, но токен указан чуть ниже и не виден.
Перейдя в CI/CD можно увидеть коммиты для проекта. Один из них находится в состоянии Passed. 
Нажав на Passed можно увидеть подробности. В данном случае это консольный вывод с успешно выполненным тестом.
Так выполняется работа с runner-ами и так они регистрируются на сервере. Runner-ов может быть много: индивидуальных и общих для нескольких проектов.
Если их много в конфигурационном файле можно использовать тэги или 'tags', которые указывают какой runner будет использован.
Настройка 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 можно из официальных репозиториев. Сначала добавьте репозиторий в систему:
curl -L «https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh» | sudo bash
Обратите внимание, что поддерживаются Ubuntu 16.04, 18.04 и 20.04, если у вас другая версия, после установки репозитория вам надо будет изменить его на версию для ближайшего поддерживаемого дистрибутива. После этого можно установить пакет:
sudo apt install gitlab-runner
Так выполняется установка GitLab runner Ubuntu. В CentOS и других Red Hat дистрибутивах процедура установки похожая. Сначала добавьте репозиторий:
curl -L «https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh» | sudo bash
Затем установите пакет:
sudo yum install gitlab-runner
Возможно, в будущем процедура или ссылки на пакеты изменятся. Смотрите официальную документацию.
После установки запустите сервис с помощью systemd и добавьте его в автозагрузку:
sudo systemctl enable —now gitlab-runner
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) возле раннера и выставьте такие настройки:
- Active — должно быть включено, иначе раннер не сможет выполнять задания;
- Protected — должно быть включено, для того чтобы раннер брал задания из всех веток, а не только защищённых;
- Run untagged jobs — должно быть включено, позволяет раннеру брать задачи без тегов;
- Lock to current projects — если включено, этот раннер доступен только для этого проекта.
Все остальные опции можно не трогать.
После завершения настройки на забудьте нажать кнопку Save Changes. Дальше можно переходить к созданию файла .gitlab-ci.yml.
4. Создание gitlab-ci.yml
Именно в этом файле описываются все задачи, а также команды, которые gitlab-runner будет выполнять на сервере. Вы можете создать его вручную или же, если такого файла ещё нет, то на главной странице проекта нажмите кнопку Setup CI/CD:
После этого кликните по кнопке Create New CI/CD Pipeline:
Дальше перед вами откроется редактор файла .gitlab-ci.yml.
Как и следует из расширения — это файл в формате YAML, поэтому отступы перед значениями очень важны. Сразу же можете удалить отсюда все комментарии. Структура файла примерно такая:
Раздел 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:
rsync -av —no-perms —no-owner —no-group —exclude «.git*» $CI_PROJECT_DIR/ /var/www/project
Для редактирования файла .gitlab-ci.yml можете воспользоваться пунктом меню CI/CD -> Editor или найти и отредактировать этот файл в списке файлов. Папка, в которую вы собираетесь разврачивать проект должна существовать на сервере и у пользователя gitlab-runner должны быть права на запись в неё:
sudo mkdir -p /var/www/project
sudo chown gitlab-runner:gitlab-runner /var/www/project
После сохранения файла развертывание выполнится и файлы, либо будут копированы в указанную папку, либо вы получите ошибку. В случае ошибки вы можете исправить проблему, затем открыть CI/CD -> Jobs и перезапустить задачу с помощью кнопки с круговой стрелочкой:
Если всё было сделано верно на этот раз, то файлы появятся в папке:
Аналогичным образом вы можете добавлять другие команды, которые необходимо выполнить с исходниками на сервере. Можно даже загружать их на другие сервера с помощью того же rsync. Вообще говоря, локально можно было бы и обойтись без этой утилиты и воспользоваться cp. Но rsync позволяет именно синхронизировать изменения, что очень удобно.
Выводы
Теперь вы знаете как выполняется настройка GitLab CI CD, а также GitLab-runner. Как видите, это довольно полезные инструменты. Теперь на сервере будут оказываться все новые коммиты и у вас больше не будет необходимости выгружать их туда вручную.