Отличный заголовок. Ну а как назвать статью о штуке которая не приносит ничего нового, не решает большинство существующих проблем, добавляет новых, увеличивает сложность системы и трудозатраты? Просто ещё один способ деплоя.
Жаль, что вы фокусируетесь на моментах, которые вам кажутся спорными и отказываетесь видеть общую картину. Я сталкивался с многими странными решениями в своей практике, и к любой вещи подхожу на основе закона Мерфи: если что-то может быть сделано не так, это будет сделано не так. Это принцип, с позиции которого я писал и эту статью. Для меня неожиданно что этот подход вызвал у вас столько недоумения, потому что я считаю, что любой специалист с достаточным опытом рано или поздно приходит к этой позиции.
Развивайте системное мышление, повышайте уровень технической грамотности, будьте позитивным и уважительным и вас определённо ждёт успех в будущем.
В этом подходе источник истины распространяется на хранилище и его содержимое в том числе. Содержимое хранилищ может быть изменено, эти изменения могут быть не зарегистрированы (и не отображены в гит) но напрямую повлиять на функционал приложения. Это нужно по крайней мере учитывать.
Я бы назвал git в данном случае не single а main source of truth.
Если говорить строго, GitOps принципиально отказывается решать вопрос переноса версий ПО между окружениями. Я писал об этом в статье. Данный вопрос важный и этот тред прекрасно иллюстрирует мою мысль - когда какой-то вопрос не описан, каждый решает его сам при помощи собственных костылей и велосипедов.
Мерж кода - один из способов решения этого вопроса.
Другие способы связаны с активным скриптописанием. Тоесть stop scripting and start shipping не получается.
Можете рассказать как с вашей точки зрения этот вопрос решить правильно?
Обсуждение я замыкаю на уровне деплоя приложения потому что гитопс замыкается на уровне деплоя приложения. Тоесть это не continuous delivery (определение понятий есть в первjй части статьи), а просто способ организации деплоя.
разработать удобную и масштабируемую CI шаблонизацию
Разработать удобную и масштабируемую CI шаблонизацию придётся в любом случае. В случае гитопс вам придётся написать скрипт апдейта инфраструктурного репозитория. И потенциально его написать не проще чем скрипт деплоя через тот же хелм.
проработать удобные нотификации от CI систем
Нотификации как правило встроены в CI систему. И их возможности больше и шире чем у того же Flux Notification controller. Их настройка проще.
позаботиться о том, чтобы из енва и приложения можно было бы определить из какого билда оно прилетело (тут благо почти все CI системы это уже умеют в аннотации проставлять, но мало ли)
Да. Причем за счет стандартных переменных пайплайна CI это сделать проще чем в gitops(который этот вопрос тоже никак по умолчанию не решает - я писал об этом в статье). Я кстати говорю про это в этом докладе https://youtu.be/1uhfChFSktQ
при каких-то изменениях CI скриптов проходиться по n репозиториев приложений (мое любимое, даже с максимальной шаблонизацией CI шаблонов и автоматизацией массовых git апдейтов это всегда весело)
Во-первых в случае GitOps стоит ровно такая же проблема, потому что вам точно также нужно писать CI-скрипты для обвязки.
Во-вторых CI системы умеют нативно в централизованный CI. Посмотрите инклюд Gitlab CI из централизованного GIT репозитория или build configuration template в teamcity.
продумать и решить вопрос привязки енва к вашему git flow
Этот пункт, как я понимаю, обратен второму пункту? Посмотрите пожалуйста место про трекинг окружений в гитлаб в моей статье.
решать вопрос падающих helm upgrade на этапе деплоя (retries, timeouts, etc)
Основная мысль здесь была в том, что откат нужно хорошо спроектировать. Следование пути гитопс не гарантирует возможность откатиться. Возможно я это чуточку многословно изложил, с избыточным количеством примеров, но мысль именно такая.
Почему в CI систему нельзя класть пользователя с доступом в кластер?
Во-первых хранилище секретов это один из важнейших функционалов CI систем. Мы можем достаточно гибко заводить секреты, раздавать на них права и защищать от кражи.
Во-вторых есть множество способов интеграции CI систем с kubernetes. От авторотирующихся токенов в специальных модулях до установки раннера в кластер и использования сервисаккаунтов (схема очень близкая к контроллерам flux).
Но моя основная мысль здесь - к безопасности нужно подходить осмысленно. Гитопс утвержданием что он безопасен по умолчанию вводит в заблуждение.
Это опять же не позволит сделать stage propagation через merge.
Почему я настаиваю на мерже изменений для доставки изменений по окружениям? Если у нас окружения описаны отдельными репозиториями или папками в гите, и конфигурацию там мы изменяем вручную, либо при помощи каких-то скриптов, то это потенциально приводит нас к ситуации когда накапливается environment drift.
Я правильно понимаю, что этот комментарий скорее в поддержку моей мысли?
это очевидно
речь идёт о случае когда у нас много микросервисов и values для них хранятся в едином месте
существование инфра репозитория - фундаментальное требование гитопс
Есть такой принцип программирования - KISS (keep it simple, stupud).
Много репозиториев это не плохо при условии что это хорошо спроектировано. Согласно моему опыту, в отдельные репозитории нужно выносить только явно используемые совместно вещи. Если вы просто вынесете в отдельный репозиторий настройки всех приложений, то возникнет просто разрыв между приложением и его конфигурацией, который будет не очевиден и который потребуется покрыть документацией. Если вы добавите к этому репозиторий глобальных настроек приложенй, то просто будете просто теряться между репозиториями - в какой из них положить тот или иной конфигурационный параметр.
В качестве резюме - если создание отдельного репозитория сможет сократить сложность вашей системы и/или ваши трудозатраты, - во всех остальных случаях лучше этого избегать.
Судя по содержанию коментариев, вы не прочитали мои статьи. Взять хотябы это замечение что инфраструктурные репозитории мержить нельзя.
Меж тем в них я пытался дать системную картинку. Описать предпосылки -> обещания -> практическую реализацию -> анализ обещаний через практическую реализацию -> выводы. Причем снабдил это множеством ссылок на теорию и документацию потому что практика без теории слепа.
Вы же прошли статью по диагонали, выбрали несколько моментов, которые не понравились и пытаетесь их обсуждать вне контекста. Как в той притче когда человек нашел хвост слона и утверждал что слон это верёвка.
Вы правы. Более пятидесяти плюсов в сумме за обе статьи прекрасно это подчеркивает.
Отличный заголовок. Ну а как назвать статью о штуке которая не приносит ничего нового, не решает большинство существующих проблем, добавляет новых, увеличивает сложность системы и трудозатраты? Просто ещё один способ деплоя.
Сомнительный/неоднозначный плюс.
Во-первых мы точно также можем не делать это в CIOps.
Во-вторых замена непосредственного доступа на апосредованный на мой взгляд не сильно поднимает безопасность.
Хорошо. А что в этом подходе специфично для GitOps?
Полностью с этим согласен.
Жаль, что вы фокусируетесь на моментах, которые вам кажутся спорными и отказываетесь видеть общую картину. Я сталкивался с многими странными решениями в своей практике, и к любой вещи подхожу на основе закона Мерфи: если что-то может быть сделано не так, это будет сделано не так. Это принцип, с позиции которого я писал и эту статью. Для меня неожиданно что этот подход вызвал у вас столько недоумения, потому что я считаю, что любой специалист с достаточным опытом рано или поздно приходит к этой позиции.
Развивайте системное мышление, повышайте уровень технической грамотности, будьте позитивным и уважительным и вас определённо ждёт успех в будущем.
Спасибо!
Интересно будет на это взглянуть.
Безусловно. Но это outside of gitops scope.
В этом подходе источник истины распространяется на хранилище и его содержимое в том числе. Содержимое хранилищ может быть изменено, эти изменения могут быть не зарегистрированы (и не отображены в гит) но напрямую повлиять на функционал приложения. Это нужно по крайней мере учитывать.
Я бы назвал git в данном случае не single а main source of truth.
Тоесть хорошенько поскриптить?
Если говорить строго, GitOps принципиально отказывается решать вопрос переноса версий ПО между окружениями. Я писал об этом в статье. Данный вопрос важный и этот тред прекрасно иллюстрирует мою мысль - когда какой-то вопрос не описан, каждый решает его сам при помощи собственных костылей и велосипедов.
Мерж кода - один из способов решения этого вопроса.
Другие способы связаны с активным скриптописанием. Тоесть stop scripting and start shipping не получается.
Можете рассказать как с вашей точки зрения этот вопрос решить правильно?
С удовольствием бы это сделал. Вижу, у нас есть о чем поговорить. Но, к сожалению, не попадаю на будущий девопсконф.
Обсуждение я замыкаю на уровне деплоя приложения потому что гитопс замыкается на уровне деплоя приложения. Тоесть это не continuous delivery (определение понятий есть в первjй части статьи), а просто способ организации деплоя.
разработать удобную и масштабируемую CI шаблонизацию
Разработать удобную и масштабируемую CI шаблонизацию придётся в любом случае. В случае гитопс вам придётся написать скрипт апдейта инфраструктурного репозитория. И потенциально его написать не проще чем скрипт деплоя через тот же хелм.
проработать удобные нотификации от CI систем
Нотификации как правило встроены в CI систему. И их возможности больше и шире чем у того же Flux Notification controller. Их настройка проще.
позаботиться о том, чтобы из енва и приложения можно было бы определить из какого билда оно прилетело (тут благо почти все CI системы это уже умеют в аннотации проставлять, но мало ли)
Да. Причем за счет стандартных переменных пайплайна CI это сделать проще чем в gitops(который этот вопрос тоже никак по умолчанию не решает - я писал об этом в статье). Я кстати говорю про это в этом докладе https://youtu.be/1uhfChFSktQ
при каких-то изменениях CI скриптов проходиться по n репозиториев приложений (мое любимое, даже с максимальной шаблонизацией CI шаблонов и автоматизацией массовых git апдейтов это всегда весело)
Во-первых в случае GitOps стоит ровно такая же проблема, потому что вам точно также нужно писать CI-скрипты для обвязки.
Во-вторых CI системы умеют нативно в централизованный CI. Посмотрите инклюд Gitlab CI из централизованного GIT репозитория или build configuration template в teamcity.
продумать и решить вопрос привязки енва к вашему git flow
Этот пункт, как я понимаю, обратен второму пункту? Посмотрите пожалуйста место про трекинг окружений в гитлаб в моей статье.
решать вопрос падающих helm upgrade на этапе деплоя (retries, timeouts, etc)
helm upgrade --atomic --timeout 600 ?
Основная мысль здесь была в том, что откат нужно хорошо спроектировать. Следование пути гитопс не гарантирует возможность откатиться. Возможно я это чуточку многословно изложил, с избыточным количеством примеров, но мысль именно такая.
Почему в CI систему нельзя класть пользователя с доступом в кластер?
Во-первых хранилище секретов это один из важнейших функционалов CI систем. Мы можем достаточно гибко заводить секреты, раздавать на них права и защищать от кражи.
Во-вторых есть множество способов интеграции CI систем с kubernetes. От авторотирующихся токенов в специальных модулях до установки раннера в кластер и использования сервисаккаунтов (схема очень близкая к контроллерам flux).
Но моя основная мысль здесь - к безопасности нужно подходить осмысленно. Гитопс утвержданием что он безопасен по умолчанию вводит в заблуждение.
Тема широкая, согласен, но она фундаментальная. Это та вещь, которая must have. И обойти её было бы по крайней мере не правильно.
В гитопс есть понятие Git as the single source of truth. Мне было интересно как сделать управление секретами, чтобы следовать этой идее.
Кстати как вы относитесь к идее Git as the single source of truth? Считаете ли вы её важной для гитопс?
Это опять же не позволит сделать stage propagation через merge.
Почему я настаиваю на мерже изменений для доставки изменений по окружениям? Если у нас окружения описаны отдельными репозиториями или папками в гите, и конфигурацию там мы изменяем вручную, либо при помощи каких-то скриптов, то это потенциально приводит нас к ситуации когда накапливается environment drift.
Я правильно понимаю, что этот комментарий скорее в поддержку моей мысли?
это очевидно
речь идёт о случае когда у нас много микросервисов и values для них хранятся в едином месте
существование инфра репозитория - фундаментальное требование гитопс
Есть такой принцип программирования - KISS (keep it simple, stupud).
Много репозиториев это не плохо при условии что это хорошо спроектировано. Согласно моему опыту, в отдельные репозитории нужно выносить только явно используемые совместно вещи. Если вы просто вынесете в отдельный репозиторий настройки всех приложений, то возникнет просто разрыв между приложением и его конфигурацией, который будет не очевиден и который потребуется покрыть документацией. Если вы добавите к этому репозиторий глобальных настроек приложенй, то просто будете просто теряться между репозиториями - в какой из них положить тот или иной конфигурационный параметр.
В качестве резюме - если создание отдельного репозитория сможет сократить сложность вашей системы и/или ваши трудозатраты, - во всех остальных случаях лучше этого избегать.
Можем пойти от противного. Что по-вашему дал нам гитопс?
Судя по содержанию коментариев, вы не прочитали мои статьи. Взять хотябы это замечение что инфраструктурные репозитории мержить нельзя.
Меж тем в них я пытался дать системную картинку. Описать предпосылки -> обещания -> практическую реализацию -> анализ обещаний через практическую реализацию -> выводы. Причем снабдил это множеством ссылок на теорию и документацию потому что практика без теории слепа.
Вы же прошли статью по диагонали, выбрали несколько моментов, которые не понравились и пытаетесь их обсуждать вне контекста. Как в той притче когда человек нашел хвост слона и утверждал что слон это верёвка.