GitLab Runner на офшорном VPS: выделенный CI worker без лимитов

На небольших проектах достаточно запустить Runner рядом с GitLab сервером, но как только команда растёт и pipeline становятся тяжёлыми, удобнее вынести Runner на отдельный VPS. Причины:

• Изоляция нагрузки: тяжёлые CI job не тормозят основной GitLab. Разработчики продолжают делать commit и code review, пока на runner идут долгие тесты.
• Параллельные сборки: один Runner с concurrent = 4 на 8 vCPU держит 4 параллельных pipeline. На пиках добавляем второй VPS и Runner подхватывает job автоматически.
• Безопасность секретов: можно создать отдельные runner для production и staging веток, разделяя доступ к credentials.
• Docker-in-Docker без конфликтов: на выделенном VPS свободно гоняем docker build, docker push в registry, не задевая GitLab сервер.
• Юрисдикция Исландии и Румынии: Runner с доступом к исходному коду и секретам должен стоять в стране, где провайдер не передаёт данные иностранным регуляторам.

Anubiz Host выделяет KVM VPS под Runner с гарантированным CPU и NVMe дисками. Открытые порты позволяют Runner подключаться к любому внешнему GitLab серверу через HTTPS, а полный root даёт право ставить любые версии Docker, kubectl, golang и nodejs.

Выбор плана VPS зависит от executor и размера сборок. Базовые ориентиры для GitLab Runner 16.x:

• Shell executor, простые тесты: 2 vCPU, 4 ГБ RAM, 50 ГБ NVMe. План VPS M от $12/мес. Concurrent = 2.
• Docker executor, сборка образов: 4 vCPU, 8 ГБ RAM, 100 ГБ NVMe. План VPS L от $20/мес. Concurrent = 3-4. Включаем Docker layer cache.
• Docker-in-Docker, deploy в Kubernetes: 8 vCPU, 16 ГБ RAM, 200 ГБ NVMe. План VPS XL от $35/мес. Concurrent = 6-8.
• Kubernetes executor: Runner сам по себе требует минимум 2 vCPU и 4 ГБ RAM, но k8s кластер на отдельных VPS. План VPS M под controller, плюс 2-3 worker от $35/мес каждый.
• Кэш и артефакты: минимум 50 ГБ свободного места под /var/lib/gitlab-runner/cache. На тяжёлых node_modules или composer проектах кэш быстро забивает диск.

Все планы Anubiz Host используют NVMe, что критично для Docker layer cache и git clone больших монорепозиториев. На медленных дисках время сборки растёт в 2-3 раза, особенно на проектах с большим количеством мелких файлов.

GitLab Runner получает доступ к исходному коду и секретам проекта, поэтому компрометация Runner означает компрометацию всего пайплайна. Базовый чеклист защиты:

• Отдельный пользователь gitlab-runner: никогда не запускаем Runner от root. Создаём системного пользователя без sudo прав.
• Tags для group runner: привязываем runner к конкретным проектам через tags, чтобы не выполнять job из чужих репозиториев.
• Protected runner для production: отдельный VPS только под job из защищённых веток (main/master). Секреты deploy недоступны runner из feature веток.
• Docker rootless или Sysbox: чтобы не давать runner полный доступ к Docker daemon. Альтернатива Kaniko для сборки образов без daemon.
• Сетевая изоляция: Runner подключается к GitLab по HTTPS и наружу не нужен ничего больше. Закрываем входящие порты iptables.
• Очистка после job: shell_executor оставляет следы в /tmp, добавляем pre_clone_script и post_clone_script для wipe.
• Логи job не сохраняем дольше 14 дней: Admin Settings - CI/CD - Job artifacts expiration.

Anubiz Host не имеет доступа к данным внутри VPS клиента, и юрисдикция Исландии защищает Runner от запросов иностранных регуляторов. Оплата криптой и регистрация по email без KYC дают полную приватность владельцу CI инфраструктуры.