Використання gitlab continuous integration для деплоя

Зовсім недавно гитлаб героїчно викотив версію 8.0 свого конкурента гитхабу. З цікавого — движок continuous integration тепер вбудований в платформу, а значить доступний в якості безкоштовного сервісу для всіх бажаючих на gitlab.com. Спільно з безкоштовними приватними репозиторіями це робить хмарний сервіс гитлаб не тільки зручним місцем для зберігання коду, але також тестування і деплоя. Про останнє я і розповім під катом.



Continuous integration — це не тільки запуск юніт тестів при пуше нового коду в репозиторій. Це ще й можливість робити збірки продуктів, публікувати їх в стори, сайтів і інші канали розповсюдження. Хмарна телефонія voximplant використовує javascript сценарії, які розміщуються в нашому хмарі та виконуються по команді «зовні» або при надходженні вхідного дзвінка. Багато клієнтів для роботи зі сценаріями використовують вбудований в адмінку текстовий редактор, що цілком підходить для простих випадків. Але при розробці і підтримці складних хмарних систем, наприклад телефонії Bitrix24, потрібно щось більш серйозне.


Створюючи voximplant ми вирішили не робити push-to-deploy як у heroku. У багатьох наших клієнтів основний бізнес не пов'язаний з розробкою софта, і залишати їх наодинці з git'ом не дуже добре. Зате є HTTP API з функцією «задеплоить сценарій», який натякає розуміючим людям сценарії можна зберігати на gitlab і деплоить з допомогою shell скрипта і curl. Більшість клієнтів так і робить, але в підходу є серйозний недолік: скрипт потрібно не забути викликати. Більш того, викликати його треба тільки якщо код був запушений у production гілку. І тільки після того, як пройшли тести. Взагалі багато способів помилитися.


Налаштування continuous integration в gitlab

За замовчуванням continuous integration в гитлабе вимкнено і необхідно його включити в налаштуваннях:



Після включення в лівому меню налаштувань проекту з'являється кілька нових пунктів, найцікавіший для нас — це «runners». Continuous integration в гитлабе працює наступним чином:

  1. Ви робите push в репозиторій
  2. Якщо в корені проекту є файл .gitlab-ci.yml, гитлаб розуміє, що для цього проекту буде використовуватися continuous integration.
  3. Гитлаб шукає запущений runner, підключений для цього або будь-якого проекту. Runner — це додаток, яке зазвичай запускають на окремому комп'ютері яке буде здійснювати власне continuous integration: проганяти тести, збирати виконувані файли, осущестлять деплой. Можна запустити свій runner, наприклад на маці щоб зібрати додаток для iOS. Можна використовувати «gitlab public runner», але вони не те щоб дуже безпечні і вхідні черги завдань у них зазвичай багатогодинні.
  4. Гитлаб передає yaml файл runner'у, який оновлює исходники у своєму репозиторії і виконує команди, описані в цьому файлі. Команди можуть бути як прості, приміром зробити деплой сценарію в хмару voximplant. Так і складні: запуск docker контейнера, збірка в ньому проекту, запуск тестів і так далі.
  5. Після виконання скриптів runner рапортує назад гитлабу резулттаты, які можна подивитися поруч з відповідним комітом.


Установка gitlab ci runner

Для нашого прикладу ми запустимо runner на машині розробника. Інструкції з інсталяції для windows/linux/osx доступна на офіційному сайті, після установки ми отримуємо в своє розпорядження command line утиліту gitlab-ci-multi-runner. Запущений runner підключається до гитлабу і чекає завдання на складання. Але як гитлаб дізнається, які завдання якого runner'у давати? Щоб «прив'язати» runner до свого аккаунту і проекту (або кількома проектами) необхідно викликати gitlab-ci-multi-runner з ключем register і ввести параметри підключення: url гитлаб (так як гитлаб може бути розгорнутий локально у вашій мережі) і токен реєстрації, який, власне, і визначає акаунт/проекти:



Зареєстрований runner запускається командою gitlab-ci-multi-runner run і чекає завдання від гитлаба. За допомогою параметрів командного рядка install та start runner можна зареєструвати в системі як сервіс, щоб він автоматично стартував після перезавантаження операційної системи.

Конфігурація continuous integration для деплоя

Як я вже писав, завдання continuous integration описуються у файлі .gitlab-ci.yml, який необхідно розмістити в корені проекту. Рідкоземельний синтаксис YAML є як-би-человекочитаемой альтернативою JSON'у, документація доступна на офіційному сайті. Конфігураційний файл для деплоя проекту в voximplant буде максимально простим, все що нам потрібно — це зробити один виклик HTTP API як описано в нашій документації. Якщо виходити з припущення, що runner виконується на комп'ютері, де встановлений curl, а код сценарію знаходиться у файлі scenario.js, конфігураційний файл для деплоя буде виглядати наступним чином:

before_script:
- npm install
stages:
- deploy
deploy:
script:
- curl -X POST "https://api.voximplant.com/platform_api/SetScenarioInfo/?account_id=1&api_key=2&required_scenario_name=foo" --data-urlencode scenario_script@scenario.js


У curl використовується синтаксичний цукор нашого API, яке може приймати аргументи як у вікні query переданого url, так і в body http запиту.

Щоб continuous integration заробив достатньо зробити push в репозиторій: гитлаб виявить файл .gitlab-ci.yml, знайде підключений runner, передасть йому вміст цього файлу, runner оновить свою копію репозиторію і запустить скрипт деплоя, який відвантажить вихідний код в наше хмара.

Питання, уточнення, коментарі? Gitlab vs Jenkins vs Bamboo vs Teamcity?

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.