Что такое GitOps и как он связан с CI/CD?

Что такое GitOps

GitOps — это парадигма (модель) управления инфраструктурой и конфигурациями приложений, которая использует Git как центральный и единственный источник объявления желаемого состояния всей системы. Основной принцип: декларативное состояние (желаемая конфигурация) описывается в файлах (например, Kubernetes манифесты, конфигурации Terraform), которые хранятся в Git-репозитории. Любое изменение состояния системы происходит только через операцию commit/push в этот репозиторий. Затем специальный оператор (или инструмент) автоматически сравнивает желаемое состояние из Git с фактическим состоянием в реальной среде и предпринимает действия для их синхронизации (применяет изменения).

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

• Git как центральный источник истины (Single Source of Truth): Все конфигурации — код инфраструктуры (IaC), манифесты приложений, политики безопасности — версионируются в Git.
• Декларативное описание: Система описывается "как должно быть", а не "как это сделать". Например, в манифесте Kubernetes указывается, что нужно 3 реплики приложения, а не команды для их создания.
• Автоматическая синхронизация: Инструменты (например, Flux CD или Argo CD) непрерывно мониторируют репозиторий Git и кластер (или инфраструктуру), автоматически применяя изменения при их расхождении.
• Откат через Git: Если изменение вызывает проблему, восстановление рабочего состояния выполняется простым откатом (revert) коммита в Git до предыдущей рабочей версии.

Пример декларативного манифеста для Kubernetes (желаемое состояние, хранящееся в Git):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3 # Желаемое состояние: три реплики
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: myregistry/my-app:v1.2.0 # Желаемое состояние: конкретная версия образа

Связь GitOps с CI/CD

GitOps не заменяет CI/CD, а естественно расширяет и дополняет его, особенно этап Continuous Delivery (CD). Их связь можно представить как разделение ответственности и создание надежного, автоматизированного потока от разработки до production.

Как они взаимодействуют

1. CI (Continuous Integration) отвечает за строительство артефактов: компиляцию кода, запуск тестов, сборку Docker-образов. Результат CI — новый, протестированный артефакт (например, Docker образ с тегом my-app:v1.2.0), который помещается в реестр (Registry).

   # Пример этапа в CI pipeline (Jenkins, GitLab CI):
   docker build -t myregistry/my-app:v1.2.0 .
   docker push myregistry/my-app:v1.2.0
   

2. CD в классическом понимании часто включает сложные pipelines, которые напрямую выполняют deployment-действия (вызов kubectl apply, выполнение скриптов). Это может создавать "черные ящики" и множественные точки входа для изменений.
3. GitOps переосмысливает CD: теперь этап Delivery сводится к обновлению декларативного состояния в Git. После того как CI создал новый образ, единственное действие для его развертывания — это изменение файла конфигурации в Git-репозитории (например, обновление поля image в манифесте, как показано выше, на myregistry/my-app:v1.2.0).

Практический workflow GitOps + CI/CD

• Разработчик создает фичу, пушит код в Git.
• CI Pipeline запускается автоматически: строит образ, тестирует, пушит образ в registry.
• Разработчик или автоматический процесс (это может быть часть того же CI) обновляет конфигурацию в GitOps-репозитории — изменяет манифест, указывая новую версию образа. Это действие — commit и push.
• GitOps-оператор (например, Flux CD, установленный в кластер) непрерывно отслеживает этот GitOps-репозиторий. Он видит новый коммит, вычисляет разницу между желаемым (новая версия образа в манифесте) и фактическим (старый образ работает в кластере) состояниями и автоматически выполняет deployment — обновляет приложение в Kubernetes без участия человека или внешних скриптов.

Преимущества такого разделения

• Унификация процесса: Deployment для любого приложения или инфраструктуры всегда одинаков — изменение в Git.
• Повышенная безопасность и аудит: Все изменения запротоколированы в Git-истории. Кластер или инфраструктура не имеют прямого доступа из внешних CI систем; оператор работает "изнутри", снижая риск.
• Согласованность и восстановление: Состояние среды всегда можно воспроизвести из Git. Откат — это Git revert.
• Разделение ответственности: CI может принадлежать разработчикам, а управление состоянием production через GitOps — инженерам инфраструктуры, с четким контролем через pull/merge requests.

Таким образом, GitOps превращает CD в управление состоянием через контроль версий, делая процесс развертывания более безопасным, наблюдаемым и повторяемым, где Git выступает не только как инструмент для кода, но как управляющий интерфейс для всей производственной среды.