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

[@sergeydev8273]

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

[@agvaresss]

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

[@dmitriysolodukha9646]

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

[@elcolex777]

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

[@orbuzegi]

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

[@АртемийОкулов]

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

[@adammartin7477]

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

[@Andy-qg6mm]

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

[@владимирсенцов-р1ю]

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

[@AndersonSilva-dg4mg]

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

[@Flant]

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

[@MrMobilesfinks]

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

[@miky7miky]

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

[@andreylagunov2638]

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

[@egorkomarov4719]

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

[@slip3101]

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

[@_piiraa]

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

[@Mausspb]

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

[@kirillmorgachev1752]

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

[@ШураАрхипов-м9ц]

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

[@y6vmeq]

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

[@fabasoad]

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

[@Vovannumberonee]

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

[@kimrgrey]

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

[@Flant]

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

[@Holms]

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

[@Noable]

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

[@rjeka]

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

[@ОлександрКотов-э3б]

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

[@davidmagton]

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

[@ОлександрКотов-э3б]

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

[@nickb5959]

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

[@Flant]

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

[@MaximVasilets]

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

[@Wzooff]

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

[@oleksandrholovko2794]

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

[@batazor]

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

[@zimmermann512]

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

[@jewgenijmoldawski3306]

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

[@seedteam7646]

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

[@ashimov1970]

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

[@Flant]

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

[@pgdnpgdn23]

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

[@dmitriysolodukha9646]

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

[@ashimov1970]

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

[@pavelsazon2523]

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

[@spiritcxz]

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

[@michaelchudinov]

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

[@МаксимГайдай-ъ5ж]

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

[@Flant]

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

[@МаксимГайдай-ъ5ж]

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

[@Flant]

@@МаксимГайдай-ъ5ж будем рады! Если возникнут проблемы - наши разработчики на связи в t.me/werf_ru

[@cloudevops]

Спасибо

[@dreamworm8]

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

[@ashimov1970]

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

[@Flant]

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

[@ashimov1970]

@@Flant спасибо

[@dmitriymatveev4558]

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

[@MrBartonello]

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

[@davidmagton]

Sony a7iii

[@BeloRing]

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

[@владимирсенцов-р1ю]

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

[@alexandersmirnov4274]

что значит hyperconvergence?

[@Flant]

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

[@СергейПтушкин-к5ы]

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

[@ParanoidAndroid777]

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

[@NikolaiTrukhanov]

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

[@ParanoidAndroid777]

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

[@Mausspb]

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

[@ParanoidAndroid777]

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

[@nikitaproit]

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

[@vskovzgird]

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

[@f1baf1banac14]

COOOOOLLest video ever !

[@YouSysAdmin]

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

[@МаксимГайдай-ъ5ж]

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

[@sergey2151]

Материал подается хорошо, для введения в тему - самое то. Только докладчик слишком много жестикулирует, ОЧЕНЬ отвлекает от просмотра картинки. Если не получается контролировать руки, то можно просто "обрезать" человека по плечи или вообще убрать из кадра бОльшую часть времени.

[@AlexK-df4ne]

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

[@GreyDjin]

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

[@MrPetryks]

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

[@КонстантинБочкарев-к2ь]

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

[@defend00r]

Ну и артист

[@МаксимМакаров-к8б]

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

[@mootal2202]

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

[@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 не достаточно хорош, считайте на здоровье. Когда моя маленькая дочь в первый раз жарила яичницу и успешно её спалила, она тоже решила, что виноваты проклятые куры которые несут не правильные яйца. Кстати, целая группа в садике с ней согласилась и её выводы подтвердила )))

[@ProtossZealotDaol]

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

[@НиколайМакаров-э8э]

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

[@АлексейЛ-ч6р]

CI-Ops -NORM, GitOps - GOVNO