Налаштування 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'ів
| Executor | Ізоляція | Час старту | Безпека | Масштабування |
|---|---|---|---|---|
| Shell | Немає | Миттєво | Низька | Ручне |
| Docker | Так | 1–3 с | Середня | Ручне/авто |
| Kubernetes | Так | 10–30 с | Висока | Автоматичне |
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 секунд.
Порівняння стратегій кешування
| Тип кешу | Час запису | Економія часу | Складність налаштування |
|---|---|---|---|
| Без кешу | 0 с | 0% | Немає |
| Локальний (диск) | 1–3 с | до 30% | Низька |
| S3 (MinIO/AWS) | 2–5 с | до 40% | Середня |
При використанні 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-навантаження — напишіть нам, і ми оцінимо проект за один робочий день. Ви отримуєте готову інфраструктуру під ключ з гарантією стабільної роботи. Замовте консультацію, і ми підготуємо індивідуальну пропозицію.
