Как установить gitlab 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 можно из официальных репозиториев. Сначала добавьте репозиторий в систему:
Обратите внимание, что поддерживаются 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. Как видите, это довольно полезные инструменты. Теперь на сервере будут оказываться все новые коммиты и у вас больше не будет необходимости выгружать их туда вручную.
linux-notes.org
Установка GitLab-Runner-а в Unix/Linux
Сейчас я расскажу как можно настроить gitlab-runner на разные Unix/Linux ОС. Но для начала, запустим сервисы.
Установка GitLab-Runner-а в Mac OS X
Конечно же, выставить права нужно:
После того как выставили права, необходимо зарегестрировать гитлаб-ранер, например, это можно сделать следующим образом:
Для помощи есть команда:
Установим Runner как сервис и запустим его:
Для обновления сервиса, нужно выполнить все теже действия что я описывал ранее, но перед этим, стоит остановить службу.
Вот и все использование.
Установка GitLab-Runner-а в GNU/Linux
Скачиваем бинарник в зависимости от разрядности и архитектуры ОС.
Если у вас, Linux x86-64:
Если у вас, Linux x86:
Если у вас, Linux arm:
Конечно же, выставить права нужно:
При желании, если вы хотите использовать Docker, установите Docker с:
Создайте пользователя GitLab CI:
После того как выставили права, необходимо установить Runner как сервис и запустить его:
Потом, зарегестрировать гитлаб-ранер, например, это можно сделать следующим образом:
Для обновления сервиса, нужно выполнить все теже действия что я описывал ранее, но перед этим, стоит остановить службу.
PS: Конечно если кто-то привык устанавливать программы через пакеты, то можно установить гитлаб-раннер через паркет. Приведу пару примеров:
Для Debian или Ubuntu:
А чтобы установить, можно выполнить:
Для RedHat или CentOS:
PS: Если у вас проблемы с ссылками, попробуйте использовать http/https (В зависимости от того что используете на данный момент).
Вот и все использование.
Установка GitLab-Runner-а в FreeBSD
Не было необходимости!
Установка GitLab-Runner-а через docker контейнер в Unix/Linux
Можно запустить контейнер, например следующим образом:
Но после создания контейнера, стоит на него зайти:
И запустить регистрацию, я ее описывал ранее несколько раз.
Установка GitLab-Runner-а через Kubernetes
Не было обходимости пока еще.
Вот и все, статья «Установка GitLab-Runner-а в Unix/Linux» завершена.
Добавить комментарий Отменить ответ
Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.
Gitlab-CI
Всем привет.
У нас не так много задач, которым необходим полноценный CI. Некоторое время мы использовали в качестве CI-сервиса Jenkins. Там всё довольно очевидно, он прост и гибок в настройке, имеет кучу плагинов, но пару раз мы столкнулись с OOM-убийцами агентов на слабых машинах и решили рассмотреть в качестве CI-сервиса Gitlab CI, потому что мы любим эксперименты и тем более в комментариях к нашей прошлой статье задавали такой вопрос.
Установка GitLab-CE
Тут всё довольно тривиально, т. к. есть Omnibus package.
Устанавливаем и запускаем необходимые пакеты:
Настраиваем и запускаем Gitlab-CE:
Установка раннера
Кто-то в комментариях к прошлой статье просил рассмотреть 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.
Окей, собраем образ
и пушим в Registry
Теперь самое время описать пайплайн
Здесь мы указываем стадии сборки проекта. На стадии тестирования — мы проходимся lint’ом на предмет синтаксических ошибок и запускаем Ansible в Dry mode, то есть не применяя изменения на хосте, а просто их показывая. Если вдруг что-то ломается во время проигрывания плейбука — мы об этом узнаем до того, как конфигурация на хосте изменится.
Соответсвенно, если мы сейчас попробуем в плейбук добавить где-нибудь пробелов — то конфигурация не применится, lint сообщит об ошибке и упадёт на этапе тестирования, о чём можно узнать после коммита прямо в веб-интерфейсе gitlab.
У .gitlab-ci.yml очень много различных опций на все случаи стадии жизни проекта. К сожалению, за один вечер со всем ознакомиться не удалось.
Как видите, Gitlab ничем не хуже других CI-сервисов, имеет позитивный и удобный интерфейс, но есть особенности в плане написания сценария тестирования и деплоя.
Спасибо за внимание. Удачной автоматизации!
Первая попытка gitlab-ci на фронте
Эта статья о сценарии развертывания фронта, через инструменты Gitlab-CI.
Я использую GitLab-CI, а носителем исполнения скриптов GitLab Runner (об этом позже) пусть будет простой дроплет от DO
GitLab
GitLab — это онлайн-хранилище кода, основанное на Git, аналогичной GitHub. Обычно оно используется для создания частных серверов Git во внутренних сетях, таких как предприятия и школы.
Что такое непрерывная интеграция
Что такое хорошая непрерывная интеграция, можно посмотреть на Вики.
.gitlab-ci.yml
Это файл в корневом каталоге проекта Git, в котором записан ряд этапов и правил выполнения. GitLab-CI проанализирует его после пуша и вызовет Gitlab-runner(а) для запуска в соответствии с его содержимым.
Проще говоря, вы используете Git для отправки локального кода в Remote (здесь ваш gitlab.com), а затем Gitlab уведомит ваш сервер, который является Gitlab-runner, чтобы запустить задачу сборки.
Установить Gitlab Runner:
Например в Ubuntu
Скачать
Затем зарегистрируйте Gitlab Runner, необходимо зарегистрировать его в Gitlab, прежде чем он сможет использоваться проектом.
Зарегистрируйте Runner в системе Ubuntu:
Запустите следующую команду, чтобы начать процесс регистрации:
Введите URL-адрес экземпляра GitLab:
Введите полученный токен для регистрации Runner:
Задайте название Ранеру
Запрос на установку тэга, оставьте пустым!
Выберите исполнителя Runner:
Маленькая зеленая точка указывает на то, что вы успешно зарегистрировались.
Не переживайте, если у вас не так. Устанавливайте Docker и возвращайтесь к статье.
Pipeline
Конвейер — фактически эквивалентен задаче сборки, которая может включать несколько процессов, таких как установка зависимостей, запуск тестов, компиляция, развертывание. Любой из наших коммитов или слияний по запросу слияния может вызвать конвейер. Как показано ниже:
Stages
Этапы — представляют собой этап сборки, и, проще говоря, это процесс, упомянутый выше. Мы можем определить несколько этапов в конвейере, и каждый этап может выполнять различные задачи. Этапы имеют следующие характеристики:
Схематически, отношения между этапами и конвейером:
Рабочие места — представляют собой строительные работы и работы, выполняемые на этапе. Мы можем определить несколько заданий на этапах, эти задания будут иметь следующие характеристики:
Итак, отношения между Jobs и Stage таковы:
Вот самый простой сценарий развертывания для проекта Node.
Обратите внимание, что имена job1 и job2 являются произвольными, это не имеет значения, но не используете ключевые слова Gitlab-CI:
ключевое слово — Описание
image — Используется для инжекта Docker образов
services — Используется для службы докеров
stage — Определить этап сборки
before_script — Определите команду для запуска перед каждым заданием
after_script — Определите команду для запуска после каждого задания
variable — Определить переменные сборки
cache — Определяет список файлов, которые могут быть использованы в последующих запусках
Найдите более подробную статью, чтобы было ясно о каждом ключевом слове и объяснении.
По натуре своей многие разработчики слишком ленивые не любят делать одно и то же действие много раз. Нам проще научить компьютер, чтобы он делал монотонные действия за нас.
Как только кто-либо из нашей команды вносит изменения в код (читай «мерджит feature-ветку в develop»), наш билд-сервер:
Также, в зависимости от ветки, в которую были внесены изменения, могут быть выполнены:
Под катом о том, как мы научили Gitlab CI делать за нас бОльшую часть этой муторной работы.
Оглавление
Перед началом
Чтобы быть уверенными, что написанное ниже работает, мы взяли на github небольшой проект, написанный на WPF и имеющий unit-тесты, и воспроизвели на нём описанные в статье шаги. Самые нетерпеливые могут сразу зайти в созданный на сайте gitlab.com репозиторий и посмотреть, как это выглядит.
Устанавливаем и регистрируем Gitlab Runner
Чтобы настроить Gitlab Runner, выполните следующие шаги:
Далее надо ввести ответы на вопросы мастера регистрации Runner-а:
Также в этом разделе можно настроить передачу введенных параметров только при сборке защищённых веток (галочка Protected) и/или скрытие значения параметра из логов (галочка Masked).
Подробнее о параметрах окружения сборки смотрите в документации к Gitlab CI.
Активируем режим Developer PowerShell for VS
Скрипт, приведённый выше, уже можно использовать для сборки и вызова тестов. Правда, присутствует НО: крайне неудобно прописывать абсолютные пути к разным установкам Visual Studio. К примеру, если на одной билд-машине стоит Visual Studio 2017 BuildTools, а на другой Visual Studio Professional 2019, то такой скрипт будет работать только для одной из двух машин.
К счастью, с версии Visual Studio 2017 появился способ поиска всех инсталляций Visual Studio на компьютере. Для этого существует утилита vswhere, путь к которой не привязан ни к версии Visual Studio, ни к её редакции. А в Visual Studio 2019 (в версии 16.1 или более новой) есть библиотека, которая умеет «трансформировать» консоль Powershell в режим Developer Powershell, в котором уже прописаны пути к утилитам из поставки VS.
Дописываем переменную к секции Variables:
Затем создаём новую секцию before_msbuild якорем enter_vsdevshell и следующим текстом:
И всюду, где нам надо использовать утилиты Visual Studio, добавляем этот якорь. После этого задача сборки начинает выглядеть намного более опрятно:
Результат: мы имеем путь к vswhere.
Результат: загружен модуль Powershell с командлетом трансформации.
Результат: мы получили полноценную консоль Developer Powershell с прописанными путями к msbuild и многим другим утилитам, которые можно использовать при сборке.
Используем CI для проставления версии во все сборки решения
На заметку: чтобы данная команда работала корректно во всех случаях, автор gitflow даже чуть-чуть поменял скрипты finish hotfix и finish release. Если кому интересно посмотреть обсуждение с автором gitflow, а также увидеть что изменилось (картинка с актуальной схемой в последнем сообщении в треде).
Кстати, по этой же причине если вы используете gitflow, после вливания feature-ветки в develop требуется удалить влитую локальную ветку, после чего пересоздать её от свежего develop:
(обратите внимание на историю git в левой части картинки: из-за отсутствия пути из текущего коммита до коммита с меткой 1.0.5, команда git describe выдаст неверный ответ)
Но вернёмся к автопроставлению версии. В нашем репозитории царит gitflow (точнее его rebase-версия), метки расставляются в ветке master и мы не забываем пересоздавать feature-ветки от develop, а также merge-ить master в develop после каждого релиза или хотфикса.
Тогда получить версию для любого коммита и сразу передать её в msbuild можно добавив всего пару строк к задаче сборки:
Обратите внимание: если вы, согласно gitflow, будете отмечать (тэгировать) ветку master после вливания в неё release или hofix, будьте внимательны: до простановки метки автосборка будет вестись относительно последней существующей ветки. Например, сейчас опубликована версия 3.4, а вы создаёте release-ветку для выпуска версии 3.5. Так вот: всё время существования этой ветки, а также после её вливания в master, но до простановки тэга, автосборка будет проставлять версию 3.4.
Добавляем отправку данных в SonarQube
SonarQube — это мощный инструмент контроля качества кода.
SonarQube имеет бесплатную Community-версию, которая способна проводить полный анализ. Правда, только одной ветки. Чтобы настроить её на контроль качества ветки разработки (develop), требуется выполнить следующие шаги (разумеется, помимо установки и развёртывания сервера SonarQube):
Теперь при каждой сборке ветки develop в SonarQube будет отправляться подробный анализ нашего кода.
На заметку: вообще команда msbuild /t:rebuild полностью пересобирает решение. Вероятно, в большинстве проектов анализ можно было бы встроить прямо в стадию сборки. Но сейчас у нас анализ в отдельной задаче.
Пара слов об использованных параметрах:
«Причёсываем» автотесты xUnit + добавляем вычисление покрытия тестами через OpenCover
Со сборкой более-менее разобрались — теперь приступаем к тестам. Доработаем код прогона тестов, чтобы он:
На заметку: обычно в паре с OpenCover используют ReportGenerator, но при наличии SonarQube мы с тем же успехом можем смотреть результаты через его интерфейс.
Для настройки выполним следующие шаги: