gitlab ci yml что это

Настройка 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

Aug 22, 2019 · 5 min read

Gitlab предоставляет уникальную возможность получить одновременно бесплатный приватный репозиторий и бесплатный CI/CD из коробки в том же месте. Для сохранения баланса он конфигурируется не менее уникальным способом через конфиг-файл, который не так-то просто для понимания(я в первый раз вникала чересчур долго). В конце концов разобралась, и хочу поделиться.

Как это работает вообще все?

Настроить билды без этого файла, как, например, в тимсити или дженкинсе нельзя.

Ура, я хочу захостить свой фронтенд-проект на gitlab!

В отличие от простого gh-pages, где ты собираешь, что хочешь, и просто пушишь в репозиторий файл index.html, тут так поступить нельзя. Ну, то есть, в теории, можно, но автоматически ничего все равно работать не будет.

Как будет выглядеть в gitlab конфиг “типа как на gh-pages” (я предполагаю, что мы, как и с gh-pages уже собрали все в папку dist и запушили ее).

Главный секрет деплоя статики — положить все необходимое в папку public и отметить ее как артефакт.

И тут задумываемся — зачем собирать все локально, если можно делать это на машинах гитлаба, все равно же конфиг пишем. Это займет чуть больше времени, зато будет надежнее.

Все, мы разобрались с тем, как сделать, чтобы сайт собирался и деплоился, достаточно просто вносить изменения, пушить и он автоматически будет пересобираться и обновляться!

Теперь можно разобраться поподробнее в конфиге и придумать, какие еще возможности можно использовать

Этапы сборки

Конфиг “stage” — этап билда, по дефолту их три: build, test, deploy. Этапы всегда идут в четком порядке. Можно не указывать ничего, тогда запустится на этапе test.

Разберемся, что это такое и как использовать это во благо. Если подумать, этапов работы с кодом у нас и правда в целом три: собрать, протестировать(убедиться, что это можно деплоить), задеплоить. И если один из них упал, остальные запускать нет необходимости.

По этому принципу делает и гитлаб:

Особенность конфига гитлаба в том, что мы не идем вроде как логично, объявляя этапы и наполняя их задачами, а, наоборот, каждой задаче указываем, на каком она этапе. Этапы, конечно же, можно создать любые, не ограничиваясь стандартными.

Например кусочек конфига для скриншота выше:

Стоит поменять порядок этапов в конфиге, и они начнут выполняться в другом порядке.

cache

Билды обычно идут дольше, чем хотелось бы. Первое, что приходит в голову — это что же, каждый раз скачивать зависимости? Это можно улучшить!

В конфиг задачи достаточно добавить вот такое:

$ – переменная окружения, которую создает гитлаб. В ней хранится хеш имени ветки, в которой запущен процесс.

Гитлаб предоставляет много разных переменных, которые можно использовать здесь. Кешировать node_modules наиболее эффективно по веткам, хотя можно шерить кеш на весь репозиторий. Или вообще написать хитрое условие.

Артефакты

В конфиге выше написано:

Артефакты работают так: файлы, лежащие по указанным путям, в конце каждой джобы загружаются на сервер гитлаба и скачиваются в начале каждой джобы следующего этапа.

Погодите, звучит как кеш! В чем разница?

Кеш, исходя из названия, нужен для того, чтобы что-то временно хранить для ускорения сборки. Кстати, исходя из его предназначния, гитлаб не гарантирует то, что кеш найдется, он вполне себе может потеряться.

Я описала два глобальных отличия, есть еще несколько, их можно найти здесь.

Но в итоге непонятно: как тут добавление артефактов позволяет деплоить pages, и когда вообще нужно их использовать?

Все, базовые основы CD на gitlab вы знаете, теперь можно хостить и деплоить код втайне от подписчиков на гитхабе (а если не хотите и гитлаб светить, то приватные репозитории + heroku в помощь!).

Источник

Введение в GitLab CI

Публикую перевод моей статьи из блога ГитЛаба про то как начать использовать CI. Остальные переводы гитлабовских постов можно найти в блоге компании Softmart.

Представим на секунду, что вы не знаете ничего о концепции непрерывной интеграции (Continuous Integration — CI) и для чего она нужна. Или вы всё это забыли. В любом случае, начнем с основ.

Представьте, что вы работаете над проектом, в котором вся кодовая база состоит из двух текстовых файлов. Более того, очень важно, чтобы при конкатенации этих файлов в результате всегда получалась фраза «Hello world.» Если это условие не выполняется, вся команда лишается месячной зарплаты. Да, все настолько серьезно.

Один ответственный разработчик написал небольшой скрипт, который нужно запускать перед каждой отправкой кода заказчикам. Скрипт нетривиален:

Проблема в том, что в команде десять разработчиков, а человеческий фактор еще никто не отменял.

Неделю назад один новичок забыл запустить скрипт перед отправкой кода, в результате чего трое заказчиков получили поломанные сборки. Хотелось бы в дальнейшем избежать подобного, так что вы решаете положить конец этой проблеме раз и навсегда. К счастью, ваш код уже находится на GitLab, а вы помните про встроенную CI-систему. К тому же, на конференции вы слышали, что CI используется для тестирования.

Запуск первого теста в CI

Добавляем, коммитим — и ура! Сборка успешна!

Поменяем во втором файле «world» на «Africa» и посмотрим, что получится:

Сборка неудачна, как и ожидалось.

Итак, у нас теперь есть автоматизированные тесты. GitLab CI будет запускать наш тестовый скрипт при каждом пуше нового кода в репозиторий.

Возможность загрузки результатов сборки

Следующим бизнес-требованием является архивация кода перед отправкой заказчикам. Почему бы не автоматизировать и его?

Все, что для этого нужно сделать — определить еще одну задачу для CI. Назовем ее «package»:

В результате появляется вторая вкладка

Однако мы забыли уточнить, что новый файл является артефактом сборки, что позволит его скачивать. Это легко поправить, добавив раздел artifacts :

Проверяем… Все на месте:

Отлично! Однако, осталась одна проблема: задачи выполняются параллельно, а нам не нужно архивировать наше приложение в случаях, когда тест не пройден.

Последовательное выполнение задач

Задача ‘package’ должна выполняться только при успешном прохождении тестов. Определим порядок выполнения задач путем введения стадий ( stages ):

Также не стоит забывать о том, что компиляция (которой в нашем случае является конкатенация файлов) занимает время, поэтому не стоит проводить ее дважды. Введем отдельную стадию для компиляции:

Посмотрим на получившиеся артефакты:

Скачивание файла «compile» нам ни к чему, поэтому ограничим длительность жизни временных артефактов 20 минутами:

Итоговая функциональность конфига впечатляет:

Какие образы Docker лучше использовать

Прогресс налицо. Однако, несмотря на наши усилия, сборка до сих пор проходит медленно. Взглянем на логи:

Что, простите? Ruby 2.1?

А вообще, в свободном доступе находится довольно много разных образов, так что можно без проблем подобрать один для нашего стека. Главное — помнить о том, что лучше подходят образы, не содержащие дополнительной функциональности — такой подход минимизирует время скачивания.

Работа со сложными сценариями

Обратите внимание на то, что названия задач не обязательно должны быть одинаковыми. Более того, в таком случае параллельное выполнение задач на одной стадии было бы невозможным. Так что относитесь к одинаковым названиям задач и стадий как к совпадению.

А тем временем сборка не удалась:

Установка дполнительного ПО

Все это — тоже валидные команды CI. Полный список команд в разделе script должен выглядеть следующим образом:

А ведь мы только что создали конвейер! У нас есть три последовательные стадии, при этом задачи pack-gz и pack-iso стадии package выполняются параллельно:

Подводя итоги

В этой статье приведены далеко не все возможности GitLab CI, однако пока что остановимся на этом. Надеемся вам понравился этот небольшой рассказ. Приведенные в нем примеры были намеренно тривиальными — это было сделано для того, чтобы наглядно показать принципы работы CI не отвлекаясь на незнакомые технологии. Давайте подытожим изученное:

В последнем разделе этой статьи приведен более формализованный список терминов и ключевых слов, использованных в данном примере, а также ссылки на подробные описания функциональности GitLab CI.

Описания ключевых слов и ссылки на документацию

Ключевое слово/термин	Описание
.gitlab-ci.yml	Конфигурационный файл, в котором содержатся все определения сборки проекта
script	Определяет исполняемый shell-скрипт
before_script	Определяет команды, которые выполняются перед всеми заданиями
image	Определяет используемый Docker-образ
stage	Определяет стадию конвейера ( test по умолчанию)
artifacts	Определяет список артефактов сборки
artifacts:expire_in	Используется для удаления загруженных артефактов по истечению определенного промежутка времени
pipeline	Конвейер — набор сборок, которые выполняются стадиями

Также обратите внимание на другие примеры работы с GitLab CI:

Источник