Да это просто пример, иллюстрирующий что гит - плохой источник истины, если он не имеет связи с артефактами.
Два запуска сборки артефакта на одном комите могут дать совершенно разные результаты. Причин может быть тысяча - от незафиксированных зависимостей до кешей на сборщике.
И в гиотпс нет рецепта как сделать его хорошим источником истины.
Это нужно понимать чтобы выстроить качественный, стабильный процесс доставки программного обеспечения.
Мы тегировали имидж по git commit hash, запушили его в registry, потом была автоматическая чистка регистри от образов старше полугода. Спот ноды, на которых крутилось приложение перезаказались и новые поды тупо не смогли подняться. Мы повторяем сборку этого имиджа, но в коде есть незафиксированная транзитивная зависимость от библиотечки, которая за пол года стала несовместима с текущими вызовами и часть функционала приложения просто ломается.
А какая разница по большому счету? Что образ, что бинарник - артефакты сборки. Образ это такой расширенный бинарник, который включает среду выполнения.
Подход хорош только на бумаге. Но если реализовать его только частично (чарт, имидж, секреты вне гита), то источник правды получается очень посредственный. Плюс получается очень много затрат на его реализацию.
Не проще ли принять то, что мир не идеален и попытаться сделать то же самое более лёгким и простым путём?
Хелм чарт это "лёгкая" зависимость. Но её, как правило, нужно делать out of gitops scope и тут могут быть варианты, - например в HelmRelease у вас диапазон версий чарта, а та часть пайплайна, которая должна собрать и запушить в репозиторий последнюю версию чарта сфэйлилась - в итоге у вас новый имидж на старом чарте, и глядя в гит вы просто не можете понять что пошло не так. Или сервис репозитория чартов слетел и был восстановлен из бэкапа (не самого свежего), - всё консистентность окружения нарушена.
Что до сборки докер имиджа - пвторяемость сборок докер имиджей это фундаментальная проблема. Тут слишком много чего может пойти не так, - от незафиксированной зависимости в библиотеках до содержимого кэша на сборщике.
Если вы утверждаете, что ваши сборки имиджей на 100% повторяемые, то либо вы большой молодец и провели очень большую работу чтобы это было так, либо вы что-то не знаете.
Хорошей практикой чтобы гарантировать повторяемость выкатов является испоьзование так называемых "золотых имиджей", - когда мы собираем один имидж и прогоняем его через все наши окружения и именно его доставляем на продакшен. ТОлько тогда мы можем гарантировать, что доставили на прод именно то что оттестировали.
И это не учитывается в GitOps вообще никак. Даже намёка нет на накую возможность.
Там картинка есть. GitOps in 1 slide. На английском правда, но знание английского - обязательная вещь для ИТ-шника.
Переведу его для вас: GitOps это паттерн разработки/управления системами. Имеется в виду информационные системы и управление их конфигурацией.
Далее в том же разделе идёт достаточно подробное описание паттерна. Git - единственный источник истины, момент про CD тулинг и два репозитория. Если на ваш взгляд я их не полно изложил, там есть ссылки на сайт, целиком посвященный GitOps - можете разобраться самостоятельно.
И я категорически не понимаю что вас смущает в том, что я рассматриваю один из самых распространённых вариантов реализации GitOps? С Helm и Kubernetes.
Причем я подробно, по шагам, рассматриваю процесс доставки приложения в рамках процессов GitOps.
Если вы настолько не в теме, возможно вам нужно начать с какого-то более простого материала?
Кстати про сравнение CIOps с GitOps будет во второй части статьи. Но опять же судя по всему это может быть для вас сложновато.
Да это просто пример, иллюстрирующий что гит - плохой источник истины, если он не имеет связи с артефактами.
Два запуска сборки артефакта на одном комите могут дать совершенно разные результаты. Причин может быть тысяча - от незафиксированных зависимостей до кешей на сборщике.
И в гиотпс нет рецепта как сделать его хорошим источником истины.
Это нужно понимать чтобы выстроить качественный, стабильный процесс доставки программного обеспечения.
Не всё так просто. Кейс из практики:
Мы тегировали имидж по git commit hash, запушили его в registry, потом была автоматическая чистка регистри от образов старше полугода. Спот ноды, на которых крутилось приложение перезаказались и новые поды тупо не смогли подняться. Мы повторяем сборку этого имиджа, но в коде есть незафиксированная транзитивная зависимость от библиотечки, которая за пол года стала несовместима с текущими вызовами и часть функционала приложения просто ломается.
Я правильно понимаю, что в своём подходе вы не ориентируетесь на правила GitOps?
Я привожу её в качестве противопоставления.
Любую концепцию можно описать критерием полноты, с которой она решает поставленную задачу.
Концепция "колесо" не будет полной без указания того, что колесо должно быть круглым для облегчения качения.
Именно! Об этом во второй части статьи :)
Ну так верфь это не гитопс а гиттерминизм :)
А какая разница по большому счету? Что образ, что бинарник - артефакты сборки. Образ это такой расширенный бинарник, который включает среду выполнения.
Вопрос в повторяемости сборок.
Повторяемость мы можем гарантировать с использованием концепции golden image.
Заметка была о другом. Повторяемость это краеуголный камень доставки приложений. И он полностью проигнорирован в GitOps.
И нет, это не очевидно.
Тоесть по-вашему секреты не в гите позволяют гиту оставаться единственным источником правды?
У нас база на проде отвалилась от воркеров. Гит не менялся. В чем же может быть проблема? Неучто кто-то снёс секрет в волте?
Про повторяемость сборок докер имиджей я уже писал выше. Мы не можем их гарантировать на 146%.
Сам подход "git - источник правда" очень хорош.Подход хорош только на бумаге. Но если реализовать его только частично (чарт, имидж, секреты вне гита), то источник правды получается очень посредственный. Плюс получается очень много затрат на его реализацию.
Не проще ли принять то, что мир не идеален и попытаться сделать то же самое более лёгким и простым путём?
Об этом во второй части статьи.
что все описанное - вполне себе преимуществаМы твой позор в подвиг обратим (с).
Почти уже закончили вёрстку второй части статьи. В ней целиком и полностью про проблемы подхода. Не переключайтесь :)
Посмотри на мой ответ выше. Наличие registry делает единый источник правды в гите очень посредственным.
Внедрение подписи многое бы решило, но в гитопс это даже не подразумевается.
Флюкс флюксом, но ты можешь назвать тулинг в котором это реализовано лучше?
Хелм чарт это "лёгкая" зависимость. Но её, как правило, нужно делать out of gitops scope и тут могут быть варианты, - например в HelmRelease у вас диапазон версий чарта, а та часть пайплайна, которая должна собрать и запушить в репозиторий последнюю версию чарта сфэйлилась - в итоге у вас новый имидж на старом чарте, и глядя в гит вы просто не можете понять что пошло не так. Или сервис репозитория чартов слетел и был восстановлен из бэкапа (не самого свежего), - всё консистентность окружения нарушена.
Что до сборки докер имиджа - пвторяемость сборок докер имиджей это фундаментальная проблема. Тут слишком много чего может пойти не так, - от незафиксированной зависимости в библиотеках до содержимого кэша на сборщике.
Если вы утверждаете, что ваши сборки имиджей на 100% повторяемые, то либо вы большой молодец и провели очень большую работу чтобы это было так, либо вы что-то не знаете.
Хорошей практикой чтобы гарантировать повторяемость выкатов является испоьзование так называемых "золотых имиджей", - когда мы собираем один имидж и прогоняем его через все наши окружения и именно его доставляем на продакшен. ТОлько тогда мы можем гарантировать, что доставили на прод именно то что оттестировали.
И это не учитывается в GitOps вообще никак. Даже намёка нет на накую возможность.
Там картинка есть. GitOps in 1 slide. На английском правда, но знание английского - обязательная вещь для ИТ-шника.
Переведу его для вас: GitOps это паттерн разработки/управления системами. Имеется в виду информационные системы и управление их конфигурацией.
Далее в том же разделе идёт достаточно подробное описание паттерна. Git - единственный источник истины, момент про CD тулинг и два репозитория. Если на ваш взгляд я их не полно изложил, там есть ссылки на сайт, целиком посвященный GitOps - можете разобраться самостоятельно.
И я категорически не понимаю что вас смущает в том, что я рассматриваю один из самых распространённых вариантов реализации GitOps? С Helm и Kubernetes.
Причем я подробно, по шагам, рассматриваю процесс доставки приложения в рамках процессов GitOps.
Если вы настолько не в теме, возможно вам нужно начать с какого-то более простого материала?
Кстати про сравнение CIOps с GitOps будет во второй части статьи. Но опять же судя по всему это может быть для вас сложновато.
В статье нет ничего про пицу и алкоголь. Не практикуете такое?
Дьявол кроется в деталях.
Хранить конфигурацию в гите и раскатывать их из гита придумали задоооооолго до гитопса (посмотрите тот же тест Лимончелли).
Я хочу от концепции ровно то, что она заявляет - от гита как единственного источника истины до key benefits + пунктов why i should use gitops.
И во второй части статьи обязательно раскрою как GitOps (конкретно flux2) реализует эти пункты. Как говорится, не переключайтесь.
Интересно как вы 800 источников насчитали...
Приведите кейс когда на job/step пайплайна нужно больше.
ТОлько если настраивать интеграцию. Ничто не мешает НАПРИМЕР сделать на раннере кубконфиг на оба кластера и просто переключать контекст.