Что такое GitOps и как внедрить его с Argo CD
Продвинутое3 минРедакция Innovialabs
Коротко
GitOps — подход, при котором желаемое состояние инфраструктуры описано в Git, а агент в кластере (например, Argo CD) сам подтягивает изменения и приводит кластер к этому состоянию.
Что такое GitOps в двух словах
GitOps — это способ управлять приложениями и инфраструктурой, где Git является единственным источником истины. Все манифесты Kubernetes, Helm-чарты или Kustomize-оверлеи лежат в репозитории. Изменение среды — это коммит или pull request, а не ручная команда kubectl apply.
Ключевое отличие от классического CI/CD — pull-модель:
- Push-модель: CI-пайплайн получает доступ к кластеру и сам выкатывает изменения.
- Pull-модель: агент внутри кластера следит за Git и сам применяет изменения. CI только собирает образ и обновляет манифест.
Плюсы pull-модели: учетные данные кластера не покидают его, любое ручное изменение видно как drift (расхождение), а откат — это git revert.
Как работает Argo CD
Argo CD — контроллер для Kubernetes, который постоянно сравнивает состояние кластера с тем, что описано в Git.
- Application — ресурс, связывающий путь в репозитории с namespace в кластере.
- Sync — приведение кластера к состоянию из Git, вручную или автоматически.
- Self-heal — автоматический откат ручных правок в кластере.
- Prune — удаление ресурсов, которых больше нет в Git.
Быстрая установка
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
Затем опишите приложение декларативно — тоже в Git:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: shop-api-staging
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/acme/deploy.git
targetRevision: main
path: apps/shop-api/overlays/staging
destination:
server: https://kubernetes.default.svc
namespace: shop-staging
syncPolicy:
automated:
prune: true
selfHeal: true
Подробности — в официальной документации Argo CD.
Как структурировать репозитории
Держите код приложения и манифесты деплоя раздельно. Иначе каждый коммит в код запускает лишние синхронизации, а права доступа смешиваются.
Типичная структура репозитория деплоя с Kustomize:
apps/
shop-api/
base/
overlays/
dev/
staging/
production/
| Подход | Когда подходит |
|---|---|
| Папки на окружение в одной ветке | Большинство команд: всё видно сразу, диффы между средами понятны |
| Ветка на окружение | Редко оправдано: сложно сливать, легко получить расхождения |
| Отдельный репозиторий для production | Когда нужен строгий контроль доступа к проду |
Для большого числа приложений используйте паттерн App of Apps или ApplicationSet, чтобы не создавать Application вручную.
Продвижение между окружениями
Продвижение (promotion) — это перенос проверенной версии из одного окружения в следующее. В GitOps это всегда изменение в Git:
- CI собирает образ с неизменяемым тегом (например, SHA коммита).
- CI или инструмент вроде Argo CD Image Updater обновляет тег в оверлее
dev. - После проверки тот же тег переносится в
stagingчерез pull request. - Для
production— отдельный PR с обязательным ревью и, при необходимости, ручной синхронизацией.
Главное правило: в production попадает ровно тот артефакт, который прошел staging, а не пересобранный заново.
Частые ошибки
- Секреты в открытом виде в Git. Используйте Sealed Secrets, SOPS или External Secrets Operator.
- Тег
latest. Argo CD не увидит изменений, а откат станет невозможен. - Ручные правки в кластере при включенном self-heal — они будут молча откатываться.
- Один гигантский Application на всё: долгие синхронизации и сложная диагностика.