Настройка GitLab Runner Self-Hosted (регистрация, масштабирование)

Настройка GitLab Runner Self-Hosted (регистрация, масштабирование)

Ваш пайплайн стоит в очереди по 15 минут, пока shared runners GitLab.com заняты? Или безопасники требуют, чтобы сборочные контейнеры не уходили на чужие хосты? Наши инженеры настраивают собственные GitLab Runner уже 5 лет — для проектов с нагрузкой от 10 до 500+ джоб в день. Более 50 успешных внедрений в компаниях от стартапов до enterprise. Оценим вашу CI-инфраструктуру за один день и предложим архитектуру, которая снизит время ожидания в разы.

Как настроить GitLab Runner с Docker executor?

Самый популярный вариант — Docker executor, где каждая джоба запускается в изолированном контейнере. Регистрация runner'а одной командой:

gitlab-runner register \
  --non-interactive \
  --url "https://gitlab.company.com" \
  --token "glrt-xxxxxxxxxxxx" \
  --executor "docker" \
  --docker-image "alpine:latest" \
  --docker-volumes "/var/run/docker.sock:/var/run/docker.sock" \
  --docker-privileged

Флаг --docker-privileged нужен только для Docker-in-Docker (dind). Если dind не требуется — не используйте его: это расширяет привилегии контейнера до хостовых, что создаёт риски безопасности. Альтернатива — использовать docker:dind как sidecar-контейнер.

Ключевые настройки config.toml

После регистрации конфигурация лежит в /etc/gitlab-runner/config.toml. Параметр concurrent определяет, сколько джоб runner выполняет одновременно. Значение подбирается под ресурсы хоста: для 4-ядерной машины разумно 4–8. pull_policy = ["if-not-present"] уменьшает время старта джобы, так как образы кешируются локально. Без этой настройки runner при каждой джобе выполняет docker pull, что замедляет пайплайн и создаёт нагрузку на registry.

concurrent = 10

[[runners]]
  name = "docker-runner-prod"
  url = "https://gitlab.company.com"
  token = "glrt-xxxxxxxxxxxx"
  executor = "docker"
  [runners.docker]
    image = "alpine:latest"
    privileged = false
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache"]
    shm_size = 0
    pull_policy = ["if-not-present"]

Сравнение executor'ов

Kubernetes executor выигрывает в масштабировании: он автоматически запускает Pod для каждой джобы, а при пиковой нагрузке cluster autoscaler добавляет ноды. Это в 3–5 раз эффективнее статического Docker runner'а, когда днём нагрузка в 10 раз выше, чем ночью.

Почему стоит выбрать Kubernetes executor?

Для команд с переменной нагрузкой (ночью CI почти не используется, днём — пики) оптимальна связка runner в Kubernetes + Karpenter или Cluster Autoscaler. Деплоим runner через Helm:

helm repo add gitlab https://charts.gitlab.io
helm install gitlab-runner gitlab/gitlab-runner \
  --namespace gitlab-runner \
  --set gitlabUrl=https://gitlab.company.com \
  --set runnerToken=glrt-xxxxxxxxxxxx \
  --set rbac.create=true \
  --set runners.config="$(cat runner-config.toml)"

В runner-config.toml для Kubernetes executor указываем ресурсы: cpu_request: 100m, cpu_limit: 2, memory_limit: 2Gi. Это гарантирует, что каждая джоба не перегрузит кластер. При нехватке нод Karpenter поднимает новые за 60–90 секунд.

Сравнение стратегий кеширования

При использовании S3-кеша время повторных сборок сокращается на 35–40%, а затраты на хранение — минимальны. Мы интегрируем любой S3-совместимый бакет.

Что входит в настройку GitLab Runner под ключ?

Наша стандартная поставка включает:

• Выбор оптимального executor'а на основе профиля нагрузки.
• Регистрацию runner'а и настройку config.toml с правильными политиками pull, cache и security.
• Настройку кеша в S3 (MinIO, AWS S3, Yandex Object Storage) для ускорения последующих сборок — экономия до 40% времени на повторных джобах.
• Интеграцию с cluster autoscaler и Karpenter для автоматического масштабирования.
• RBAC-политики и NetworkPolicies для безопасной изоляции.
• Документацию по эксплуатации и runbook для типовых инцидентов.
• Гарантию работы конфигурации: если через месяц что-то сломалось — исправим бесплатно.

Это решение снижает расходы на CI-инфраструктуру на 30–50% в месяц по сравнению с shared runners.

Типичные проблемы при самостоятельной настройке

Runner отваливается после обновления токена. С версии GitLab 16.0 токены стали формата glrt-. Старые runner'ы с GR1348 перестают работать — требуется перерегистрация. Решение: gitlab-runner verify && gitlab-runner register с новым токеном.

Кеш не работает между джобами. Путь в cache.paths должен быть относительным. Например, для npm используйте - .npm/, а не абсолютный /app/node_modules. Иначе кеш не восстанавливается.

Docker socket vs dind. Монтирование /var/run/docker.sock даёт джобе root-доступ к Docker на хосте — это серьёзная дыра. Лучше использовать docker:dind как сервисный контейнер. Да, это замедляет сборку на 10–20%, но безопасность важнее. GitLab официально рекомендует dind для изолированных сборок.

Сроки и стоимость

Установка одного runner с Docker executor — 2–4 часа, если уже есть хост. Настройка масштабируемого решения на Kubernetes с кешем в S3 и RBAC — от 1 до 3 дней. Стоимость рассчитывается после аудита вашей CI-нагрузки — напишите нам, и мы оценим проект за один рабочий день. Вы получаете готовую инфраструктуру под ключ с гарантией стабильной работы. Закажите консультацию, и мы подготовим индивидуальное предложение.