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

Переключение с 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 при миграции, если не предусмотрен...

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 и т.п.). Пример...

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

Самый безопасный путь — не экспортировать секреты в открытом виде. Настройте интеграцию 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, Безопасность и секреты.

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

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

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

# .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

# Установка
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"

# В 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

# 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

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

kind: pipeline
name: default

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

trigger:
  event:
  - push

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

Комментарии (0)

Проблема GitHub Actions в РФ

Шаг 1: GitLab CI базовый

Шаг 2: self-hosted runners

Шаг 3: secrets

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

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