GitOps (Хранение состояния в Git)

GitOps — это подход к управлению инфраструктурой и приложениями, при котором все изменения проходят через Git. Репозиторий становится единственным и достоверным источником конфигурации: всё, что должно быть в кластере — описано в коде и хранится в Git.

Вместо ручных операций или запуска команд из CI-системы, GitOps предполагает, что изменения сначала фиксируются в Git (обычно через pull request), а затем автоматически применяются в Kubernetes-кластере с помощью специального контроллера.

Ключевые принципы GitOps:

• Git как источник правды — любая инфраструктурная или приложенческая конфигурация живёт в Git.
• Pull request — как точка входа для изменений. Через него проходит ревью, тестирование, и только потом — доставка.
• Автоматическая синхронизация — система GitOps сравнивает текущее состояние кластера с тем, что в репозитории, и при необходимости применяет обновления.
• Обратимость — любое изменение можно откатить простым
  Копироватьgit revert
  , и система сама вернёт кластер в нужное состояние.

Инструменты GitOps:

• Argo CD — настраиваемый GitOps-контроллер для Kubernetes, умеет синхронизировать манифесты и следить за дрифтом состояния.
• Flux — лёгкий и гибкий GitOps-движок, интегрируемый с GitHub, GitLab и другими.
• GitHub Actions / GitLab CI — часто используются в связке с Argo CD или Flux для запуска пайплайнов и валидации изменений.

GitOps сильно упрощает:

• отслеживание истории и аудит (всё зафиксировано в коммитах),
• автоматизацию релизов без ручных операций,
• управление средами (dev, staging, prod — всё из одного репозитория),
• катастрофоустойчивость (кластер можно «восстановить из Git»).

GitOps vs DevOps: GitOps — это узкоспециализированный подход внутри DevOps-культуры. Если DevOps охватывает процессы, автоматизацию, взаимодействие команд, то GitOps — это конкретная реализация доставки и управления через Git.

Сегодня GitOps активно используется в компаниях, где важны стабильность, прозрачность и повторяемость процессов — особенно в связке с Kubernetes и микросервисной архитектурой.

---

GitOps Flow: от коммита до обновления кластера (на примере Argo CD)

1. Разработчик делает изменение в манифесте
   • В Git-репозитории есть структура с YAML-файлами (Deployment, Service, Ingress и др.).
   • Изменения оформляются как Pull Request (PR) в нужную ветку (например,
     Копироватьmain
     или
     Копироватьstaging
     ).
2. PR проходит ревью и попадает в
   Копироватьmain
   • После мержа Argo CD начинает отслеживать изменения. Он знает, к какому кластеру и в каком namespace относится этот каталог манифестов.
3. Argo CD сравнивает текущее состояние кластера с Git
   • Контроллер запрашивает актуальные ресурсы в Kubernetes и сверяет их с тем, что написано в Git.
   • Если найдено расхождение — состояние считается OutOfSync.
4. Синхронизация
   • Argo CD автоматически (или вручную, по триггеру) применяет нужные манифесты, чтобы привести кластер в соответствие с Git.
   • Это делается с помощью стандартных
     Копироватьkubectl apply
     -операций под капотом.
5. Кластер обновлён
   • Новый образ, обновлённая конфигурация или изменённая структура вступает в силу.
   • В интерфейсе Argo CD можно отслеживать историю, статусы и логи.

---

Пример Argo CD Application манифеста (CRD)

КопироватьapiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  source:
    repoURL: https://github.com/my-org/k8s-manifests
    targetRevision: main
    path: apps/my-app
  project: default
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

---

Что делает этот манифест:

• Подключает каталог
  Копироватьapps/my-app
  из репозитория;
• Следит за веткой
  Копироватьmain
  ;
• Разворачивает всё в namespace
  Копироватьproduction
  ;
• Включает автоматическую синхронизацию с
  КопироватьselfHeal
  (автовосстановление) и
  Копироватьprune
  (удаление лишнего).

---