Деплой проекта с помощью Gitlab Continuous Integration

Сервис GitLab, как основной конкурент GitHub-а, имеет свои плюсы и минусы (это помимо отечественных корней разработки). Однако с некоторых пор он получил карт-бланш для всех команд разработки, применяющих continuous integration (CI) — этот функционал стал быть встроенным прямо в движок. И — вуаля! — теперь GitLab не только популярное CVS-облако, но еще и полноценная платформа для тестинга и сборки проектов! Юнит-тесты, билды, публикация сборок (и кода) в сторонние хранилища — все это доступно прямо “из коробки”.
Рассмотрим все это богатство поближе.

 

Подключение CI в GitLab-е

Для начала, следует включить continuous integration для проекта в GitLab:

1f2af1c1f96e42cea43b1a5cc5082f57

Основная “рабочая лошадь” для CI в GitLab-е — это runner. Схема работы всего процесса примерно такая:

  1. push проекта в репозиторий
  2. GitLab внимательно смотрит на файлы проекта и, если обнаруживает в корне файлик .gitlab-ci.yml — то задействует для проекта механизм continuous integration
  3. GitLab выполняет поиск runner-а, который задействован для данного проекта. Runner — приложение для непосредственного выполнения continuous integration: тестирования, сборки и деплоя проекта.
    Потренироваться можно с gitlab public runner, однако этот сервис часто бывает загружен, ну и безопасность его, это вопрос.
  4. yaml-файл автоматически передается runner-у, который выполняет сценарий из этого файла.
    Это могут быть как простые команды (например, деплой проекта в какое-то облако) либо сложный сценарий, с последовательным запуском докера, билдом проекта, тестированием и т.д.
  5. Результаты работы runner-а отображаются в GitLab-е непосредственно рядом с соответствующим commit-ом.

 

Установка GitLab runner

Будем выполнять наш runner на девелоперской машине. После установки приложения под любую из распространенных ОС, получаем командный интерфейс к gitlab-ci-multi-runner.
Для того, чтобы runner получал задачи от GitLab-а, его нужно связать с соотв. аккаунтом и проектом. Для этого выполняем gitlab-ci-multi-runner с параметром register, после чего указываем url GitLab-а (а это может быть и локальный инстанс GitLab), и токен регистрации:

fa97a5f34f6a4ea8b54f5314920c7d79

Теперь сервис раннера можно запустить через gitlab-ci-multi-runner run, переведя его в ожидание задачи от гитлаба.

 

Создаем YAML-скрипт для continuous integration

Еще раз напомним — операции для continuous integration описываются файлом .gitlab-ci.yml, находящимся в корне проекта GitLab. Синтаксис формата YAML требует некоторой подготовки для понимания, однако документация по нему есть.
Мы сделаем один вызов API нашей условной платформы через HTTP по примеру из документации.
В нашем примере, curl установлен на ПК, где запущен runner, а сам скрипт API имеет название s_script.js:

before_script:

- npm install

stages:

- deploy

deploy:

script:

- curl -X POST "https://api.some_portal.com/platform_api/SetS_scriptInfo/?account_id=1&api_key=2&required_s_script_name=foo" --data-urlencode s_script_script@s_script.js

Этот скрипт будет выполняться каждый раз при команде push в репозиторий GitLab.

 

Уверенно освоить GitLab на “боевых проектах” вы можете на нашем авторском курсе «L3-DevOps».

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *