У подкасті The Pragmatic Engineer провідний інженер Octopus Deploy Роберт Ерез — фахівець із більш ніж десятирічним досвідом у CI/CD та системах розгортання — розкладає GitOps до базових принципів і акуратно знімає з нього ореол релігії. Його підхід простий: подивитися, що саме стоїть за терміном, які проблеми він реально розв’язує, а де перетворюється на зайву догму для команд, яким просто потрібно надійно й передбачувано постачати софт.
Як з’явився GitOps — і чому Kubernetes тут ключовий
GitOps народився не в теорії, а з дуже практичного спостереження: якщо Kubernetes уже вміє підтримувати заявлений стан кластера, чому б не потягнути цю ідею ще далі — до рівня репозиторію?
Ерез нагадує, що сам термін GitOps запровадила компанія Weaveworks приблизно у 2017 році. І майже одразу він пішов «у парі» з Kubernetes, тому що Kubernetes за своєю природою декларативний. У кластера є контролери, які стежать за тим, щоб бажаний стан системи — описаний у маніфестах — завжди збігався з фактичним. Якщо под помирає, контролер піднімає новий, якщо задано три репліки — система підтримує рівно три.
Далі з’явилася логічна ідея: якщо Kubernetes уже вміє безперервно примиряти бажаний і фактичний стани, чому б не зберігати цей бажаний стан у зовнішньому, версіонованому джерелі — умовно в Git — і не змусити спеціального агента постійно підтягувати його звідти в кластер?
Так сформувалась практика, якій згодом дали назву GitOps, а трохи пізніше — формалізували у вигляді чотирьох «стовпів».
Чотири стовпи GitOps — і жодного обов’язкового Git
Коли практику GitOps описали більш системно, у ній виокремили чотири ключові принципи. Цікава деталь, на якій акцентує Ерез: у жодному з них прямо не вимагається використання Git.
Перший стовп — декларативний стан.
Система має бути описана декларативно: ми не розповідаємо покроково, як перейти з точки А в точку Б, а лише фіксуємо, яким повинен бути цільовий стан. Для інфраструктури це означає: скільки реплік має бути, які сервіси, які конфігурації. У Kubernetes це вже звична модель: YAML‑маніфести описують бажаний стан, а контролери забезпечують його досягнення.
Другий стовп — бажаний стан має зберігатися у версіонованому та незмінному джерелі.
Це наступний крок: декларативний опис інфраструктури має лежати десь, де можна однозначно послатися на конкретну версію — наприклад, через тег чи commit SHA. І важливо, щоби ця версія була незмінною: не можна «підмальовувати» те, що вже нібито зафіксовано, інакше втрачається сенс історії змін та аудиту.
Git природно асоціюється з цим принципом, але Ерез звертає увагу: сам по собі Git не гарантує абсолютної незмінності. Теги можна перезаписати, історію — переписати, якщо немає політик, які це забороняють. Тому інструмент — лише реалізація, не частина аксіоми.
Третій стовп — pull, а не push.
GitOps спирається на модель, де агент всередині цільової системи (наприклад, кластера Kubernetes) сам тягне бажаний стан із джерела правди й застосовує його. Це протилежність push‑сценаріям, коли зовнішній інструмент «натискає» зміни в інфраструктуру. Модель pull зменшує кількість точок довіри та робить інфраструктуру більш самоорганізованою: кластер сам піклується про свою відповідність декларації.
Четвертий стовп — безперервна реконсиляція.
Це природне продовження: агент не просто один раз застосовує конфігурацію, а постійно стежить за дрейфом. Якщо хтось руками видалив deployment через kubectl, GitOps‑агент знову зчитає бажаний стан і відновить ресурс. Так з’являється замкнений контур: декларація → агент → Kubernetes → перевірка → повторне застосування при розбіжності.
Жоден із цих чотирьох принципів не вимагає саме Git. Потрібні декларативні описи, версіоноване й незмінне джерело, pull‑модель та безперервна реконсиляція. І назва «GitOps», на думку Ереза, тут зіграла двояку роль.
Пастка «все має бути в Git»: коли назва створює хибні очікування
Через сам термін «GitOps» у багатьох команд виникає автоматична й, по суті, помилкова інтуїція: якщо «Git», значить, усе — в репозиторій. Конфіг, середовище, параметри, артефакти, секректи — усе, що тільки можна, варто «загнати» в Git.
Ерез описує знайому для спільноти дискусію: куди класти секрети? Інтуїтивна відповідь у GitOps‑середовищі — «теж у git, але ж якось захищено». Відповідь практиків інфраструктури — «секрети у відкритому вигляді в git зберігати не можна взагалі».
На стику цих двох позицій народилися компромісні інструменти: наприклад, механізми «sealed secrets», у яких секрети шифруються й у вигляді зашифрованих blobs усе ж кладуться в репозиторій. Але сама поява таких рішень, на думку Ереза, радше висвітлює фундаментальну проблему: частина речей просто не повинна жити в Git, навіть якщо команда намагається будувати процес за принципами GitOps.
Якщо основні стовпи говорять лише про версіонованість та незмінність, немає ніякого обов’язку, щоб це джерело було виключно git‑репозиторієм. Організації можуть використовувати інші системи збереження конфігурацій, окремі сервіси для секретів, різні механізми керування станом — і при цьому залишатися в руслі GitOps‑ідеї.
Де GitOps працює прекрасно, а де починає скрипіти
Популярність Kubernetes автоматично потягнула за собою і популярність GitOps. Багато компаній, які тільки починають працювати з Kubernetes, сприймають GitOps як «де-факто спосіб» управління середовищами: є кластери, є маніфести, значить, має бути GitOps‑агент, який тягне все з репозиторію.
За спостереженнями Ереза, у великих організаціях GitOps уже став майже стандартним підходом до Kubernetes‑кластерів. Але далі починається намагання «протягнути» цю модель і на все інше — наприклад, інтегрувати Terraform через безперервну реконсиляцію зовнішніх ресурсів за описами в репозиторії. Є експерименти, є проєкти, які так роблять, але поки що важливіше інше: у прагненні «описа́ти все декларативно й у Git» команди стикаються з реальністю.
У реальному процесі розгортання майже завжди є кроки, які погано вкладаються в чисто декларативну модель. Ерез перелічує те, що зустрічається повсюдно:
- короткі smoke‑тести після розгортання;
- надсилання сповіщень після успішного деплою;
- міграції баз даних чи інші операції над станом, які складно описати як чистий «цільовий стан».
Для таких речей існують окремі інструменти й механіки — від пайплайнів розгортання до Argo Workflows, які намагаються «загітопсити» імперативні процеси. І це працює для частини команд, але не знімає базового обмеження: не все, що відбувається під час релізу, природно описується як декларативний стан у Git.
У результаті, каже Ерез, деякі інженерні колективи потрапляють у пастку «якщо в нас є Git і GitOps‑агент, кожна задача схожа на цвях». Вони намагаються загнати в GitOps усі етапи життєвого циклу розгортання, хоча частина процесів природніше й безпечніше реалізовується імперативними пайплайнами чи іншими засобами.
GitOps не для всіх: проти «абсолютизму» в інфраструктурі
Коли GitOps поширився з Kubernetes‑світу на ширшу аудиторію, інфраструктурні команди почали чути на конференціях і в блогах дуже жорсткі формулювання: «ви маєте робити GitOps», «усе має бути в Git», «це сучасний стандарт». Після цього багато хто приходить до постачальників інструментів — зокрема й до Octopus Deploy — уже з очікуванням, що рішення «має бути GitOps».
Ерез ставиться до цього скептично. Він підкреслює: GitOps потенційно не є обов’язковим для всіх локацій, середовищ і команд. У нього є сильні сторони, але є й ситуації, де він або надто важкий, або просто не потрібен.
Команди часто забувають, що за межами декларативних маніфестів Kubernetes у їхньому житті є й інші речі. Наприклад:
- оркестрація smoke‑тестів;
- комбіновані зміни інфраструктури й коду;
- прості кроки на кшталт відправки повідомлення чи запуску додаткової перевірки.
Ці задачі не вимагають жорсткої прив’язки до GitOps‑агента. Вони можуть чудово жити в окремому CI/CD‑інструменті, який працює імперативно, запускає потрібні дії послідовно, реагує на помилки, взаємодіє з іншими системами.
Тому Ерез радить дивитися на GitOps як на набір корисних принципів, які можна застосовувати там, де вони природно підходять, а не як на всеохопну догму. Одне середовище може управлятися через GitOps‑агента, інше — через класичний пайплайн, третє — комбінованим способом. Головне — щоби команда чітко розуміла, для чого вона обирає кожен підхід.
Фокус не на термінах, а на постачанні софту
У розмовах із клієнтами Ерез постійно повертається до простої думки: більшість команд у реальності не цікавить, як саме буде називатися їхній процес — GitOps, DevOps, «платформа як продукт». Їм потрібно стабільно й безпечно постачати програмне забезпечення.
Якщо GitOps допомагає зробити це — чудово. Якщо команда використовує його принципи лише для Kubernetes‑кластерів, а все інше розгортає звичними пайплайнами — теж нормально. Якщо якісь речі взагалі не мають потрапляти в git‑репозиторій — наприклад, секрети — це не зрада і не «порушення канону», а просто свідома інженерна практика.
Ерез протиставляє це конференційному «абсолютизму», де зручно подавати одну технологію як універсальне рішення. У реальному світі десятки тисяч компаній будують процеси доставки софту з урахуванням власних обмежень, регуляцій, історичних рішень і рівня зрілості команд. І в цьому світі GitOps — не релігія, а лише один із інструментів.
Висновок: GitOps як здоровий компроміс, а не як тотальна віра
GitOps виник як природне продовження декларативної моделі Kubernetes і дуже влучно влучив у потребу: зробити стан інфраструктури видимим, відтворюваним і підконтрольним. Чотири його стовпи — декларативність, версіоноване й незмінне джерело правди, pull‑модель і безперервна реконсиляція — справді дають командам потужну рамку мислення.
Та разом з успіхом прийшла й спокуса перетворити GitOps на єдино правильний шлях. Саме проти цього застерігає Роберт Ерез. Назва з префіксом «Git» створила хибне відчуття, що все мусить опинитися в репозиторії, включно з тим, що туди відверто не належить, як‑от секрети. Спроби «декларативізувати» кожен крок розгортання врешті впираються в реальність: не всі операції зручні як чистий цільовий стан, частина потребує імперативних процесів, сторонніх сервісів, додаткової логіки.
Тому зрілий підхід до GitOps — не «перейти на нього повністю», а обрати, де саме його принципи приносять найбільшу користь. Для Kubernetes‑кластерів і частини інфраструктури він може стати стандартом. Для секретів, складних міграцій чи бізнес‑процесів навколо релізів — лише одним із елементів більших CI/CD‑ланцюжків.
Команди, які пам’ятають про це, менше сперечаються про назви й більше концентруються на тому, що справді важливо: як зробити поставку програмного забезпечення надійною, прозорою й керованою — незалежно від того, чи зберігається конфіг саме в Git, чи ні.