gitops

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

Четыре принципа GitOps

Вейл Тёрнер и компания Weaveworks, популяризировавшая термин, сформулировали четыре ключевых принципа.

1. Декларативность: вся система описана декларативно. Не «запусти этот скрипт», а «вот желаемое состояние».
2. Версионируемость: желаемое состояние хранится в Git с полной историей, возможностью аудита и отката.
3. Автоматическое применение: одобренные изменения применяются автоматически без ручного вмешательства.
4. Непрерывное согласование: агент постоянно сравнивает желаемое и реальное состояние и устраняет расхождения.

Как работает GitOps на практике

Разработчик вносит изменение: обновляет тег Docker-образа в Kubernetes-манифесте и открывает pull request. После ревью и мержа GitOps-агент (ArgoCD или Flux) обнаруживает изменение в репозитории, сравнивает его с текущим состоянием кластера и применяет разницу. Разработчик видит статус деплоя в интерфейсе агента или в PR.

Никто не делает kubectl apply вручную. Никто не «деплоит с ноутбука». Единственный способ изменить систему — коммит в Git.

Push vs Pull модель деплоя

Традиционный CI/CD работает по push-модели: CI-пайплайн сам подключается к кластеру и применяет изменения. Это требует хранения учётных данных кластера в CI-системе.

GitOps использует pull-модель: агент работает внутри кластера, сам отслеживает изменения в Git и применяет их. Кластер тянет изменения сам — credentials не нужно хранить снаружи. Это принципиально улучшает безопасность.

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

ArgoCD — наиболее популярный GitOps-контроллер для Kubernetes. Имеет богатый веб-интерфейс с визуализацией состояния приложений, поддерживает Helm, Kustomize, jsonnet и plain YAML. Показывает diff между желаемым и текущим состоянием.

Flux CD (v2) — более легковесная альтернатива. Полностью Kubernetes-native, строится на Custom Resources. Хорошо интегрируется с Helm через HelmRelease.

Jenkins X — GitOps-платформа поверх Jenkins и Tekton, ориентированная на CI+CD для Kubernetes.

GitOps и безопасность

Pull-модель устраняет необходимость хранить kubeconfig в CI-системе. Весь аудит — в Git-истории: видно, кто что и когда изменил. Rollback — это git revert с PR и ревью. Несанкционированные изменения в кластере (через kubectl напрямую) будут перезаписаны агентом при следующей синхронизации — система самокорректируется.

Структура репозитория при GitOps

Популярный паттерн — разделение на два репозитория: app repo (код приложения, Dockerfile) и config repo (Kubernetes-манифесты, Helm values). CI-пайплайн собирает образ, обновляет тег в config repo. GitOps-агент отслеживает config repo.

Альтернатива — монорепо, где и код, и конфигурация хранятся вместе, разделённые директориями.

Ограничения GitOps

GitOps отлично подходит для управления конфигурацией и деплоем, но не покрывает всё. Секреты не должны храниться в Git в открытом виде — используют Sealed Secrets, External Secrets Operator, Vault. Одноразовые задачи (миграции БД) не вписываются в GitOps-паттерн напрямую. GitOps ориентирован на Kubernetes и менее применим к традиционным серверам без оркестрации.