Что же такое GitOps? Его свойства и недостатки

GitOps - современный подход, улучшающий паттерн IaC («инфраструктура как код») для доставки приложений в Kubernetes (и не только). Он был придуман для того, чтобы процессы CI/CD были детерминируемы, идемпотентны, хорошо наблюдались и т.д. Однако в реальной жизни, при использовании существующих утилит, не всё получается гладко.
Это видео - рассказ техдира компании «Флант» Дмитрия Столярова про подход GitOps, его сравнение с CIOps, оценка главных характеристик с учетом «большей картины» (полного CI/CD-пайплайна). Оно доступно также и в англоязычной версии ( • GitOps approach, its p... ).
00:00 Введение
01:01 Уточнение по терминологии «GitOps»
02:33 Про werf
03:20 Что такое GitOps
06:53 Оценка преимуществ и недостатков GitOps
13:58 Что такое CIOps
17:22 Оценка CIOps
26:15 Сравнение GitOps и CIOps с учетом всей картины
31:21 Заключение
* werf (ru.werf.io/ github.com/werf/werf) - Open Source-утилита для CI/CD, реализующая наш взгляд на GitOps.
* kubedog (github.com/werf/kubedog) - библиотека для языка Go для отслеживания Kubernetes-ресурсов в CI/CD-пайплайнах.
P.S. Текстовая версия этой лекции доступна в нашем блоге: habr.com/ru/company/flant/blo...

[@agvaresss]

не привычно слышать Дмитрия, говорящего в таком темпе. )

[@dmitriysolodukha9646]

Можно поставить скорость 1.5х :-D Так привычней

[@elcolex777]

Закончились запасы адреналин раш

[@orbuzegi]

@@dmitriysolodukha9646 так и сделал, лол :)

[@user-ry5zh7mo8j]

а для тех кто слушал его ранее в 1.5х приходится ставить 2х, чтоб было привычно) Но Дмитрий как всегда, объясняет очень доступно, понятно и интересно, на любой скорости)

[@adammartin7477]

Кокаин - плохо

[@sergeydev8273]

Флант конечно лютые!) Качество материала и подачи просто пушка!

[@Andy-qg6mm]

Отключаем в ГитОпс операторе синхронизацию с докер реджистри (т.е. он будет мониторить только гит) и избавляемся от всех описанных недостатков этого подхода. Кроме этого ГитОпс удобно использовать не только для выкатки собственных приложений в кластер, но и для управления этим кластером в целом - роли, квоты, сопуствующие тулы и т.д. Также такой подход значительно упрощает Disaster Recovery который по сути сводится к созданию нового кластера, установке мастер-ключа для расшифровки секретов (если используется что-то типа sealed-secrets) и накатке гитопс оператора который восстановит состояние до целевого.

[@user-gw6df6ns7e]

То есть в DevOps репо просто тег образа проставляем например? Можно даже скрипт написать, чтобы автоматически это делал когда собрался новый образ. Можно это отдельным таском сделать. Тут уже как душа пожелает. Тут только одна проблема - данные и их структура. Часто у нас есть некие операции DDL которые нельзя взять и откатить просто сменив тег в репо. Ну не описывается у нас таблица через манифест к сожалению.

[@miky7miky]

Отличное видео! Теперь не хватает несколько видео-воркшопов, как Вы показываете решение вышеупомянутых вызовов на практике с помощью Werf.

[@AndersonSilva-dg4mg]

Дмитрий, спасибо за бесплатную инфу, активно смотрю и читаю ваши материалы. Сейчас буду смотреть. Вы крутые!

[@Flant]

И вам спасибо!

[@egorkomarov4719]

Качество картинки и звука - топ. Продолжаю смотреть сам видос

[@andreylagunov2638]

про стену, супер. Очень точно подмечено. devops про прозрачность и отсутсвие препятствий у разработчиков. А в реальности часто два репозитория и да, разделение :) CIops как единая система вместо gitops, мне очень близко. Интеграция и единая система. Единая система должна быть проста и прозрачна.

[@MrMobilesfinks]

Дмитрий, отличный взгляд. Спасибо, что делишься своей философией и видением. Очень ценю твои выступления они позволяют увидеть то на что обычно замылен взгляд в повседневной работе.

[@Mausspb]

Спасибо за подробный обзор подхода GitOps в особенности за разбор ключевых моментов. Очень удобно, что есть и видео и статья на хабре ! По поводу последнего вопроса, есть ощущение, что CI трансформируется во что-то более стандартизированное и нативное(в этом контексте мне нравится движение gitlab-ci). P.S.: Так же непривычно слышать Дмитрия в таком ритме )

[@slip3101]

Здравствуйте! Приятно слушать, все по делу. Материал сильно помог в выборе и осознание того с чем имею дело. Спасибо за видео.

[@fabasoad]

Очень структурированно и понятно. Спасибо!

[@L1texxxomg]

Супер! Не знал, что у вас есть ещё и ролики такого плана. Спасибо!

[@Flant]

Только начинаем, но планов много! :-)

[@kirillmorgachev1752]

Дмитрий, спасибо! Классно получились вставки. Очень интересно и нескучно!

[@_piiraa]

Спасибо из Латвии, хорошая информация

[@Noable]

Спасибо за материал, классная картинка, звук, подача

[@oleksandrholovko2794]

Непонятно почему у меня в CI-опс билд будет недерминирован, если у меня в гитлаб-СИ пайплайн запускается единожды и создает докер-имедж с тегом коммита. второй раз никто руками не будет запускать этот пайплайн. на моменте паблиша просто генерируем тег который коммитим по апи в репо на этот коммит и клеим на тег уже собранного докера. Вроде как детерминизм остается нерушимым. Хелм чарт так же хранится в аппликейшн гит-репе. Все эти стратегии билда и тегирования отчасти навеяны вашими рекомендациями из конференций, но увы там вы конкретных примеров не приводили и пришлось на колене додумать самому. Вобщем у меня было стойкое ощущение что весь мой пайплайн очень близок к гитопс (git - single source of truth). Единственным нарушением правил - является хранение продакшн конфигов в отдельной репе и на момент деплоя - они апплаятся к уже собранному хелм-чарту через кастомный values_prod.yaml. Спасибо за структурированную подачу и разбор тонкостей, которые нужно учесть. Как всегда вы делитесь хорошим опытом и расширяете кругозор!

[@batazor]

Согласен, единственно что вносит смуты это различные переменные окружения, можно через blackbox шифровать и хранить в той же репе для каждого окружения, но это не для всех кейсов подходит P. S. Хотя можно и во внешнем хранить и подключать как саб-модуль

[@zimmermann512]

Билд недетерминирован от того, что два раза запущенная сборка образа из одного коммита даст потенциально бинарно разные образы, разве нет (представим, что необходимость второй раз запустить пайплайн возникла) ?

[@jewgenijmoldawski3306]

@@zimmermann512 пересборка по одному и тому же commit это anti-pattern в ci/cd. Ну да, бывает надо, но лучше избегать.

[@y6vmeq]

Обожаю флант🔥🔥🔥 отлично все рассказали. Только начал присматриваться к werf, нужно изучить поближе

[@kimrgrey]

Ребята, вы делаете очень крутую работу, генерируя контент на русском языке. Благодаря вам, в частности, наш родной язык не умирает для IT. Считаю, это важно. Поэтому переводы - это збс, но, ИМХО, можно бы обойтись субтитрами, а не делать вдвое большую работу ради перевода. Хотя, возможно, коммерчески это и круче, потому что потенциально может привести клиентов, я хз по мотивации. Как бы то ни было, спасибо за ваш труд!

[@Flant]

Спасибо большое за мотивирующие слова! ;-)

[@Holms]

мне как из англии важно доносить нашим динозаврам суть через такие видосы так как не всегда у меня получается защитить ту или иную технологию для конкретных целей. я как бы не нанимался быть учителем )) так что мне видосы на инглишы нужны.

[@BeloRing]

Круто! Спасибо

[@pgdnpgdn23]

Красиво. Спасибо.

[@nickb5959]

Спасибо за видос. Почаще выпускайте в это нелегкое время)) расскажите пожалуйста про правильную с вашей точки зрения стратегию тегировагия образов

[@Flant]

Спасибо за отзыв и пожелания! По поводу стратегии тегирования пока можно почитать эту нашу статью - в ней рассказано, что мы выбрали для werf и почему к этому пришли: habr.com/ru/company/flant/blog/495112/

[@pavelsazon2523]

Крутое видео!

[@user-qu9je8im7e]

Ты крутой тип. Спасибо что делаешь такое

[@user-hg9gz9dj5u]

Отличное видео)))

[@dmitriymatveev4558]

Хорошее видео.

[@cloudevops]

Спасибо

[@rjeka]

Спасибо за интереный обзор. В данный момент переходим на гиопс, сейчас как раз процесы обкатаны на дев стендах и все движется к тому что бы уйти в прод. Согласен со многим из видео, кроме усложнения. Вы в ролике рассмотрели модель CI\CD только приложения не затрагивая инфраструктцрную часть стендов. И не рассмотрели плюсы гитопс. Например мне подход гитопс с использованием argocd позволил вносить изменения во множество стендов одним коммитом в инфраструктурный репозиторий с хелм чартами. Описать все стенды проекта в одном репозитории фактически 2 yaml файлами. Более удобно и гибко создавать динамические окружения для разработчиков. Да недостатки есть, как у любого инструмента, но я пока вижу плюсов больше чем минусов.

[@Vovannumberonee]

Блин чувак, говори как на конфе, там быстро и от души :) За материал спасибо 🙏

[@user-cu2yw9fc5j]

В FluxCD деплой новых имеджей работает так - когда появился новый имедж в реджистри FluxCD делает комит с новый образом в репу с манифестами, и только после этого синкает состояние репы с кубом, то есть всегда то что в репе соотвсвует тому что в кубе, нет двух независимсых источников правды - гита и реджистри. Но даже такое поведение можно отключить что бы FluxCD не реагировал на изменения в реджистри. В таком случае тег имиджа нужно обновлять руками или через CI.

[@davidmagton]

Привет. Спасибо за комент! Все так. Более того. Если я правильно помню, то в argo так вообще нельзя. И я бы сказал, что это главный косяк видео. Я должен был четко это обозначить, но не сделал. Плохо. Очень расстраиваюсь по этому поводу. Сейчас получается, что многие натыкаются на эту неточность и смотрят видео через призму "Столяров тут что-то гонит". Или не смотрят дальше вообще... Тот факт, что теги фиксированы в гите - никак не меняет ситуацию. Все поинты видео остаются валидны. Состояние registry, к сожалению, не определяется одним тегом.

[@user-cu2yw9fc5j]

@@davidmagton Дмитрий, в любом случае видео интересное, с удовольствием посмотрел, очень доступно обьясняете концептуальные вещи, вообще люблю смотреть Ваши видео, успехов Вам !

[@MrBartonello]

Актуальный и интересный материал, спасибо! А еще - отличная картинка. Подскажите, пожалуйста, модель камеры )

[@davidmagton]

Sony a7iii

[@MaximVasilets]

Спасибо за отличное видео. Для себя искал ответ на очень важный для меня вопрос - как скрыть важные секреты в CI/CD процессах. На самом деле очень легко, специально или случайно, такие секреты как AWS или Kubernetes ключи вывести в консоль или еще как-то сделать доступными внутри компании, или еще хуже для общего доступа. Я думал что GitOps поможет мне в этом, но видимо все не так просто.

[@Wzooff]

При правильном предоставлении прав ci воркерам, у вас не будут появляться секреты в логах. Например воркер использует irsa для доступа к ecr, если говорить и паблише образов. Так же все нынешние ci тулы позволяют определить секреты в энв переменных и они будут маскироваться. Так что надо читать мануалы по вашей си системе.

[@seedteam7646]

Круто на английском! не парься по поводу акцента, очень круто!!!!

[@dreamworm8]

Звук отличный! Как писали?

[@dmitriysolodukha9646]

Вот бы еще посмотреть видос Argo CD vs werf

[@ashimov1970]

тема! хотя при беглом знакомстве с документацией обоих проектов у Арго тема приведения реестра докеров к желаемому состоянию не раскрыта

[@ashimov1970]

В свете технологии билдпаков + недавно анонсированного Гуглом Config Sync насколько актуален Werf?

[@Flant]

Google Sync ограничен cloud-платформой Google, а werf - универсальная утилита (для деплоя в условно любой Kubernetes). GS - это по сути такой же pull-оператор, как и другие решения, о минусах коих идет речь в этой лекции. Buildpacks - интересный проект; сравнение werf с ним у нас стоит в плане статей. Однако он только про сборку. В свою очередь Google Sync - только про деплой. А werf - и про сборку, и про деплой. Эта утилита про «склеивание» разных процессов CI/CD в одном (унифицированном) месте. И она дает возможность использовать разные инструменты (предпочтительную CI-систему, Kubernetes любого вендора…) для своих задач.

[@f1baf1banac14]

COOOOOLLest video ever !

[@user-er9ev7vf1h]

тестировалась ли werf на совместимость с OpenShift? OKD4?

[@Flant]

Не делали таких тестов.

[@user-er9ev7vf1h]

@@Flant в данный момент разворачиваем тестовый кластер OKD4. Скорее всего попробуем и werf. По результатам могу поделиться впечатлением

[@Flant]

@@user-er9ev7vf1h будем рады! Если возникнут проблемы - наши разработчики на связи в t.me/werf_ru

[@ParanoidAndroid777]

Спасибо за информацию, ждем вас в трендах) P.S. сейчас думаю писать диплом по k8s, но что конкретно взять, чтобы было актуально, пока не определился. Интересует тема логирования, например чтобы по запросу, поступившему на ingress, можно было проследить путь по кластеру и посмотреть логи в каждом сервисе, участвовавшем в оброботке, вплоть до запроса в бд, если бд у нас внутри кубера. На сколько эта тема может быть актуальной? Можите посоветовать еще какие то темы?

[@user-iq6xw4hv9m]

Отследить запрос по цепочке, это tracing называется скорее, а не логгирование.

[@ParanoidAndroid777]

@@user-iq6xw4hv9m а как tracing связать с логами? например такая ситауция: клиент отправил запрос, он как то прошел по нашему кластеру, и вернул клиенту 500 ошибку. Как мы можем понять, в каком сервисе была ошибка и какая именно?

[@Mausspb]

@@ParanoidAndroid777 вот например статья на эту тему. medium.com/opentracing/opentracing-on-kubernetes-get-yer-tracing-for-free-7a69cca03c8a Выше верно написали про tracing. Собственно каждое приложение имеет свой ворклоад/лейблы, по этим ключам видно от какого приложения какие логи приходят, в системах сбора логов можно фильтровать по этим ключам (а также по traceID).

[@ParanoidAndroid777]

@@Mausspb Спасибо за информацию, обязательно почитаю!

[@nikitaproit]

Скажу так: раз вы не в магистратуре, любая тема подойдет, а лучше просто устройтесь на работу, сделайте какую-нибудь таску на пару часов и вот диплом готов. Не тратьте силы на то, чтобы в вашем дипломе было что-то адекватное, его увидят 2 человека включая вас, это просто очередной документ который отправится в мусорное ведро как и все работы которые вы сдаете (диплом конечно хранят, но это чисто для галочки). Вы конечно можете заняться этим для себя, но тогда вас будет мучать то, что вашу работу выкинули в мусорное ведро.

[@ashimov1970]

Дмитрий, что вы скажете относительно проектов TEKTON и KNative в сравнении с WERF?

[@Flant]

Это продукты разного плана. Tekton - тоже для CI/CD, но той части, которая не реализуется werf, а интегрируется с werf (как, например, можно использовать GitLab CI или GitHub Actions с werf). Knative - решение из другой плоскости: сравнивать совсем странно.

[@ashimov1970]

@@Flant спасибо

[@michaelchudinov]

С асинхронностью между репой кода, образом докера и репой кластера боремся просто - деплоим кластер и приложение в кластер вручную, когда нужно.

[@user-gw6df6ns7e]

Не всегда можно назад состояние откатить. Например прошла миграция в базу и убрали поля из таблицы. В модели они при откате появятся 😢.

[@spiritcxz]

смешно 😄 1. что мешает держать тестовый и прод в разных кластерах или в разных неймспейсах. 2. так же допустим для теста в gitops репе можно создать тестовую и продовую папку для манифестов. 3. еще ни разу не было проблем с деплоем. 4. выпрямите руки и делайте правильное тегирование и проблем не будет. уже как неделю юзаю flux и проблем не знаю

[@vskovzgird]

Просто браво.

[@alexandersmirnov4274]

что значит hyperconvergence?

[@Flant]

Про гиперконвергентность у нас была статья - обзор Harvester: habr.com/ru/company/flant/blog/665066/

[@YouSysAdmin]

Дядько, прекращай щёлкать пальцами ;)

[@user-er9ev7vf1h]

он так кластеры разворачивает

[@GreyDjin]

слишком много баса в звуке голоса, нужно было срезать немного

[@AlexK-df4ne]

Обратите внимание какого труда ему стоит говорить медленно

[@defend00r]

Ну и артист

[@MrPetryks]

Без специфектов было бы не так увлекательно :)

[@user-gi9sk9zr8j]

А Навальный то делом занялся!

[@uk267i]

С детерминизмом вы погорячились. Мол состояние K8s зависит не только от Git. Чувак, Dockerfile же лежит в Git и от этого полностью зависит состояния Docker образа, а Registry это всего лишь доставка этого образа, собранного и хранящегося в Git... Остальные выводы примерно так же за уши притянуты. Не понимаю, зачем этот ролик? Просто вводить в заблуждение начинающих инженеров...

[@Flant]

Dockerfile'а в Git недостаточно для того, чтобы не зависеть полностью. Только на днях отвечали на похожий вопрос в комментариях на Хабре: habr.com/ru/company/flant/blog/526102/comments/#comment_24754288

[@uk267i]

@@Flant полной независимости в природе вообще не существует, всё взаимосвязано. Имеет смысл говорить про достаточный и необходимый контроль над собственным приложением, архитектурой, инфраструктурой, что и дает Dockerfile находящийся в Git. Если этот контроль в системе не нужен, то конкретный Docker образ вполне можно взять из внешнего источника, что только увеличивает гипкость GitOps подхода. Вы же, зачем-то, пытаетесь сказать, что GitOps какой-то не совсем правильный. У меня только один вывод напрашивается, вы или не умеете его готовить и/или намеренно искажаете суть пытаясь набить себе очки и добавить важности. Типа GitOps не правильный, а вот Флант настоящий огурец ))

[@Flant]

​@@uk267i GitOps позиционируют именно как гарантию того, что результат будет immutable (см. пункт 2 на opengitops.dev/). Уже не только мы заметили проблемы и говорим* о них - вот пример совсем свежей статьи по теме: thenewstack.io/does-the-gitops-emperor-have-no-clothes/ * В конце концов, мы не просто говорим «для красного словца» о каком-то недостижимом идеале. Мы решаем проблемы на практике и делимся этими мыслями, своим опытом.

[@uk267i]

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

[@user-jx4jb4of3c]

Как жаль что сложные видео смотрит так мало человек. Как жаль что это приводит к исчезновению продолжений... :-(

[@mootal2202]

Специфическая тема потому что. Это нормально.

[@ProtossZealotDaol]

Столяров специалист наверное хороший, но слово своё НЕ всегда держит. Для мужика - не очень.

[@user-up9ho2ko2d]

чем то похоже для доклад навального

[@user-gu9jg6ei4h]

CI-Ops -NORM, GitOps - GOVNO