Настройка GitLab Runner — это тот самый фундамент, на котором держится вся автоматизация вашего пайплайна. Если сделать это неправильно, вы будете постоянно сталкиваться с «плавающими» ошибками, долгими сборками и головной болью. Давайте разберем, как настроить раннер правильно, надежно и с учетом современных практик.
Что такое "ci cd gitlab runner настройка" и почему это нужно?
Представьте, что ваш CI/CD пайплайн — это конвейер на заводе. GitLab CI — это диспетчер, который говорит, что и когда делать. А GitLab Runner — это рабочие руки, которые выполняют инструкции: собирают код, запускают тесты, разворачивают приложения. Настройка раннера — это процесс "найма" и обучения этих рабочих: где они будут работать (на вашем сервере, в облаке, в Kubernetes), какие у них будут инструменты (Docker, shell) и как они будут общаться с диспетчером.
Важно: Runner — это отдельное приложение, которое работает независимо от основного сервера GitLab. Его можно установить куда угодно, что дает гибкость, но и добавляет ответственности за его настройку и безопасность.
Критерии выбора (Таблица из 5 параметров)
Прежде чем ставить раннер, нужно понять, какой тип вам нужен. Вот ключевые параметры для принятия решения:
| Параметр | Варианты | Когда выбирать |
|---|---|---|
| Исполнитель (Executor) | Shell, Docker, Kubernetes, SSH | Docker — для изоляции, Shell — для скорости на «голом» железе, K8s — для нативной работы в кластере. |
| Тип регистрации | Shared, Group, Specific | Specific — для критичных проектов, Group — для команд, Shared — для общих задач (например, линтинг). |
| Масштабируемость | Один инстанс, Docker Machine, K8s Autoscale | Для предсказуемых нагрузок хватит одного, для пиков — механизмы автоскейлинга. |
| Безопасность | Изолированная сеть, ограниченные теги, внутренний доступ | Чем выше уровень изоляции (например, отдельная VPC), тем безопаснее. |
| Стоимость владения | Свои серверы, Управляемые сервисы (GitLab.com, облачные VM) | Свои серверы — контроль, но и overhead. Управляемые сервисы — простота, но меньше гибкости. |
Топ-3 подхода к развертыванию Runner
На рынке нет единого "лучшего" решения, есть подходы, которые подходят под разные задачи.
1. Docker Executor на выделенной VM
Классика. Вы поднимаете виртуальную машину в облаке (например, Yandex Cloud или AWS EC2), устанавливаете там Docker и регистрируете раннер с executor = "docker". Это дает хорошую изоляцию jobs через контейнеры и относительно простую настройку.
2. Kubernetes Executor в своем кластере
Современный и гибкий подход. Runner работает как pod в вашем Kubernetes-кластере, а каждое задание (job) запускается в отдельном, временном pod. Идеально, если ваша инфраструктура уже завязана на K8s.
3. GitLab.com Shared Runners (управляемые)
Самый быстрый старт. GitLab предоставляет свои раннеры "из коробки". Не нужно ничего настраивать, но есть ограничения по времени выполнения, безопасности и предустановленному ПО. Отлично подходит для небольших проектов и Open Source.
Детальное 10-балльное сравнение подходов
- Скорость настройки: GitLab.com (10/10), Docker VM (6/10), K8s (4/10).
- Гибкость конфигурации: K8s (9/10), Docker VM (8/10), GitLab.com (3/10).
- Масштабируемость: K8s (10/10), Docker VM (7/10), GitLab.com (8/10 — но не вами).
- Изоляция безопасности: K8s (9/10), Docker VM (8/10), GitLab.com (5/10).
- Стоимость: GitLab.com (бесплатно в лимитах), Docker VM (зависит от размера VM), K8s (стоимость кластера).
- Производительность: Docker VM (9/10 — ресурсы выделены), K8s (8/10), GitLab.com (7/10 — общие ресурсы).
- Поддержка кэширования: Docker VM (легко настраивается на диске), K8s (требует настройки volume), GitLab.com (встроенное).
- Обслуживание: GitLab.com (0/10 — не ваша забота), Docker VM (5/10 — обновления ОС/Docker), K8s (6/10 — обновления кластера).
- Интеграция с инфраструктурой: K8s (10/10 если все в K8s), Docker VM (7/10), GitLab.com (3/10).
- Порог входа: GitLab.com (10/10), Docker VM (6/10), K8s (3/10).
Мой личный выбор и почему
Я долгое время был сторонником Docker Executor на выделенных VM. Это надежно и предсказуемо. Но в 2024-2025 годах мой выбор сместился в сторону Kubernetes Executor с автоскейлингом. Почему?
История из практики: У нас был проект с очень неравномерной нагрузкой: утром все разработчики пушат код, а ночью пайплайны почти не работают. На VM-раннерах мы либо простаивали (и платили за простой), либо не справлялись с пиком. Миграция на K8s с использованием autoscaler позволила сократить средние затраты на 40%, а время ожидания в очереди (queue time) — с 15 минут до 30 секунд в пик. Настройка, конечно, была сложной, но окупилась.
Экспертный совет: Не начинайте с Kubernetes, если только осваиваете CI/CD. Возьмите Docker на VM, отстройте пайплайн, поймите свои потребности. Затем уже планируйте миграцию на K8s для масштабирования.
Руководство по реализации (Docker Executor на Linux)
Давайте настроим раннер на Ubuntu 22.04. Это базовый и рабочий вариант.
Шаг 1: Установка Docker и GitLab Runner
# Установите Docker
sudo apt-get update
sudo apt-get install -y docker.io
sudo systemctl enable --now docker
# Добавьте текущего пользователя в группу docker (требует перелогина)
sudo usermod -aG docker $USER
# Установите GitLab Runner
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash
sudo apt-get install -y gitlab-runner
Шаг 2: Регистрация раннера
Вам понадобятся URL вашего GitLab и токен. Токен можно взять в Settings -> CI/CD -> Runners (для группового или специфичного раннера).
sudo gitlab-runner register \
--non-interactive \
--url "https://gitlab.example.com/" \
--registration-token "PROJECT_REGISTRATION_TOKEN" \
--executor "docker" \
--docker-image "alpine:latest" \
--description "My Docker Runner" \
--tag-list "docker,linux" \
--run-untagged="false"
Внимание: Указание --run-untagged="false" означает, что этот раннер будет запускать только джобы с соответствующими тегами (например, docker). Это хорошая практика для разделения окружений.
Шаг 3: Базовая конфигурация
Основной файл конфигурации: /etc/gitlab-runner/config.toml. Вот важные настройки для Docker executor:
concurrent = 4 # Сколько jobs может выполняться одновременно
check_interval = 3
[[runners]]
name = "My Docker Runner"
url = "https://gitlab.example.com/"
token = "..."
executor = "docker"
[runners.docker]
tls_verify = false
image = "alpine:latest"
privileged = false # Ставьте true только если нужен доступ к Docker daemon (docker-in-docker)
shm_size = 0
volumes = ["/cache", "/var/run/docker.sock:/var/run/docker.sock"] # Осторожно с sock!
[runners.cache]
Type = "s3" # Рекомендую использовать S3-совместимое хранилище для кэша
Shared = true
Ключевые выводы
- Не используйте Shared Runner для продакшена. Вы не контролируете их среду и безопасность.
- Всегда используйте теги. Это четко разделит, какой раннер какую работу выполняет.
- Настройте кэширование. Без него каждая сборка будет начинаться с чистого листа, тратя время и трафик.
- Заложите время на обслуживание. Раннеры требуют обновлений, мониторинга и очистки диска.
- Документируйте конфигурацию. Файл
config.tomlдолжен храниться в git как Infrastructure as Code.
FAQ (Часто задаваемые вопросы)
Как ограничить доступ раннера к секретным переменным?
Используйте Protected Tags и Protected Branches. Настройте раннер так, чтобы он был доступен только для защищенных веток, и назначайте ему соответствующие теги. Тогда переменные, помеченные как Protected, не будут раскрываться в джобах на незащищенных ветках.
Почему мой Docker job не может запустить другой контейнер (docker-in-docker)?
Вам нужно либо запустить раннер в привилегированном режиме (privileged = true), что небезопасно, либо использовать специальные образы с установленным Docker и монтировать сокет (/var/run/docker.sock). Лучшая практика — использовать отдельные шаги (stages) и кэшировать артефакты, чтобы избежать DinD.
Как очистить диск от старых Docker-образов?
Добавьте в cron задачу: docker system prune -a -f --volumes. Или настройте политики в самом Docker daemon (/etc/docker/daemon.json).
Где взять актуальную документацию?
Официальная документация GitLab обновляется постоянно: https://docs.gitlab.com/runner/. Также следите за блогом GitLab — там появляются анонсы новых функций, например, для раннеров на ARM-архитектуре.