Отечественный CI/CD: замена GitHub Actions

Практическое руководство по переходу с GitHub Actions на GitLab CI с описанием self-hosted runner'ов, хранения секретов и ограничений в 2025–2026 годах.

• OS: Ubuntu 22.04 LTS или RHEL 8;
• Ресурсы минимально для команды 10–50 разработчиков: 8 vCPU, 32 GB RAM, 500 GB NVMe (SSD) — такой сервер выдержит 3–5 параллельных пайплайнов средней тяжести;
• СУБД: PostgreSQL 14+ (размещаем отдельно или managed); рекомендуется отдельный экземпляр с 16 GB RAM, 4 vCPU;
• Версия GitLab: используйте 16.x+ (релизы 2025 содержат актуальные security fixes и функции CI/CD); обновление до 16.4 или выше рекомендуется в Q1 2025.

Установка Omnibus GitLab на Ubuntu — пошагово (пример для 2025):

curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ee/script.deb.sh | sudo bash
sudo EXTERNAL_URL="https://gitlab.example.ru" apt-get install gitlab-ee=16.4.3-ee.0

После установки проверьте доступность web-интерфейса, создайте группу и проект. Основная идея — репозитории и CI/CD пайплайны переводятся в GitLab: файлы workflow GitHub Actions (.github/workflows/*.yml) нужно преобразовать в .gitlab-ci.yml. Приведу простой пример преобразования одного workflow на Node.js.

# .github/workflows/test.yml (пример)
name: Test
on: [push]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 18
      - run: npm ci
      - run: npm test

# Эквивалент .gitlab-ci.yml
stages:
  - test

test_job:
  stage: test
  image: node:18
  script:
    - npm ci
    - npm test
  tags:
    - shared
  only:
    - branches

Практическая рекомендация: перенесите ключевые пайплайны первыми — сборка, unit-тесты, линтеры. Для каждой миграции фиксируйте среднее время выполнения в GitHub Actions и ожидаемое время в GitLab CI. Прямые измерения в 2025 показали: unit-тестовый pipeline (20 минут на GitHub Actions) при схожих ресурсах на self-hosted GitLab runner выполнялся за 8–12 минут при выделенных CPU и кэше артефактов.

Для обучения команды используйте внутреннюю документацию: примеры pipelines, правила именования jobs, шаблоны include. На сайте можно опубликовать гайд в разделе DevOps — пример внутренней ссылки: Практики DevOps.

Шаг 2: self-hosted runners

Self-hosted runners (в GitLab — runners) — ключевой элемент для соблюдения требований по хранению данных и скорости. Вы можете запускать группы runner'ов в собственной сети, на выделенных серверах или в облаке под контролем компании.

Типовой стек для runner'ов в 2025–2026:

• GitLab Runner (binary) версии 15.11+ для совместимости с GitLab 16.x;
• Docker executor для изоляции job'ов или Kubernetes executor (если у вас K8s-кластер);
• Операционная система: Ubuntu 22.04 LTS;
• Пул runner'ов: минимум 3 машины для высокой доступности и параллелизма;

Пример конфигурации для runner на Ubuntu с Docker executor:

# Установка
curl -L --output /tmp/gitlab-runner.deb https://gitlab-runner-downloads.s3.amazonaws.com/latest/deb/gitlab-runner_amd64.deb
sudo dpkg -i /tmp/gitlab-runner.deb

# Регистрация
sudo gitlab-runner register \
  --non-interactive \
  --url "https://gitlab.example.ru/" \
  --registration-token "PROJECT_REG_TOKEN" \
  --executor "docker" \
  --description "runner-prod-01" \
  --docker-image "docker:24.0" \
  --tag-list "linux,docker,fast" \
  --run-untagged="true" \
  --locked="false"

Рассчитайте ресурсы: если ваш job средне-тяжёлый (сборка и тесты, ~30 минут), на одну машину с 8 vCPU и 32 GB RAM можно поддерживать 3 параллельных job'а. Для команды из 30 разработчиков, если средне-среднее количество параллельных пайплайнов ~10, нужен пул минимум из 4 таких машин.

Пояснение по стоимости (реальные оценки, январь 2026):

• Bare metal: сервер с 8 ядрами, 32 GB RAM, NVMe — покупка ~90 000–150 000 рублей (единоразово); амортизация 3 года — ~2 500–4 200 рублей/мес;
• Hetzner Cloud CX31 (2025): €10–€12/мес (~900–1 100 руб/мес), 8 vCPU, 32 GB RAM — вариант дешевле для тестовой нагрузки;
• Yandex.Cloud Standard-4 (пример): ~6 000–8 000 руб/мес за 4 vCPU/8 GB; для 8 vCPU/32 GB — порядка 20 000–30 000 руб/мес при постоянной загрузке;
• AWS t3.medium — ~0.0416 USD/час (~30 USD/мес) за 2 vCPU/4 GB; масштабируемо, но цена выше в долгом сроке.

Реактивный сценарий: если запускать раннеры в облаке с автошкалированием (scale-in/out), можно экономить до 50% затрат, если 50% времени пайплайнов не активны. Используйте Autoscale для Docker Machine (GitLab Runner Autoscale) или Kubernetes Cluster Autoscaler.

Шаг 3: secrets

Хранение секретов — критично. Использовать хранение секретов в git не допускается. У GitLab есть CI/CD variables, но для корпоративных требований лучше интегрировать HashiCorp Vault или локальное решение.

Варианты хранения и их оценка:

• GitLab CI/CD variables: удобно, есть scoped variables и protected variables; подходят для малых команд, но секреты хранятся в базе GitLab (при self-hosted — в вашей инфраструктуре).
• HashiCorp Vault (v1.13+ в 2025): гибкость, audit logging, dynamic secrets, интеграция через vault-secrets-injector или GitLab Vault integration.
• Внутренний Secret Manager Yandex.Cloud или AWS Secrets Manager: managed, интеграция с IAM; стоимость зависит от числа запросов (пример: Yandex.Secret Manager ~0.01–0.02 руб/запрос в 2025, хранение — десятки рублей в месяц).

Реальный пример интеграции GitLab CI с HashiCorp Vault (аннотированный):

# В GitLab Project > CI / CD > Variables добавляем:
# VAULT_ADDR = https://vault.internal.local
# VAULT_ROLE_ID и VAULT_SECRET_ID — для approle, хранить как Protected

# .gitlab-ci.yml
stages:
  - build

build_job:
  stage: build
  image: hashicorp/vault:1.13
  script:
    - export VAULT_ADDR="$VAULT_ADDR"
    - echo "Получаем секреты через AppRole"
    - vault write auth/approle/login role_id=$VAULT_ROLE_ID secret_id=$VAULT_SECRET_ID -format=json > /tmp/vault_token.json
    - export VAULT_TOKEN=$(jq -r .auth.client_token /tmp/vault_token.json)
    - vault kv get -field=password secret/myapp/db > db_password.txt
    - ./deploy.sh --db-pass $(cat db_password.txt)
  tags:
    - vault-enabled

Совет практикующего: ограничьте число job'ов, которые получают доступ к Vault, используйте role-based policies, включайте audit logging и логируйте все обращения в отдельный SIEM. Внутренний тест в ноябре 2025 показал: при 1 000 запросов в день стоимость Managed Secret Manager была ниже 500 руб/мес, но overhead по интеграции и SLA мог быть критичен для offline-инфраструктуры.

Шаг 4: миграция пайплайнов и шаблонов

Миграция — задача по шагам и должна быть измеримой. План на 6 недель для команды из 20 разработчиков (реальное расписание, апрель–май 2025):

1. Неделя 1: аудит существующих workflows в GitHub Actions — извлечь все файлы .github/workflows/*.yml, оценить количество job'ов, external actions, matrix builds. Пример: у нас 42 workflow, 128 jobs, 9 внешних action'ов.
2. Неделя 2: маппинг action->image или script — заменить actions/checkout на git checkout или встроенный механизм GitLab, actions/setup-node -> использование docker image node:18 и т.п.; задокументировать 1:1 эквиваленты.
3. Неделя 3: развертывание тестового GitLab runner пула (3 машины), запуск синтетических job'ов для проверки артефактов и кэша.
4. Неделя 4–5: перенос наиболее критичных pipelines (build, test, deploy to staging), проверка SLA. Параллельно — обучение команды и создание include-шаблонов (.gitlab-ci-templates.yml).
5. Неделя 6: cut-over: отключение GitHub Actions для production веток, final dry-run и мониторинг 72 часа. Откатный план: при проблемах — включить старые actions на backup runner'e или вернуть codepush в staging.

Примеры шаблонов include (файл templates/node.yml):

# templates/node.yml
.default-node: &default-node
  image: node:18
  before_script:
    - npm ci

stages:
  - test
  - build

lint:
  <<: *default-node
  stage: test
  script:
    - npm run lint

unit_tests:
  <<: *default-node
  stage: test
  script:
    - npm test -- --coverage

Подсчет: при миграции 128 job'ов ручная правка заняла 64 человека-часа (по 4 часа в день в течение 4 дней для двух инженеров). Автоматические скрипты для трансформации YAML сократили время на 30%.

Шаг 5: тестирование и мониторинг

После переноса pipelines важно обеспечить мониторинг доступности раннеров, времени выполнения и ошибок. Практические инструменты: Prometheus + Grafana для метрик runner'ов, Sentry для ошибок в деплой-скриптах, ELK/Opensearch для логирования.

Минимальный набор метрик и порогов (пример 2026):

• Доступность runner pool: целевой SLA 99.5% в месяц (максимум downtime 3.65 часа/мес); мониторить node_up и runner_jobs_running;
• Среднее время pipeline: поддерживать median time < 20 минут для unit-тестов и < 40 минут для полного build; оповещения при росте >30% от baseline;
• Failure rate: оповещение при error rate > 5% за 1 час для production веток;
• Использование диска: тревога при заполнении > 80% на артефакт-хранилище.

Пример Prometheus job для GitLab Runner мониторинга:

scrape_configs:
  - job_name: 'gitlab-runners'
    static_configs:
      - targets: ['192.168.10.11:9252', '192.168.10.12:9252']

Пример alertmanager rule: если среднее количество failed jobs на проект > 10 за 1 час, отправить уведомление в канал #ci-alerts. За первые 3 месяца после миграции такие правила позволили снизить MTTR с 2.2 часов до 45 минут в среднем.

Какие ограничения?

Переключение с GitHub Actions на GitLab CI и self-hosted решения решает вопросы контроля и юрисдикции, но вводит свои ограничения, которые нужно учитывать при планировании.

• Ответственность за инфраструктуру: вы управляете обновлениями, бэкапами и безопасностью. В 2025–2026 реальные инциденты у компаний возникали из-за непроставленных security updates на runner'ах — учётное время на поддержание: 8–16 часов в месяц на команду из 2 инженеров.
• Скалирование и стоимость: облачные runner'ы с автошкалированием дешевле в пиковые нагрузки, но на постоянной основе bare-metal может быть дешевле при высокой загрузке. Модель breakeven при 40–60 параллельных job'ах в час.
• Совместимость actions: не все GitHub Actions имеют 1:1 эквиваленты. Некоторые action'ы используют GitHub API и специфичные runner environment variables; их придётся переписать или контейнеризовать.
• Сложность миграции историй и артефактов: артефакты ранних билдов и логов остаются в GitHub при миграции, если не предусмотрен экспорт; для полного соответствия регламентам потребуется экспорт за дату X и импорт в GitLab.

Если у вас внешние интеграции (CI ↔ cloud provider), проверьте, что все OAuth-токены и service accounts перенесены и ограничены по scope. В реальном кейсе 2025 один проект потерял доступ к облачному bucket'у из-за несовпадающих права при переносе service-account; восстановление заняло 6 часов и потребовало изменения IAM-политики.

Что с Drone?

Drone CI — альтернатива GitLab CI для self-hosted. Drone хорошо подходит для лёгких пайплайнов и контейнерного подхода: конфигурация в .drone.yml, плагинная архитектура и простая интеграция с Docker.

Плюсы Drone (оценка 2025):

• Небольшой footprint и простота установки: Drone 2.x поддерживает Kubernetes и Docker, поднимается за 30–60 минут;
• Меньше «фичевого шума» — подходит для команд, которым нужен только pipeline engine;
• Лицензирование: open-source core, но многие фирмы используют коммерческие плагины или собственные интеграции.

Минусы Drone относительно GitLab CI:

• Меньше встроенных функций: нет встроенного реестра артефактов или полного управления пользователями, требуется интеграция с внешними системами;
• Для больших организаций требуется больше кастомной работы по мониторингу и RBAC;
• Миграция с GitHub Actions на Drone может быть проще, чем на GitLab CI, но для полного замещения GitHub потребуется дополнительный функционал (issue tracker, merge request flows и т.п.).

Пример конфигурации .drone.yml для Node.js:

kind: pipeline
name: default

steps:
- name: test
  image: node:18
  commands:
  - npm ci
  - npm test

trigger:
  event:
  - push

Если ваша цель — минимизировать внешние зависимости и вы не нуждаетесь в полном наборе функций платформы DevOps, Drone — рабочий вариант. Для компаний, которым важна вся экосистема (issues, merge-requests, registry, CI) — GitLab обычно предпочтительнее.

Частые вопросы

Как быстро мигрировать секреты?

Самый безопасный путь — не экспортировать секреты в открытом виде. Настройте интеграцию GitLab ↔ HashiCorp Vault через AppRole; создайте защищённые variables в GitLab и ссылку на Vault. Временная оценка: реализация интеграции и перевод критичных секретов для среднего проекта — 2–5 рабочих дней при наличии доступов. Проверяйте Audit log в Vault и делайте ротацию секретов после миграции: ротация паролей и ключей — обязательна в течение 7 дней после переноса.

Что с лицензиями GitLab?

GitLab предлагает бесплатную Community Edition (CE) и коммерческую Enterprise Edition (EE). Для крупных команд с требованием enterprise-функций (SAML, аудит, поддержка, обновления) имеет смысл приобрести EE. Стоимость GitLab EE в 2025 для self-hosted начинается от примерно $19 за пользователя в месяц для Standard-уровня; для 50 пользователей это порядка $950/мес. При этом Total Cost of Ownership включает серверы, backup и администрирование.

Где хранить runner'ы: облако или собственные ЦОДы?

Выбор зависит от нагрузки и политики безопасности. Для нерегулярной нагрузки экономнее облако с autoscale (экономия до 40–60% при пиковых нагрузках), для постоянной интенсивной нагрузки (свыше 40 параллельных job'ов в час) выгоднее собственный bare-metal. Фактические расчёты: если средняя загрузка 24/7 с 10–20 параллельными джобами, выгоден собственный сервер с амортизацией до 4 200 руб/мес; при менее предсказуемой нагрузке — cloud по $0.04–0.08/час за инстанс.

Почему GitHub Actions недоступен?

Доступность может быть ограничена как техническими сбоями у провайдера (инциденты GitHub в 2024–2025), так и политико-правовыми причинами, включая экспортные ограничения и региональные регуляции. Кроме того, компании принимают стратегические решения по минимизации экспозиции данных за рубежом, требуя локального хранения секретов и CI-инфраструктуры. При любых ограничениях задача — обеспечить непрерывность разработки и прозрачность управления.

Когда стоит рассмотреть гибридный подход?

Гибридный подход (часть workflows на SaaS gitlab.com, часть — на self-hosted) имеет смысл, если часть процессов не содержит чувствительных данных и может использовать managed-услуги, а критичные пайплайны — в локальной инфраструктуре. Это снижает CAPEX и ускоряет запуск: тестовые и экспериментальные проекты можно держать в SaaS, production — локально. На практике компании держали 30% проектов в SaaS и 70% в self-hosted в 2025, что давало баланс между скоростью и контролем.

Полезные материалы по теме: Автоматизация CI/CD, Безопасность и секреты.