Модуль 10.8: Корпоративний GitOps та платформна інженерія

Складність: [COMPLEX] | Час на виконання: 2.5 год | Передумови: Основи GitOps (ArgoCD/Flux), Kubernetes RBAC, Управління мультихмарним флотом (Модуль 10.5)

Чому цей модуль важливий

У 2024 році великий європейський банк мав 160 команд розробки, які деплоїли код у 42 кластери Kubernetes. Вони впровадили ArgoCD двома роками раніше, і спочатку це був успіх. Але зі зростанням кількості команд почався хаос. Кожна команда ставила свій власний ArgoCD. Дехто мав по три штуки: для dev, staging та prod. Разом банк запускав 87 окремих інстансів ArgoCD, кожен налаштований по-своєму. Коли вийшла новина про критичну вразливість в ArgoCD, оновлення всіх систем зайняло 11 тижнів. Їхній GitOps перетворився на “87 маленьких ізольованих островів”.

Тим часом досвід розробників погіршувався. Нова команда мала чекати 3 дні на створення неймспейсу, потім вручну редагувати YAML-файли в спільних репозиторіях і самостійно розбиратися з секретами через Slack. Шлях від створення команди до першого деплою в продакшн займав 6 тижнів. Їхні конкуренти, що використовували сучасні внутрішні платформи (IDP), робили це за дні.

Корпоративний GitOps — це не просто встановлення софту. Це побудова платформи самообслуговування, де команди деплоять і моніторять свої додатки через Git, не замислюючись про те, як працює інфраструктура під ними.

У цьому модулі ви навчитеся будувати таку платформу на базі Backstage, масштабувати ArgoCD за допомогою патернів ApplicationSets та App of Apps, розробляти стратегії репозиторіїв для великих компаній та налаштовувати суворий RBAC для безпеки GitOps.

Внутрішня платформа розробки (IDP)

IDP — це шар самообслуговування між розробником та хмарою. Він перетворює складні налаштування на прості шаблони.

Що дає Backstage:

Software Catalog: “телефонна книга” всіх сервісів компанії. Ви бачите, хто власник додатка і де його логи.
Software Templates: кнопка “Створити новий мікросервіс”. За лаштунками Backstage сам створює репозиторій, кластер та налаштовує деплой.
TechDocs: документація, яка живе поруч із кодом у Git.

Масштабування ArgoCD

Патерн App of Apps

Замість того, щоб створювати кожен додаток вручну, ви створюєте одну “Кореневу програму”. Вона дивиться в папку в Git, де лежать маніфести інших програм. Додали новий YAML у папку — ArgoCD сам створив новий додаток.

ApplicationSets: Генерація на льоту

Це найпотужніший інструмент для великого флоту.

Git Generator: створює додаток для кожної папки в репозиторії.
Cluster Generator: автоматично деплоїть моніторинг у кожен новий кластер, що з’явився у списку компанії.
Matrix Generator: деплоїть список сервісів на список кластерів у всіх комбінаціях.

Стратегія Git-репозиторіїв

Mono-Repo: все в одному (платформа + всі команди). Зручно шукати, але репозиторій стає дуже важким і повільним.
Repo Per Team: у кожної команди свій склад. Максимальна автономія, але важко впроваджувати спільні стандарти.
Hybrid (Рекомендовано): центральний репозиторій для стандартів платформи (monitoring, policy) + окремі репозиторії для коду та маніфестів команд.

RBAC та безпека

В ArgoCD ви використовуєте Проєкти (AppProjects) для ізоляції команд.

Команда “Платежі” бачить тільки свої додатки.
Вона може деплоїти тільки у свій неймспейс payments.
Вона може брати код тільки зі своїх репозиторіїв.
Синхронізаційні вікна: ви можете заборонити деплой у продакшн у неробочий час або під час свят.

Типові помилки

Помилка	Чому це стається	Як виправити
Окремий ArgoCD кожній команді	Бажання автономії	Використовуйте один центральний HA інстанс із розподілом прав через Projects
Паролі відкритим текстом у Git	”Це ж приватний репо”	Використовуйте External Secrets Operator або SOPS для шифрування
Деплой без лімітів	”Ми не знаємо, скільки треба”	Використовуйте Kyverno політики, щоб ArgoCD не міг задеплоїти под без `resources`
Ручне створення в UI	Швидше, ніж міняти Git	Забороніть зміни через UI для продакшну. Тільки Git — єдине джерело істини

Тест

1. Чому патерн App of Apps вважається кращим за ручне створення додатків в інтерфейсі ArgoCD?

Тому що він дозволяє керувати самою системою розгортання через Git. Якщо ви випадково видалите ArgoCD або переїдете в інший регіон, вам достатньо буде застосувати один “Кореневий” маніфест, і він сам відновить сотні додатків згідно з конфігурацією в Git.

2. Як запобігти тому, щоб помилка в Git однієї команди "поклала" весь центральний ArgoCD?

Використовуйте sharding (розподіл) навантаження між кількома копіями контролера ArgoCD та встановлюйте ліміти на кількість об’єктів, які один додаток може створити в кластері.

Практична вправа: Дизайн платформи

Створіть шаблон Backstage для розгортання простого сайту (репозиторій + ArgoCD App).
Налаштуйте AppProject, який забороняє команді створювати ресурси типу ClusterRole (безпека кластера).
Напишіть ApplicationSet, який автоматично встановить fluent-bit у всі кластери з міткою logging: enabled.
Впровадьте External Secrets, щоб под отримував пароль до бази з хмари, а в Git лежав лише безпечний маніфест.

Наступний модуль

Ви побудували платформу деплою, тепер час зробити її безпечною за сучасними стандартами. Переходьте до Модуля 10.9: Архітектура Zero Trust у гібридній хмарі — ми навчимося відмовлятися від VPN, використовувати IAP та будувати мікросегментацію мережі.