Впровадження GitOps-підходу для управління інфраструктурою

Ми впроваджуємо GitOps як операційну модель, де git-репозиторій стає єдиним джерелом правди для стану інфраструктури та застосунків. Будь-яка зміна в кластері — через Pull Request. Жодних kubectl apply руками. Жодних terraform apply з локальної машини розробника. Це звучить просто, але перехід від «ми деплоїмо через CI» до справжнього GitOps-підходу зачіпає процеси, архітектуру репозиторіїв, управління секретами та культуру команди.

Чому GitOps вимагає планомірного підходу?

Найчастіша помилка — встановити ArgoCD або Flux, налаштувати синхронізацію одного застосунку та оголосити «у нас GitOps». Через місяць з'ясовується: частина ресурсів досі створюється вручну через kubectl create namespace, секрети зберігаються в CI-змінних і застосовуються в pipeline, Helm values для production редагуються безпосередньо в кластері без commit у git. Drift між тим, що в репозиторії, і тим, що реально крутиться — накопичується непомітно.

Друга проблема: монолітний репозиторій без чіткої структури. Коли apps/ перемішаний з infrastructure/, а overlays/ для різних оточень не консистентні — onboarding нового інженера перетворюється на детектив. Kustomize overlays та Helm values потрібно організовувати за оточеннями (base/, overlays/dev/, overlays/prod/) з самого початку, а не рефакторити потім.

Управління секретами в GitOps — окремий головний біль. У git не можна зберігати plaintext secrets. Три робочі варіанти: Sealed Secrets (шифрування через kubeseal, секрет розшифровується тільки контролером у кластері), SOPS з age/GPG (зашифровані файли в git, розшифровка в runtime), External Secrets Operator (секрети живуть у Vault/AWS SSM/GCP Secret Manager, ESO синхронізує їх як Kubernetes Secrets). Вибір залежить від того, чи є вже Vault в інфраструктурі та чи потрібен єдиний secrets store для кількох кластерів.

Як вибрати GitOps-оператор: ArgoCD vs Flux?

Для більшості команд ArgoCD зручний при необхідності візуалізації та багатокластерного керування. Flux вибирають проекти, де все має працювати через pipeline без ручного втручання.

Архітектура GitOps-впровадження

Повноцінне впровадження включає кілька шарів:

Репозиторна стратегія. Два основні патерни: monorepo (все в одному репозиторії — інфраструктура + застосунки) та polyrepo (окремий app repo + окремий gitops/config repo). Для більшості команд оптимальний варіант App repo окремо, GitOps config repo окремо — це розділяє життєві цикли коду та конфігурації, прибирає конфлікти при одночасній роботі кількох команд.

Структура config репозиторію під Kustomize:

gitops-config/
├── apps/
│   ├── base/
│   │   └── myapp/
│   │       ├── deployment.yaml
│   │       ├── service.yaml
│   │       └── kustomization.yaml
│   └── overlays/
│       ├── dev/
│       │   └── kustomization.yaml # patch ресурсів + replica=1
│       └── prod/
│           └── kustomization.yaml # patch ресурсів + HPA + PDB
├── infrastructure/
│   ├── cert-manager/
│   ├── ingress-nginx/
│   └── monitoring/
└── clusters/
    ├── dev/
    └── prod/

Вибір GitOps-оператора. ArgoCD — більш багатий UI, зручний для мультикластера, ApplicationSet для генерації застосунків з шаблонів. Flux v2 — більш cloud-native, краще інтегрується з Helm OCI-репозиторіями, підходить для автоматизованих workflows без UI. На практиці ArgoCD частіше вибирають команди, яким важлива візуалізація, Flux — там, де все через GitOps pipeline без ручного втручання.

CI/CD інтеграція. В GitOps CI залишається за збіркою та тестуванням. CD повністю йде в GitOps-оператор. CI pipeline будується за схемою: build → test → push image → update image tag in config repo → ArgoCD/Flux підхоплює зміну та синхронізує кластер. Оновлення тегу в config repo можна робити через kustomize edit set image або через Argo CD Image Updater / Flux Image Automation.

Приклад GitHub Actions step для оновлення image tag у config repo:

---
- name: Update image tag in gitops repo
  run: |
    git clone https://github.com/org/gitops-config.git
    cd gitops-config
    kustomize edit set image myapp=registry.example.com/myapp:${{ github.sha }}
    git add .
    git commit -m "ci: update myapp to ${{ github.sha }}"
    git push
  working-directory: apps/overlays/dev

Drift Detection і Self-healing

Одна з головних переваг GitOps — автоматичне відновлення після ручних змін у кластері. Якщо хтось змінив replicas напряму через kubectl scale, ArgoCD виявить розбіжність і через налаштований sync interval (за замовчуванням 3 хвилини) поверне стан до того, що в git. Це називається self-healing, і воно має бути увімкнено свідомо — не для всіх ресурсів одразу.

Ресурси, які часто потрібно виключити з auto-sync: HPA (horizontal pod autoscaler змінює replicas автоматично, конфлікт з GitOps-синхронізацією), PersistentVolumeClaims (зміна може призвести до втрати даних), деякі CRD з dynamic reconciliation. В ArgoCD це налаштовується через ignoreDifferences:

spec: ignoreDifferences: - group: apps kind: Deployment jsonPointers: - /spec/replicas 

Етапи впровадження

Впровадження GitOps — це ітеративний процес, не одноразове завдання.

Повний цикл від аудиту до production-ready GitOps — від 3 тижнів для невеликого стеку до 3 місяців при складній мультикластерній інфраструктурі з compliance-вимогами.

Що входить в роботу

• Аудит поточної інфраструктури та deploy-процесів
• Проектування репозиторної структури (monorepo або polyrepo)
• Налаштування GitOps-оператора (ArgoCD або Flux) з RBAC та multi-tenancy
• Поетапна міграція застосунків зі збереженням працездатності
• Впровадження управління секретами (Sealed Secrets/SOPS/External Secrets Operator)
• Розробка документації та runbook
• Навчання команди та підтримка на етапі запуску

Зв'яжіться з нами для аудиту вашої інфраструктури — ми оцінимо обсяг робіт і терміни впровадження. Досвід нашої команди — понад 5 років успішних проектів з GitOps-трансформації в компаніях різного масштабу. Гарантуємо результат: скорочення часу деплою на 30-50% та виключення ручних операцій.

Отримайте консультацію з вибору GitOps-оператора та архітектури репозиторіїв.