#gitops#argocd#kubernetes

GitOps с ArgoCD: от деплоев по SSH до git push

01.10.2026

Единственное место, где происходит деплой, — это git. Почему это работает и с чего начать.

Годы назад деплой выглядел так: SSH на сервер, git pull, перезапуск. Потом появился конвейер, но релизы все равно кто-то нажимал руками. GitOps — следующий шаг: единственное место, где происходит деплой, — это git.

Что такое GitOps

Принцип простой: желаемое состояние кластера описано в git, а агент (ArgoCD) постоянно сравнивает его с фактическим и приводит в соответствие. Всплыл drift — «кто-то поменял HPA руками» — система его откатывает до версии из репозитория.

# Application в ArgoCD — это тоже просто манифест
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: web-frontend
spec:
  project: default
  source:
    repoURL: https://git.example.com/infra/k8s
    path: apps/web-frontend
    targetRevision: main
  destination:
    server: https://kubernetes.default.svc
    namespace: web
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Почему это работает

  • Аудит — история деплоев = git log, с авторами и ревью
  • Откат — git revert + push, никакого «руками поправим»
  • Drift-детекция — изменения, внесены не через git, видны и откатываются
  • PR-процесс — деплой проходит тот же ревью, что и код

С чего начать

  1. Поднять ArgoCD: kubectl create namespace argocd && kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
  2. Один репозиторий инфраструктуры, разделенный по приложениям
  3. Сначала sync вручную (UI), потом включать automated по одному приложению
  4. Запретить прямой kubectl apply через RBAC — иначе GitOps беззубый

Самое сложное не в ArgoCD, а в дисциплине: все изменения — только через git. Инструмент это обеспечивает, но только пока команда с ним соглашается.