Модуль 6. CI/CD и GitOps

В BI/DWH меняется всё: схемы БД, ETL/DAG, конфиги, версии коннекторов, дашборды, SSO-настройки. Цель CI/CD и GitOps — превратить хаотичные ручные выкаты в повторяемый, наблюдаемый и обратимый процесс:

CI (build/test): собирает артефакты (контейнеры, Helm-чарты, миграции Liquibase/Flyway, экспорт дашбордов).
CD (delivery): изменения попадают в репозиторий окружений, откуда их контроллер GitOps (Argo CD/Flux) приводит кластер в нужное состояние.
GitOps: кластер — это «отражение Git». Ревью через PR, аудит «кто/когда/что», быстрый rollback.

Ключевые выгоды для BI/DWH:

предсказуемые релизы и быстрые откаты;
безопасные миграции схем (expand/contract);
канареечные выкаты фронтов BI без простоя;
централизованное управление секретами;
контроль соответствия (policy-as-code, подписи образов).

Репозитории и границы ответственности

Минимальный набор репозиториев

app-repos — исходники и Dockerfile компонентов:
postgres-migrations, airflow-dags, superset-config, etl-jobs, trino-conf и т. п.
ops-charts — Helm-чарты/манифесты для приложений (или используем официальные чарт-репозитории с тонкими оверлеями).
env-repo (главный в GitOps) — описывает «что должно стоять» в Dev/Stage/Prod: версии образов, значения Helm, Kustomize-оверлеи, Argo Applications, секреты-ссылки.

Небольшим командам удобно начинать с двух реп: app и env. Крупным — разносить «код» и «операции» отдельно.

Шаблон дерева env-repo (пример)

env/
  clusters/
    prod/
      apps/
        airflow/   (helmrelease/values.yaml или kustomize overlay)
        superset/
        postgres/
      argocd-apps/ (Application/ ApplicationSet)
    stage/
    dev/
  policies/        (OPA/Kyverno, PodSecurity, NetworkPolicy по умолчанию)
  secrets/         (ExternalSecrets/SealedSecrets/SOPS файлы-ссылки)

Helm vs Kustomize — что выбрать

Helm — пакеты с шаблонами и переменными. Отличен для приложений с множеством опций (Airflow, Superset, Postgres-операторы).
Kustomize — «патч-оверлеи» поверх чистых YAML. Удобно для системной конфигурации, сетевых политик, Argo-объектов.
Комбинация: Helm для приложений, Kustomize для обвязки окружений и кросс-ресурсных патчей.

Практика показывает: HelmRelease/Helm-в-Argo + Kustomize overlays — гибко и прозрачно.

Argo CD vs Flux — критерии выбора

Argo CD: UI из коробки, «app-of-apps», ApplicationSet, Pre/Post-Sync hooks, Rollouts (канареечные/blue-green). Популярен для data-платформ.
Flux: декларативность через CRDs, сильный Git-пуллинг, меньше UI, глубже интеграция в Git-события.

Рекомендация: стартовать с Argo CD за счёт отличного UX и зрелого community-практикума.

Промо окружений Dev → Stage → Prod

Принцип «двух реп» и tag-promotion

CI апп-репозитория собирает образ, подписывает (cosign), публикует в регистр, создаёт git-тег vX.Y.Z.
Бот CI создаёт PR в env-repo (dev-оверлей) с обновлённой версией образа.
После тестов в Dev — PR в Stage; затем — в Prod.
Argo CD подхватывает изменения и синхронизирует кластеры.

Механика: иммутабельные версии (semver/commit-sha), никаких latest.

Политика контроля изменений

Обязательный PR-review (2 глаза), авто-чекапы (OPA/Kyverno, schema lint).
Аннотации релизов → Grafana для сопоставления метрик и выката.
«Заморозка» окружения в окна пиковых продаж/отчётности.

Канареечные релизы

Где это нужно

BI-фронты (Superset/Metabase), промежуточные микросервисы, прокси, API.
Не применяем для первичных БД и операторов — там другие стратегии (см. ниже).

Инструменты

Argo Rollouts (поверх Deployment): трафик-сплит через Ingress/Service, прогрев по шагам, автоматический или ручной прогресс.
Критерии продвижения: рост 5xx на Ingress, p95 latency, собственные тесты здоровья.

Для Superset: canary на 10%/25%/50% трафика; откат при росте ошибок экспорта/авторизации.

Миграции схем: Liquibase/Flyway и «expand/contract»

Принцип

Expand: сначала добавляем новые сущности/колонки/индексы, совместимые со старой версией кода.
Migrate data: фоновые переносы/заполнение новых колонок, пересчёты.
Contract: удаляем старое только после того, как весь код перешёл на новое.

Как запускать миграции в GitOps

Паттерны:

PreSync/Sync hooks в Argo CD: миграция как Job перед развёртыванием приложения (для небольших схем).
Отдельный HelmRelease/Argo Application «migrations»: явный шаг, можно катить/откатывать независимо.
Airflow-DAG-миграции для тяжёлых backfill’ов (с checkpoint’ами и мониторингом).

Практические правила:

Миграции идемпотентны и повторяемы.
Всегда есть PITR/бэкап (см. Модуль 2) перед изменением.
Backfill — отдельный выпуск, чтобы не блокировать быстрый выкат приложения.
Миграции выполняются с минимальными блокировками (по возможности CONCURRENTLY, батчи).

Управление секретами в пайплайнах

Где хранить секреты: Vault/Cloud Secret Manager → в k8s через External Secrets Operator; альтернативы — SOPS/SealedSecrets для «статичных» значений.
В CI: подключение к реестру, подпись образов (cosign), креды к артефакт-стораджу — через OIDC-федерацию или краткоживущие токены (не хранить в переменных навсегда).
Dynamic creds: Vault Database Engine для краткоживущих пользователей БД (ideally для ETL и ад-hoc миграций).
Проверки пайплайна: «секреты в yaml» (secret-scanners), запрет kubectl apply «мимо GitOps».

Контроль соответствия и качество релизов

Политики: Gatekeeper/Kyverno (запрет привилегий, допустимые реестры, обязательные ресурсы), валидация подписей образов (cosign).
Проверки в CI: линтеры Helm/Kustomize, schema-валидация CRD, trivy-скан образов, unit-тесты DAG/SQL.
Release-gates: smoke-тесты, пост-деплой проверки SLI/SLO (Inkubate/Probes), «canary-ok → promote».

Риски и как их снимать

Риск	Проявление	Митигирующие меры
Смешивание кода и окружения	Неясно, что «поедет» в Prod	Разделить app-repos и env-repo; только env-repo — источник CD
Канареечный успех «на бумаге»	Трафик не сплитится/метрики не читаются	Argo Rollouts, интеграция с Ingress, явные SLO-гейты
«Схема вперёд кода»	Падения из-за несовместимости	Expand/contract, фича-флаги, двустадийный релиз
Миграции без PITR	Невозможность отката	Обязательный бэкап/точка восстановления перед изменением
Секреты в Git	Утечки	ESO/Vault, SOPS, сканеры секретов, OIDC-федерация
Rollback «ломает» данные	Обновили схему, откатили код	Контрактная совместимость, поэтапное отключение старого
«Шумные» алерты в релиз-окна	Слепота к настоящим проблемам	Особые SLO-порогы на период canary, аннотации релизов в Grafana
Случайный kubectl apply в прод	Обход GitOps	Read-only доступ, Admission-Webhook, аудит API-сервера

Мини-примеры (только необходимый код)

Argo CD Application (env-repo, Stage)

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: superset-stage
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://git.company/env
    path: clusters/stage/apps/superset
    targetRevision: main
  destination:
    server: https://kubernetes.default.svc
    namespace: bi
  syncPolicy:
    automated: { prune: true, selfHeal: true }
    syncOptions: ["CreateNamespace=true"]

Kustomize overlay (управление версиями образов)

# clusters/stage/apps/superset/kustomization.yaml
resources:
- ../../base/superset
images:
- name: apache/superset
  newTag: 3.1.0-2025-08-10 # продвижение через PR
configMapGenerator:
- name: superset-config
  literals:
  - FEATURE_FLAG_CANARY_ROUTES=true

(Дальше всё зашито в Git: PR меняет newTag, Argo CD синхронизирует.)

Практика: полноценный GitOps для «Postgres + Airflow + Superset»

Цель практики

Подготовить env-repo (Dev/Stage/Prod) и подключить его в Argo CD.
Завести приложения: Postgres (оператор или StatefulSet), Airflow (официальный Helm), Superset (официальный Helm).
Организовать миграции Postgres (Liquibase/Flyway), выпуск DAG и канареечный релиз Superset.
Настроить секреты через External Secrets и промо Dev→Stage→Prod через PR.

Шаги

Развернуть Argo CD в платформенном неймспейсе.
- Создать Application уровня «app-of-apps»: clusters/dev, clusters/stage, clusters/prod.
- Включить RBAC и SSO к Argo (OIDC) — чтобы доступ был по ролям.
Подготовить env-repo:
Дерево clusters/{dev,stage,prod}/apps/{postgres,airflow,superset}.
Для Postgres — либо оператор (Patroni/StackGres), либо простой StatefulSet (для практики).
Для Airflow и Superset — использовать официальные charts, вынести values.yaml в каждый оверлей.
Добавить ExternalSecret для подключений БД и SSO секретов (см. Модуль 4).
postgres-migrations: pipeline собирает Liquibase-контейнер (или кладёт changelog в артефакты), запускает юнит-тесты миграций на временной БД, подписывает образ.
airflow-dags: сборка образа воркеров/шедулера с DAG внутри; линтер DAG, smoke-тест DAG (dry-run).
superset-config: экспорт baseline-дашбордов/ролей/фич-флагов как код; сборка образа для инициализации (скрипт импорта).
В env-repo создать отдельный «релиз» миграций как Helm/Kustomize-ресурс с PreSync hook (Job), который:
1. берёт из ExternalSecret креды;
2. выполняет Liquibase/Flyway update;
3. пишет «версию схемы» в таблицу schema_version.
Для тяжёлых backfill’ов — отдельный Airflow DAG с чекпоинтами.
CI после успешных тестов создаёт PR в clusters/dev/... на обновление тегов образов postgres-migrations, airflow, superset.
После наблюдения (SLO-дашборд зелёный) — PR в clusters/stage/....
В Stage включить Argo Rollouts для Superset: ступить 10%→50%→100%, остановка по ошибкам 5xx/latency.
Поднять Vault/Secret Manager; накатить External Secrets Operator.
Для БД — по возможности динамические логины (Vault DB Engine) с TTL; иначе — статические, но с ротацией.
В CI — OIDC-федерация к регистру/артефакт-стораджу, без «вечных» токенов.
До продвижения на Prod проверяем:
CI для app-репозиториев:
Описание миграций в GitOps:
Промо Dev → Stage:
Секреты:
SLO-гейты:
1. доступность Superset (2xx/3xx) ≥ 99% за 1 час canary;
2. p95 latency UI < 3 c;
3. Airflow DAG «ежедневка» прошёл;
4. Postgres нет долгих транзакций/блокировок;
5. бэкап БД «свежий» (< 24 ч).
Гейты оформлены как проверки PR (CI дергает PromQL/Alertmanager API).
Release notes и аннотации:
В PR — список изменений MIG/ETL/BI, риски, план отката.
В Grafana — аннотации на время canary/rollout.
Для Superset — rollback в Argo Rollouts (возврат на предыдущий ReplicaSet).
Для DAG — вернуть тег образа в env-repo.
Для миграций — только если предусмотрены rollback-скрипты; иначе — PITR БД до точки перед релизом.
Откат:

Результат

В Dev/Stage/Prod стоят управляемые версии Postgres, Airflow, Superset.
Любое изменение идёт через PR в env-repo; Argo CD отображает статус и синхронизацию.
Миграции схем проходят как управляемые Jobs с бэкапом/контролем.
Superset выкатывается канареечно, метрики SLO — зелёные.

Чек-лист «ГОТОВНОСТЬ К PROD»

Разделены app-repos и env-repo; включён Argo CD с SSO и RBAC.
Helm/Kustomize стандартизированы (шаблоны оверлеев Dev/Stage/Prod).
Канареечные выкаты возможны (Argo Rollouts + Ingress трафик-сплит).
Миграции БД описаны и запускаются автоматически с PreSync/отдельным релизом; есть PITR-план.
Секреты — через ESO/Vault; для CI — OIDC-федерация/краткоживущие токены.
Политики безопасности (Gatekeeper/Kyverno) стоят «enforce»; подписи образов валидируются.
CI включает тесты DAG/миграций/линты, скан уязвимостей, SBOM.
SLO-дашборды и алерты настроены; PR-гейты читают метрики.
Описаны runbook’и: откат Superset, откат DAG, восстановление БД (PITR).
Включён аудит: кто промотировал релиз, какие изменения в env-repo.

Хороший GitOps в BI/DWH — это не только «Argo CD + Helm». Это организация жизни изменений: версионирование артефактов, безопасные миграции схем, канареечные выкаты фронтов BI, секреты как сервис, политики как код и SLO-гейты на каждом шаге. Когда все части соединены, релизы становятся частыми и безопасными, а откат — быстрым и предсказуемым.

← Предыдущая статья

Модуль 5. Наблюдаемость и эксплуатация

Следующая статья →

Модуль 7. Стек данных на k8s (open-source)