Инструкции

Разработка программного обеспечения — многоступенчатый процесс проектирования, написания кода и тестирования продукта. Часть шагов можно автоматизировать с помощью процессов непрерывной интеграции (CI) и непрерывной доставки (CD). В этом материале расскажем про установку Gitlab Runner — исполнителя пайплайнов в среде совместной разработки Gitlab. Gitlab — это платформа для совместной разработки ПО, в основе которой лежат Git-репозитории. Помимо простого управления репозиториями, Gitlab позволяет выполнять автоматические однотипные действия, например, собирать «ночные сборки» программного обеспечения и выполнять автотесты для каждого коммита. За это отвечает компонент GitLab CI/CD. Последовательность действий в CI/CD называется пайплайном (pipeline), а один шаг пайплайна – джобой (job). По умолчанию Gitlab использует собственное оборудование для запуска пайплайнов. В бесплатном тарифном плане ежемесячно дается 400 минут вычислительного времени, а премиум-подписка расширяет это ограничение до 10 000 минут в месяц. Если этого недостаточно, есть альтернатива — развернуть собственный сервер и запустить GitLab Runner. В этом случае число пайплайнов ограничено только вычислительной мощностью вашего сервера. GitLab Runner можно подключить как к gitlab.com, так и к self-hosted версиям GitLab. Сегодня рассмотрим подключение к облачному GitLab. Подготовка инфраструктуры Gitlab Runner не предъявляет особых требований к аппаратному обеспечению сервера. Выбор конфигурации напрямую зависит от сложности пайплайнов и количества параллельных задач. Более того, Gitlab Runner запускается не только на Linux, но и на macOS, FreeBSD, Windows и z/OS. Также поддерживаются восемь архитектур, от ожидаемых x86 и AMD64 до ARM, RISC-V и даже IBM-мейнфреймов. Начнем с сервера конфигурации 1 vCPU, 2 GB RAM, 50 GB SSD. Заказ сервера. Заходим в панель управления Selectel: Продукты → Облачные серверы → Создать сервер. Выбираем 1 vCPU, 2 GB RAM, 50 GB Универсальный SSD и Ubuntu 26.04 в Санкт-Петербурге, ru-9a. В этой версии Ubuntu SSH-ключ обязателен, поэтому добавляем свой ключ. Когда вся информация заполнена, нажимаем Создать сервер. После появления сервера в его карточке будет инструкция по подключению. Проверяем. Сервер доступен. Развертывание Gitlab Runner Runner можно развернуть «на железе» и в контейнерах. Для развертывания «на железе» доступна установка отдельного пакета или установка через репозитории. Для контейнеризации доступны Docker-контейнер, Helm Chart, Agent и Operator для Kubernetes. Для демонстрации простоты установки выберем наименее автоматизированный путь — установку отдельного пакета. При заказе сервера отмечено, что конфигурации на процессорах AMD, отсюда понимаем, что архитектура процессора — amd64. Иногда ее называют x86_64 (это значение видно в выводе команды uname -a), но GitLab понимает только amd64. Скачиваем пакет, подставляя архитектуру по шаблону gitlab-runner_${arch}.deb: Устанавливаем скачанные пакеты: Для работы GitLab Runner нужна единственная зависимость — git. Если она уже есть в системе, то пакеты успешно установятся. Если же ее нет, то пакетный менеджер сообщит об этом: Ошибка исправляется одной командой: GitLab Runner установлен. Осталось связать его с проектом в GitLab. Подключение к Gitlab Список runner’ов. В левом меню переходим в Build → Runners в левом меню и нажимаем Create Group Runner. Меню добавления runner’а. Настройки раннера минимальны: можно задать теги, по которым runner будет выбирать себе задания, или разрешить принимать неразмеченные задания. Также можно сделать выделенный runner для защищенных веток или вовсе временно приостановить его работу при создании, чтобы он не брал джобы до завершения настройки. Окно регистрации. После создания «карточки» нужно связать процесс на сервере с GitLab. Для этого выполняем команду, которая передает URL сервера и секретный токен (команда указана на странице регистрации). Токен не следует передавать третьим лицам, поэтому в статье он обрезан: При выполнении этой команды gitlab-runner попросит уточнить конфигурацию. Наиболее важный параметр конфигурации — режим выполнения (executor). Он определяет, в каком окружении будут выполняться задания из GitLab. В статье выбран shell, в этом случае все команды исполняются непосредственно в операционной системе, где установлен gitlab-runner. shell является наиболее простым и понятным режимом запуска заданий, однако исполняемые задания имеют доступ к серверу и слабо изолированы друг от друга. Это может привести к конфликтам при параллельном выполнении. Этот способ подходит для сборки ОС-специфическими инструментами, например, на Windows или macOS. Второй «простой» режим выполнения — docker. Каждое задание будет изолированно запускаться в собственном контейнере. Однако это потребует установки Docker на сервер. Несмотря на удобство изоляции, Docker-контейнеры ограничены ОС Linux, а запуск Docker внутри задания в этом режиме потребует настойки Docker-in-Docker (DinD). Универсального режима нет: выбор полностью зависит от выполняемых задач и действующих политик безопасности. Успешно запущенный раннер. После регистрации статус раннера можно увидеть на странице Build → Runners. Обратите внимание на идентификатор #58254123 (Ogchk0qL), это пригодится позже. Отключение «публичных» раннеров. Теперь заходим в настройки проекта: Settings → CI/CD и отключаем переключатель Enable instance runners for this group. Этим действием мы отказываемся от «официальных» раннеров GitLab. Воспользоваться ими все равно не получится: GitLab требует идентификацию по иностранному номеру телефона. Теперь можем проверить работоспособность. Тестирование Создаем в корне репозитория файл .gitlab-ci.yml такого содержания: Выполняем git commit и git push. Успешно выполненное задание. Если все сделано правильно, задания пайплайна будут выполнены на развернутом нами GitLab Runner. Это идентифицируется по имени хоста (hostname) runner и по идентификатору #58254123 (Ogchk0qL) в правом меню.