EMZETT.GitOps: керування інфраструктурою з Git
Коротко: Бажаний стан застосунків та інфраструктури зберігається в репозиторії Git, а інструмент автоматично узгоджує з ним працюючі системи.
Докладніше: У GitOps Git — єдине джерело істини. Зміни вносяться не ручними командами на сервері, а як коміт чи pull request. Агент у кластері (наприклад, Argo CD або Flux) постійно порівнює бажаний стан у репозиторії з фактичним і виправляє відхилення.
Подробиці
Принципи
- Декларативність: файли описують, що має працювати (YAML для Kubernetes), а не кроки для цього.
- Версіонування: кожна зміна має автора, час і причину, і її можна скасувати (
git revert). - Автоматичне застосування: агент приймає схвалені зміни.
- Самовідновлення: якщо щось змінено вручну, агент скидає це (виявлення дрейфу).
Pull замість push
Класичні конвеєри надсилають (push) зміни до кластера зі своїми обліковими даними. У GitOps агент у кластері забирає (pull) зміни з репозиторію. Кластеру не потрібно видавати облікові дані конвеєру, що підвищує безпеку, а стан простежується в будь-який момент.
Типовий потік
- Розробники змінюють файл маніфесту (наприклад, новий тег образу) у гілці.
- Pull request із рев’ю та автоматичними перевірками.
- Після злиття агент виявляє зміну.
- Агент застосовує її й повідомляє статус.
Відкат означає: скасувати коміт.
Підводні камені
Секрети (паролі) не повинні потрапляти в репозиторій відкритим текстом; для цього існують інструменти на кшталт Sealed Secrets чи SOPS. Розділяйте код застосунку й конфігурацію середовища, інакше кожна зміна коду запускає збірку конфігурації. GitOps найефективніший разом з інфраструктурою як кодом.
Див. також: Інфраструктура як код, Основи Kubernetes, Git, Конвеєр CI/CD