Добавить в корзинуПозвонить
Найти в Дзене

GitOps: управление инфраструктурой через Git

#devops #it_design_architect (канал https://t.me/cybermerlin_pub - больше статей \ полезного) GitOps — это подход, при котором всё состояние системы (код приложений, конфигурации, манифесты Kubernetes) хранится в Git-репозитории как единый источник истины. Изменения вносятся через Pull Request, а автоматический оператор (например, ArgoCD или Flux) синхронизирует кластер с желаемым состоянием, описанным в Git. - Декларативность - Всё состояние системы описывается декларативно (YAML, Helm, Kustomize), а не через императивные команды - Версионирование - Git хранит всю историю изменений, позволяя откатиться к любой точке - Автоматическая синхронизация - Оператор постоянно следит за репозиторием и применяет изменения в кластере - Безопасность - Доступ к кластеру только через Git-репозиторий; никто не имеет права менять состояние вручную 1. Разработчик меняет манифесты в Git и создаёт Pull Request. 2. После ревью и слияния изменений в основную ветку, оператор (ArgoCD или Flux) замечает расхо
Оглавление

#devops #it_design_architect

(канал https://t.me/cybermerlin_pub - больше статей \ полезного)

GitOps: управление инфраструктурой через Git

GitOps — это подход, при котором всё состояние системы (код приложений, конфигурации, манифесты Kubernetes) хранится в Git-репозитории как единый источник истины. Изменения вносятся через Pull Request, а автоматический оператор (например, ArgoCD или Flux) синхронизирует кластер с желаемым состоянием, описанным в Git.

Принципы GitOps

- Декларативность - Всё состояние системы описывается декларативно (YAML, Helm, Kustomize), а не через императивные команды

- Версионирование - Git хранит всю историю изменений, позволяя откатиться к любой точке

- Автоматическая синхронизация - Оператор постоянно следит за репозиторием и применяет изменения в кластере

- Безопасность - Доступ к кластеру только через Git-репозиторий; никто не имеет права менять состояние вручную

1. Разработчик меняет манифесты в Git и создаёт Pull Request.

2. После ревью и слияния изменений в основную ветку, оператор (ArgoCD или Flux) замечает расхождение.

3. Оператор автоматически применяет изменения в кластере Kubernetes.

4. Если что-то пошло не так — просто откатываем коммит в Git, и кластер вернётся в прежнее состояние.

Инструменты для GitOps

- ArgoCD - Декларативный, с удобным UI, поддерживает Helm, Kustomize, Jsonnet (Стандарт для большинства команд, мощный веб-интерфейс)

- Flux (v2) - Легковесный, отлично интегрируется с Git, поддерживает Helm, Kustomize (Если нужна минималистичная интеграция, особенно с GitLab)

- Jenkins X - GitOps + CI/CD в одном флаконе (Если вы уже используете Jenkins и хотите всё в одном месте)

Преимущества

- Прозрачность: все изменения видны в Git → упрощается аудит.

- Отказоустойчивость: кластер автоматически восстанавливает состояние, если кто-то внёс правки вручную.

- Упрощение откатов: откат — это просто revert коммита в Git.

- Снижение человеческого фактора: не надо помнить, что где лежит и как править.

Пример: развертывание с ArgoCD

Установка ArgoCD в кластер:

kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

Создание Application (привязать к репозиторию):

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: myapp
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/myorg/myapp-config
targetRevision: main
path: ./overlays/production
helm:
valueFiles:
- values.yaml
destination:
server: https://kubernetes.default.svc
namespace: production
syncPolicy:
automated:
prune: true
selfHeal: true

ArgoCD будет автоматически синхронизировать кластер с этим состоянием, удалять лишние ресурсы и исправлять ручные правки.

Типичные ошибки

- Хранить секреты в открытом виде в Git. Всегда шифруйте их (Sealed Secrets, SOPS, Vault).

- Не разделять окружения (dev/staging/prod) в разных ветках или папках.

- Не использовать политики автоматической синхронизации без тестирования (можно применить syncPolicy: automated только после проверки).