Сегодня мы хотим поговорить не о инструментах и технологиях, а о подходах. Думаю, многие из вас слышали такой подход, как GitOps. Он в свое время появился и получил распространение благодаря компании WeaveWorks (https://www.weave.works/).

GitOps - это метод / подход / практика / модель (называйте как удобно) к управлению кластером Kubernetes, и доставке приложений, которые в этом кластере работают. Чем-то это напоминает подход Infrastructure-as-a-Code, но чем-то и отличается. Если коротко, то, согласно блогу той же WeaveWorks (https://www.weave.works/technologies/gitops/), у вас GitOps, если:

🍬 Ваша система описана декларативно
🍬 Целевое требуемое состояние описано в едином источнике - Git
🍬 Автоматическое применение изменений
🍬 Софт, отслеживающий корректность фактического состояния

На текущий момент этот подход набирает обороты, уже появилось достаточное количество специализированных инструментов (GitOps - агентов), практических реализаций все больше. Преимущества подхода просты и понятны. И одно из них как раз и заключается в том, что GitOps - это не про инструменты, а про подход. Который как раз оставляет вам свободу выбора тех инструментов, к которым вы привыкли, и не привязывает вас к какому-то одному.

Но сегодня мы не об этом ) Сегодня как раз хотим поговорить не о том, почему это хорошо. А о том, почему это не (очень/всегда) хорошо.

Как и у любого подхода, у GitOps есть свои ограничения. Недавно наткнулись на интересную и познавательную статью - GitOps: The Bad and the Ugly (https://blog.container-solutions.com/gitops-limitations). В ней описаны следующие ситуации и проблемы, которые порождаются при GitOps - подходе:

🍬 Конфликты при апдейтах репозитория. Единый источник правды - Git - это и благо, и нет. Когда у вас большое окружение, сложное ПО с большим количеством микросервисов, конфликты при апдейтах неизбежны
🍬 Отсюда же следует вторая проблема: в попытке уйти от единого репозитория, их количество начинает расти большими темпами, и в итоге вы оказываетесь в ситуации, когда приходится тратить значительную часть времени на управление самими репозиториями, pull-request management, правильная настройка прав доступа, и т.д.
🍬 Недостаток наглядности, как следствие первых двух проблем. Понять и отследить фактическое состояние кластера, когда у вас много репозиториев - сложно
🍬 Сложность управления секретами (secrets management). GitOps не заточен для решения этой задачи сам по себе, и не особенно помогает ее решать. Потребуется единая точка управления секретами в виде отдельного хранилища
🍬 Аналогично и в части аудита изменения конфигураций. Бывают ситуации, когда отследить историю изменений сложно
🍬 Недостаток валидации артефактов на входе. В отличие от обращения к кластеру по API, при котором валидность проверяется, при простом коммите в git за корректность отвечает сам пользователь

Понятно, что не все из этих пунктов применимы ко всем кластерам, окружениям и компаниями. И нужно смотреть case-by-case.
Даже среди нас эти пункты вызвали дискуссии и разные мнения. Поэтому хотим обсудить это с вами - что вы думаете? Актуален ли для вас GitOps подход в целом? Применяете его? Сталкивались ли с проблемами и ограничениями? Поделитесь вашим опытом и соображениями на этот счет в комментариях!

П.с. А чтобы вам интереснее было читать статью - для затравки, в ней дано видение на подход, альтернативный GitOps'у.
П.с.2. И в этой же статье - ссылка на статью "11 причин зачем вам нужен GitOps" :) Enjoy!