Argo CD в CI/CD: от merge до стабильного rollout

⚙️ Теория

🧭 Argo CD как GitOps контроллер

Argo CD сравнивает:

desired state в Git,
live state в Kubernetes,

и синхронизирует расхождения по заданной политике.

🔄 Sync и drift detection

Ключевые режимы:

manual sync;
auto sync;
self-heal/prune (по политике).

Drift detection показывает отклонение кластера от Git и возвращает управление в декларативную модель.

⚠️ Риски внедрения

auto-sync без guardrails может закрепить ошибочную конфигурацию;
отсутствие окружений/approval-потока усложняет контроль промоушена;
ручные изменения в кластере создают конфликт с GitOps моделью.

❓ Что нужно уметь объяснить

Почему GitOps снижает operational risk?

Потому что изменения становятся трассируемыми (commit/PR), воспроизводимыми и откатываемыми.

Когда auto-sync стоит включать аккуратно?

Для production с критичным SLA: сначала policy/тесты/валидации, потом постепенный переход к полной автоматике.

Почему rollback в GitOps это в первую очередь `git revert`?

Потому что источником истины остается Git, а контроллер приводит кластер к этому состоянию.

🧪 Практика

1. Базовый Application

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: demo-app
spec:
  source:
    repoURL: https://github.com/argoproj/argocd-example-apps.git
    path: guestbook
    targetRevision: HEAD
  destination:
    server: https://kubernetes.default.svc
    namespace: demo
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

2. Проверка статуса и синка

argocd app get demo-app
argocd app sync demo-app
argocd app history demo-app

3. Guardrails

policy checks до merge (lint/scan/tests);
разделение окружений и promotion strategy;
rollback runbook через revert + sync.

🧾 Вывод

Argo CD стабилизирует delivery, когда Git действительно единственный источник истины, а pipeline окружен валидациями и понятной стратегией промоушена.

📚 Ссылки

✅ Проверка источников

Argo CD Docs