Index
GitOps за пределами Kubernetes
1. Классический подход (с Kubernetes)
Git Repo → ArgoCD/Flux → Kubernetes API
Стандартный сценарий с операторами, отслеживающими изменения в git-репозитории.
2. GitOps для виртуальных машин и bare-metal
Инструменты
- Ansible + AWX/Galaxy
- Terraform + Atlantis
- Puppet с git-бэкендом
Особенности
- Нет встроенного оператора
- Требуются кастомные CI/CD-пайплайны
# Пример Terraform + Atlantis
# atlantis.yaml
version: 3
projects:
- dir: "terraform/prod"
workflow: terraform-prod
terraform_version: "1.3.7"
3. GitOps для облачных сервисов
Провайдер |
Реализация |
Особенности |
AWS |
AWS Proton + CodePipeline |
Управление через CloudFormation |
Azure |
Azure Resource Manager + DevOps |
Bicep-шаблоны в git |
GCP |
Config Connector + Cloud Build |
Kubernetes-like API для GCP |
Важно: Облачные реализации часто требуют кастомных адаптеров вместо стандартных операторов.
4. GitOps для сетевого оборудования
Git → CI → Nornir/Ansible → Cisco/Juniper Devices
Кейсы использования:
- Управление конфигурацией маршрутизаторов
- Централизованное обновление ACL
- Версионирование сетевых политик
5. Универсальные GitOps-решения
Кросс-платформенные инструменты:
Инструмент |
Поддерживаемые цели |
Принцип работы |
Flux (v2) |
K8s, Helm, TF, AWS |
Custom Resource Definitions |
Crossplane |
30+ облачных провайдеров |
Kubernetes-API для всего |
# Пример Crossplane для AWS S3
apiVersion: s3.aws.crossplane.io/v1beta1
kind: Bucket
metadata:
name: my-gitops-bucket
spec:
forProvider:
locationConstraint: eu-west-1
6. Критерии выбора подхода
Когда использовать Kubernetes-ориентированный GitOps
- Уже есть K8s-инфраструктура
- Нужен declarative-подход
- Требуется self-healing
Когда выбрать альтернативы
- Legacy-системы без K8s
- Специфичное сетевое оборудование
- Жесткие compliance-требования