1) Выглядит так будто у вас очень маленький проект, для которого хватает кастомайза, либо ваши кастомайзы должны быть адом копипаста. Вы пересобираете имиджи для каждого окружения? Вы настолько уверены в повторяемости сборок? Мне интересно какой у вас стек и какое медианное количество собственных строк кода на проект. SBOM вы составляли?
2) Закономерно. Хелм экстремально популярен. Все основные проекты развивают свои хелм чарты. Даже если основа деплоя проекта - оператор, обвязку к нему тоже как правило заворачивают в чарт.
4) Тоесть внедрение гитопс заставило вас принести в инфру ещё одну систему алертинга?
5) Интересно сколько команд в вашей организации, сколько у них проектов и как часто они релизятся. По моим ощущениям, после двадцати проектов с недельным релизным циклом разбираться в инфраструктурных гитах становится уже достаточно сложно.
Перезапуск стейджей - это все равно ручное действие.
Вы не считаете git revert ручным действием? У вас он как-то автоматизирован?
Как, например, будет раскатываться релиз, если кто-то руками поменял configMap в приложении?
Мне несколько раз в рамках обсуждения статей писали коментарии вида:
Ручные операции в кластере это ваши проблемы, а не проблемы гитопс. Просто отберите у всех доступ в кластер. У вас же гитопс. Он безопасен и не требует раздавать права.
Вы с этим не согласны?
Или релиз в состоянии Failed? Тут GitOps кончается и инженер идет в куб править руками
Нене. У нас же гитопс. Git revert и всё в порядке. Это вот прям на сайте gitops.tech на главной странице в первых строках написано. Вы не согласны что гитопс решает эту проблему?
GitOps добавляет поверх этого еще автоматический процесс синхронизации с целевой средой.
Парадигма "синхронизации конфигурации" стара как мир. Впервые идея декларативного описания инфраструктуры и автоматическая синхронизация конфигурации с ним была реализована в cfengine (первая версия 1993 год).
Если говорить о развитии парадигм, то сейчас главенствует immutable infrastructure. Полностью автоматизированные пайплайны доставки её необходимый аттрибут. Я описывал это в первой части статьи.
Возможно вы имеете в виду разницу между pull и push подходом? Pull-подход был основным в SCM второго поколения - puppet и chef. SCM-системы третьего поколения (ansible, salt,terraform) от него отошли. Как думаете почему? (ответ - pull подход очень ресурсозатратен и не может до конца предотвратить configuration drift)
Кроме того гитопс всего лишь рекомендует использовать pull. С push-подходом он тоже ок.
Для меня вообще грань эта едва уловима, эти понятия схожи.
Ну так можете объяснить эту грань? Мы ведь говорим про IT. Строгая теоретическая база её фундаментальное свойство. Вот вы явно адепт или апологет гитопс. Чувствуется что вы любите эту концепцию. Что мне нужно чтобы делать гитопс?
Покачто вы описываете идеи, самая свежая из которых появилась не менее деясти лет назад. Самое оригинальное из того что вы сказали это превращение давно и хорошо известной хорошей практики держать IaC в гите в обязательное требование. Этого достаточно?
Вот у меня например дженкинс и пайплайны как код. У меня дженкинсфайл, который билдит имидж, sed'ит его в шаблон ямлика и аплаит ямлик в куб. Всё это лежит в гите и триггерится по пушу в гит. У меня гитопс?
Ну я тоже потерялся. Тред начинался с секретов.
Не совсем. Тред начинался с обсуждения секретов в рамках одной вполне определённой идеи.
1) А как вы генерите то что нужно запушить? Как решаете вопрос stage propagation? У вас всего одно окружение?
2) Вы не используете флюкс с хелмом?
3) Как вы определяете на какой комит откатиться? У вас репозиторий на каждое окружение каждого приложения? Как вы определяете что конфигурация в конкретном комите рабочая?
4) Вы не используете нотификации о прохождении пайплайнов? А если билд или пуш сфэйлится?
5) Вам хватает git history? Как вы определяете какая конфигурация выкатилась, а какая упала например?
С CI Ops мне много приходилось делать руками в кластере, чтобы чинить состояние.
А что помешало сделать это через перезапуск стейджей пайплайнов? У вас монолитные пайплайны?
Не совсем. Перед применением хелм делает плоский "релиз" и записывает его в release backend. По умолчанию это secret в неймспейсе релиза. Тоесть мы в любое время можем посмотреть ямлики, которые были применены в кластер. Причем хелм обычно хранит несколько последних релизов - мы можем делать откат например.
Теперь вопрос - у нас в секрете в кластере лежит эталонный ямлик текущего релиза. Какие проблемы в рамках общего reconciliation loop следить за дрифтом актуальной конфигурации?
Прошу прощения если мой комментарий вас обидел. Давайте поясню.
Не стоит путать концепцию CI/CD со сборкой и деплоем. Это гораздо более сложная концепция, в которой делается акцент в первую очередь на соблюдении качества кода и стабильности приложения.
Например Continuous delivery не предполагает деплоя куда бы то нибыло. Она предполагает что наш код в мастере настолько качественный, что мы можем при желании задеплоить его в прод в любое время.
Continuous deployment предполагает что всё что приходит в наш мастер, деплоится на прод автоматически. И это, как вы наверное уже понимаете, невозможно без Continuous delivery.
Тоесть вся схема полностью представляет собой матрёшку Continuous integration -> Continuous delivery -> Continuous deployment, каждая часть которой включает в себя предыдущую.
Чтобы говорить что GitOps это Continuous deployment - концепция, нужно пересмотреть определение Continuous deployment. Тоесть поставить знак тождества между Continuous deployment и автоматическим деплоем. На мой взгляд, практических причин это делать нет. Есть только маркетинговые.
Они позволяют создать в компании условия, при которых технические границы повторяют границы административные, разграничивая ответственность между отдельными командами и даже отдельными людьми.
Вы ведь понимаете что это утверждение идёт в разрез с культурой DevOps, которая как раз и создана чтобы рушить барьеры?
Команда эксплуатации и инфраструктуры, которая отвечает за Kubernetes, может спать спокойно не опасаясь, что кто то скопировав из системы автоматизации токен начнет "только на пять минут, очень надо" производить миграцию базы данных, менять конфигурацию системы и так далее.
Тут идёт явная подмена понятий. Почему вы считаете что записать токен в CI-систему равно отдать его программисту? Управление секретами - одна из важных функций CI-систем. При желании можно достаточно тонко выдавать права программистам на ключи, скрывать их и защищать от кражи. И что вас вообще заставляет записывать токены в CI-систему? Есть куча других способов интеграции CI-системы и kubernetes.
И почему вы считаете, что разработчик модет запустить миграцию базы данных только вручную? Почему он не может сделать это в коде? Почему вообще вы считаете что опосредованный доступ к инфраструктуре (через комит кода в гит) безопаснее непосредственного?
Создается впечатление, что вы пытаетесь понять что такое GitOps, но сами для себя не можете это сделать.
Вышла вторая часть и в ней есть вывод что такое гитопс по моему мнению.
Резюмирую для вас: GitOps не принёс ничего нового. Всё было изобретено до него. Можно подумать что GitOps сделал обязательным требование хранить манифесты IaC в гите (идею Git as the single source of truth вы ведь сами только что обесценили - так что просто забудем про неё), но они утверждают что это не верно:
No. Declarative Infrastructure as Code plays a huge role for implementing GitOps, but it’s not just that. GitOps takes the whole ecosystem and tooling around Git and applies it to infrastructure. (Здесь всё понятно? Перевод нужен?)
Тоесть под названием гитопс вам фактически продают тулинг. Просто ещё один способ что-то задеплоить.
Если кто-то считает, что он хорошо подходит на его процессы - это нормально. Но ни о каком прорыве/серебряной пуле речи не идёт.
никаких ручных действий с инфраструктурой, любое изменение - это git commit
Эта проблема известна ещё с эпохи "синхронизации конфигурации". Я описывал это в первой статье в разделе про configuration drift и сервера-снежинки. И в процессе развития темы статьи дал понять что GitOps не толерантен к ручным изменениям (по крайней мере не более толерантен чем обычная SCM с pull-подходом и reconcilliation loop). Он не ставит во главу угла борьбу с ручными изменениями. А ручные изменения обязательно будут, просто потому что они могут быть.
И если инфраструктуру стереть в пепел, ее можно полностью восстановить исходя из состояния, которое зафиксировано на репозитории.
Принципы infrastructure-as-code:
#1 Systems can be Easily Reproduced
#2 Systems are Disposable
#3 Systems are Consistent
#4 Processes are Repeatable
#5 Design is Always Changing
Вы только что описали первый и четвёртый. Вот только эти принципы были сформулированы за добрый десяток лет до гитопс.
Чего здесь нет, так это про обязательное хранение кода IaC в гите. Но хранение кода в гите известна как хорошая практика уже более десятка лет. Посмотрите 6-й пункт теста Лимончелли.
Так что такое GitOps? Что мы сейчас с вами обсуждаем? Это просто требование хранить манифесты IaC в гите?
По ходу тут явное передёргивание. Действие "положить ключ доступа к кластеру kubernetes в CI систему" трактуется как "дать ключ разработчику". Это севершенно не верно. В CI системе мы можем при желании запретить доступ разработчика к этому ключу.
Единственный наверное кейс, в котором безопасность с GitOps увеличивается, это когда CI-систему и кубовые кластера эксплуатируют разные команды, и команде CI-щиков не хочется выдавать ключи доступа к кластерам. И то этот случай можно решить установкой раннера в кластере и использование сервисакаунта.
Ну плюс на раннере можно выполнить произвольный скрипт, а на контроллере флюкс только создание объекта в кубе, но это не особо существенное различие.
Я же привёл пример - поднять раннер ci системы в целевом кластере и использовать сервисаккаунт для доступа к нему. Эта схема повторяет модель безопасности контроллеров флюкс например.
Неймспейсы в кубе это с одной стороны группировка объектов, да. Но это не единственная и не самая важная функция.
Во-первых неймспейсы это сервисдискавери. Полное DNS имя подов и сервисов формируется на основе неймспейсов.
Во-вторых это безопасность. RBAC мы нарезаем в том числе в разрезе неймспейсов.
В-третьих неймспейсы это управление ресурсами. Квотами, числом подов и прочее.
В-четвёртых сетевые политики управляются также в разрезе неймспейсов.
Вот вы включили иерархические неймспейсы в кубе. Как стали работать эти четыре пункта? Доменные имена теперь с поддержкой вложенных неймспейсов? Квоты и сетевые политики как работают?
Про права вроде как написали. Интересно как именно это работает.
Я сужу по рынку недвижимости моего родного города. Я купил однушку четыре года назад за 2800. Сейчас она 3500. Двушка купленная пять лет назад - 1700. Недавно соседи продали свою такую же за 3000.
Условную квартиру можно сравнить с денежным депозитом, который приносит некоторый годовой прирост. Ну тоесть мы тратим на обслуживание условные 7.5% плюс годовая страховка жизни, но стоимость квартиры тоже растёт к примеру на 5 % в год. Не так?
Ну во-первых вижу здесь отсутствие автоматизации. Toil automation - one of five SRE pillars так сказать.
Во-вторых человеческий фактор. У инженера может "соскочить пальчик" и это может привести к непредсказуемым последствиям.
Дублирование работы опять же. Постановка тега на целевой репозиторий плюс прописывание его в инфраструктурном.
Тайные знания. Не ознакомленный со схемой инженер может не сообразить что нужно пойти в репу и поправить там файл.
В принципе, если у вас медленные процессы и вы редко релизитесь, это наверное допустимо.
Потому что культ который вы имеете в виду называется карго. И карго культ он не только про девопс.
Девопс это жэ не человек а культура. Статья тупо против автоматизации по ходу.
Выглядит кривовато КМК. Надеюсь такую схему вы сделали по каким-то реальным практическим соображениям, а не просто потому что захотелось гитопс.
А вот это вот действие - поменять тег в стейт репе, оно ручное?
1) Выглядит так будто у вас очень маленький проект, для которого хватает кастомайза, либо ваши кастомайзы должны быть адом копипаста. Вы пересобираете имиджи для каждого окружения? Вы настолько уверены в повторяемости сборок? Мне интересно какой у вас стек и какое медианное количество собственных строк кода на проект. SBOM вы составляли?
2) Закономерно. Хелм экстремально популярен. Все основные проекты развивают свои хелм чарты. Даже если основа деплоя проекта - оператор, обвязку к нему тоже как правило заворачивают в чарт.
4) Тоесть внедрение гитопс заставило вас принести в инфру ещё одну систему алертинга?
5) Интересно сколько команд в вашей организации, сколько у них проектов и как часто они релизятся. По моим ощущениям, после двадцати проектов с недельным релизным циклом разбираться в инфраструктурных гитах становится уже достаточно сложно.
Вы не считаете git revert ручным действием? У вас он как-то автоматизирован?
Мне несколько раз в рамках обсуждения статей писали коментарии вида:
Ручные операции в кластере это ваши проблемы, а не проблемы гитопс. Просто отберите у всех доступ в кластер. У вас же гитопс. Он безопасен и не требует раздавать права.
Вы с этим не согласны?
Нене. У нас же гитопс. Git revert и всё в порядке. Это вот прям на сайте gitops.tech на главной странице в первых строках написано. Вы не согласны что гитопс решает эту проблему?
Парадигма "синхронизации конфигурации" стара как мир. Впервые идея декларативного описания инфраструктуры и автоматическая синхронизация конфигурации с ним была реализована в cfengine (первая версия 1993 год).
Если говорить о развитии парадигм, то сейчас главенствует immutable infrastructure. Полностью автоматизированные пайплайны доставки её необходимый аттрибут. Я описывал это в первой части статьи.
Возможно вы имеете в виду разницу между pull и push подходом? Pull-подход был основным в SCM второго поколения - puppet и chef. SCM-системы третьего поколения (ansible, salt,terraform) от него отошли. Как думаете почему? (ответ - pull подход очень ресурсозатратен и не может до конца предотвратить configuration drift)
Кроме того гитопс всего лишь рекомендует использовать pull. С push-подходом он тоже ок.
Ну так можете объяснить эту грань? Мы ведь говорим про IT. Строгая теоретическая база её фундаментальное свойство. Вот вы явно адепт или апологет гитопс. Чувствуется что вы любите эту концепцию. Что мне нужно чтобы делать гитопс?
Покачто вы описываете идеи, самая свежая из которых появилась не менее деясти лет назад. Самое оригинальное из того что вы сказали это превращение давно и хорошо известной хорошей практики держать IaC в гите в обязательное требование. Этого достаточно?
Вот у меня например дженкинс и пайплайны как код. У меня дженкинсфайл, который билдит имидж, sed'ит его в шаблон ямлика и аплаит ямлик в куб. Всё это лежит в гите и триггерится по пушу в гит. У меня гитопс?
Не совсем. Тред начинался с обсуждения секретов в рамках одной вполне определённой идеи.
1) А как вы генерите то что нужно запушить? Как решаете вопрос stage propagation? У вас всего одно окружение?
2) Вы не используете флюкс с хелмом?
3) Как вы определяете на какой комит откатиться? У вас репозиторий на каждое окружение каждого приложения? Как вы определяете что конфигурация в конкретном комите рабочая?
4) Вы не используете нотификации о прохождении пайплайнов? А если билд или пуш сфэйлится?
5) Вам хватает git history? Как вы определяете какая конфигурация выкатилась, а какая упала например?
А что помешало сделать это через перезапуск стейджей пайплайнов? У вас монолитные пайплайны?
Не совсем. Перед применением хелм делает плоский "релиз" и записывает его в release backend. По умолчанию это secret в неймспейсе релиза. Тоесть мы в любое время можем посмотреть ямлики, которые были применены в кластер. Причем хелм обычно хранит несколько последних релизов - мы можем делать откат например.
Теперь вопрос - у нас в секрете в кластере лежит эталонный ямлик текущего релиза. Какие проблемы в рамках общего reconciliation loop следить за дрифтом актуальной конфигурации?
Прошу прощения если мой комментарий вас обидел. Давайте поясню.
Не стоит путать концепцию CI/CD со сборкой и деплоем. Это гораздо более сложная концепция, в которой делается акцент в первую очередь на соблюдении качества кода и стабильности приложения.
Например Continuous delivery не предполагает деплоя куда бы то нибыло. Она предполагает что наш код в мастере настолько качественный, что мы можем при желании задеплоить его в прод в любое время.
Continuous deployment предполагает что всё что приходит в наш мастер, деплоится на прод автоматически. И это, как вы наверное уже понимаете, невозможно без Continuous delivery.
Тоесть вся схема полностью представляет собой матрёшку Continuous integration -> Continuous delivery -> Continuous deployment, каждая часть которой включает в себя предыдущую.
Чтобы говорить что GitOps это Continuous deployment - концепция, нужно пересмотреть определение Continuous deployment. Тоесть поставить знак тождества между Continuous deployment и автоматическим деплоем. На мой взгляд, практических причин это делать нет. Есть только маркетинговые.
Вы ведь понимаете что это утверждение идёт в разрез с культурой DevOps, которая как раз и создана чтобы рушить барьеры?
Тут идёт явная подмена понятий. Почему вы считаете что записать токен в CI-систему равно отдать его программисту? Управление секретами - одна из важных функций CI-систем. При желании можно достаточно тонко выдавать права программистам на ключи, скрывать их и защищать от кражи. И что вас вообще заставляет записывать токены в CI-систему? Есть куча других способов интеграции CI-системы и kubernetes.
И почему вы считаете, что разработчик модет запустить миграцию базы данных только вручную? Почему он не может сделать это в коде? Почему вообще вы считаете что опосредованный доступ к инфраструктуре (через комит кода в гит) безопаснее непосредственного?
Вышла вторая часть и в ней есть вывод что такое гитопс по моему мнению.
https://habr.com/ru/company/gazprombank/blog/717098/
Резюмирую для вас: GitOps не принёс ничего нового. Всё было изобретено до него. Можно подумать что GitOps сделал обязательным требование хранить манифесты IaC в гите (идею Git as the single source of truth вы ведь сами только что обесценили - так что просто забудем про неё), но они утверждают что это не верно:
https://www.gitops.tech/#is-gitops-just-versioned-infrastructure-as-code
Is GitOps just versioned Infrastructure as Code?
No. Declarative Infrastructure as Code plays a huge role for implementing GitOps, but it’s not just that. GitOps takes the whole ecosystem and tooling around Git and applies it to infrastructure. (Здесь всё понятно? Перевод нужен?)
Тоесть под названием гитопс вам фактически продают тулинг. Просто ещё один способ что-то задеплоить.
Если кто-то считает, что он хорошо подходит на его процессы - это нормально. Но ни о каком прорыве/серебряной пуле речи не идёт.
Ну давайте по порядку
Эта проблема известна ещё с эпохи "синхронизации конфигурации". Я описывал это в первой статье в разделе про configuration drift и сервера-снежинки. И в процессе развития темы статьи дал понять что GitOps не толерантен к ручным изменениям (по крайней мере не более толерантен чем обычная SCM с pull-подходом и reconcilliation loop). Он не ставит во главу угла борьбу с ручными изменениями. А ручные изменения обязательно будут, просто потому что они могут быть.
Принципы infrastructure-as-code:
#1 Systems can be Easily Reproduced
#2 Systems are Disposable
#3 Systems are Consistent
#4 Processes are Repeatable
#5 Design is Always Changing
Вы только что описали первый и четвёртый. Вот только эти принципы были сформулированы за добрый десяток лет до гитопс.
Чего здесь нет, так это про обязательное хранение кода IaC в гите. Но хранение кода в гите известна как хорошая практика уже более десятка лет. Посмотрите 6-й пункт теста Лимончелли.
Так что такое GitOps? Что мы сейчас с вами обсуждаем? Это просто требование хранить манифесты IaC в гите?
А можете пояснить почему стало проще? Я описал свои претензии к гитопс в статье. В кратце это
Количество скриптов CI не уменьшается, добавяются новые инфрастуктурные сервисы и доступы, увеличивается сложность инфрыструктуры и пайплайна.
Я отразил это в чеклистах.
Здесь я стриггерился на этот пункт
https://www.gitops.tech/#easy-and-fast-error-recovery
Он выглядит так будто "git revert всё что вам нужно". Это явная брехня.
По ходу тут явное передёргивание. Действие "положить ключ доступа к кластеру kubernetes в CI систему" трактуется как "дать ключ разработчику". Это севершенно не верно. В CI системе мы можем при желании запретить доступ разработчика к этому ключу.
Единственный наверное кейс, в котором безопасность с GitOps увеличивается, это когда CI-систему и кубовые кластера эксплуатируют разные команды, и команде CI-щиков не хочется выдавать ключи доступа к кластерам. И то этот случай можно решить установкой раннера в кластере и использование сервисакаунта.
Ну плюс на раннере можно выполнить произвольный скрипт, а на контроллере флюкс только создание объекта в кубе, но это не особо существенное различие.
Я же привёл пример - поднять раннер ci системы в целевом кластере и использовать сервисаккаунт для доступа к нему. Эта схема повторяет модель безопасности контроллеров флюкс например.
Неймспейсы в кубе это с одной стороны группировка объектов, да. Но это не единственная и не самая важная функция.
Во-первых неймспейсы это сервисдискавери. Полное DNS имя подов и сервисов формируется на основе неймспейсов.
Во-вторых это безопасность. RBAC мы нарезаем в том числе в разрезе неймспейсов.
В-третьих неймспейсы это управление ресурсами. Квотами, числом подов и прочее.
В-четвёртых сетевые политики управляются также в разрезе неймспейсов.
Вот вы включили иерархические неймспейсы в кубе. Как стали работать эти четыре пункта? Доменные имена теперь с поддержкой вложенных неймспейсов? Квоты и сетевые политики как работают?
Про права вроде как написали. Интересно как именно это работает.
Однушка - монолит. Двушка - хрущёвка в плохом состоянии. Потребовался ремонт.
Я сужу по рынку недвижимости моего родного города. Я купил однушку четыре года назад за 2800. Сейчас она 3500. Двушка купленная пять лет назад - 1700. Недавно соседи продали свою такую же за 3000.
Условную квартиру можно сравнить с денежным депозитом, который приносит некоторый годовой прирост. Ну тоесть мы тратим на обслуживание условные 7.5% плюс годовая страховка жизни, но стоимость квартиры тоже растёт к примеру на 5 % в год. Не так?