Ты путаешь методологию (GitOps) и инструмент (fluxcd). GitOps это подход при котором у тебя конфигурация хранится в git, и любой инструмент который используется для "доставки" конфигурации должен использовать git как источник. Всё.
Нет. Это как раз только начало. Моя статья - сборник кейсов, в которых можно применить GitOps и сборник проблем, которые при этом могут случиться. Я отдельно указал это в дисклеймере к статьям. Вы считаете что делая GitOps вы не столкнётесь с ручными изменениями на инфраструктуре? Или что ими можно пренебречь?
Ровно то же самое я описал в своей статье в главе Проблема нескольких окружений . Только объяснения разницы я делал на основе разницы в инстансах баз данных, а не ингрессах, дал ссылки на источники на gitops.tech и таки дал рецепты решения этой проблемы.
Может вам стоит перечитать эту главу и обсудим её предметно?
By applying GitOps best practices, there is a pre-defined, ultimate source of truth for both your infrastructure and application code that lets your development teams increase velocity and improve system reliability.
Фраза ultimate source of truth for both your infrastructure and application code переводится как окончательный источник правды как для вашей инфраструктуры, так и для кода приложения. Контекст этой фразы можете найти здесь https://www.weave.works/technologies/gitops/ .
НО!!! 3-й фактор из 12-factor app говорит нам: сохраняйте конфигурацию в среде выполнения. Поскольку среда выполнения управляется как раз "манифестами" (кукбуками/плейбуками) системы управления конфигурацией, методология 12 factor app явно говорит нам, что секреты являются частью манифестов.
Всё-таки я не понимаю разницу. Может сможете объяснить это на конкретном примере? Как правильно доставлять изменения в случае multistage environments в рамках gitops. Или дадите ссылку на документацию, где описана принципиальная разница в процессах, на которую вы намекаете?
У нас нет разницы apache - nginx. У нас flux в обоих окружениях. А также некоторый набор наших приложений и инфраструктурных сервисов, который очень похож (если не тождественен) от окружения к окружению.
By applying GitOps best practices, there is a pre-defined, ultimate source of truth for both your infrastructure and application code that lets your development teams increase velocity and improve system reliability.
Это про "сделать такой подход, чтобы проблема стала невозможна".
На самом деле ручные операции и configuration drift - давняя проблема подхода IaC.
Chef и Puppet это в какой-то степени решали за счет reconciliation loop, но там были фундаментальные проблемы с выделенными железными персистентными серверами.
Сейчас же у нас immutable infrastructure, и stateless. И за счет более строгих подходов можно нивелировать проблему. Но на мой взгляд, GitOps этого не делает даже близко.
Пожалуйста, не вырывайте мои фразы из контекста. Вот полный текст:
А что у нас GitOps говорит по поводу управления окружениями? А GitOps говорит: «А давайте у вас будет всего одно окружение, и вы не будете маяться дурью». Я, например, не уверен, у многих ли команд только одно окружение. GitOps-идеологи, похоже, тоже в этом не уверены. Поэтому они говорят: «Ну если вам очень нужен multistage, то сделайте это где-нибудь outside of the GitOps scope. В рамках вашей CI/CD-системы например».
На мой взгляд это достаточно близкий по смыслу перевод документации(с авторскими комментариями).
И здесь была мысль про то, что концепция GitOps игнорирует multistage, хотя это является важной частью эксплуатации приложений.
Это заявка если не на снятие, то на уменьшение bus factor.
Что до (в том числе) отсутствия толерантности к ручным операциям, я изложил своё мнение в этих абзацах:
Одним из ключевых принципов DevOps является постулат о том, что нет плохих исполнителей, есть плохие процессы. Отсюда вытекает blameless culture и понимание того, что нужно организовать процессы так, чтобы проблема стала невозможна.
Но из-за ограниченности концепции GitOps она имеет слишком много пробелов и потенциальных проблем, слишком много вещей, которые нужно делать «out of GitOps scope». Всё это приводит к непониманию, как правильно организовать процессы, и, соответственно, к костылям и велосипедам со всеми вытекающими.
Нет. Это как раз только начало. Моя статья - сборник кейсов, в которых можно применить GitOps и сборник проблем, которые при этом могут случиться. Я отдельно указал это в дисклеймере к статьям.
Вы считаете что делая GitOps вы не столкнётесь с ручными изменениями на инфраструктуре? Или что ими можно пренебречь?
Я уже ответил на этот вопрос.
Ручные правки являются фундаментальной проблемой. Ты с ней сталкиваешься в том числе когда делаешь GitOps.
Являются ли ручные правки частью GitOps? - НЕТ
Должен ли GitOps с ними бороться? - ДА
Борется ли GitOps с ручными правками? - ПЫТАЕТСЯ
Как у него это получается? - ПОСРЕДСТВЕННО
Так понятнее?
Ровно то же самое я описал в своей статье в главе Проблема нескольких окружений .
Только объяснения разницы я делал на основе разницы в инстансах баз данных, а не ингрессах, дал ссылки на источники на gitops.tech и таки дал рецепты решения этой проблемы.
Может вам стоит перечитать эту главу и обсудим её предметно?
Вообще-то в предыдущем ответе я привёл цитату
By applying GitOps best practices, there is a pre-defined, ultimate source of truth for both your infrastructure and application code that lets your development teams increase velocity and improve system reliability.
Фраза
ultimate source of truth for both your infrastructure and application code
переводится как
окончательный источник правды как для вашей инфраструктуры, так и для кода приложения.
Контекст этой фразы можете найти здесь https://www.weave.works/technologies/gitops/ .
НО!!! 3-й фактор из 12-factor app говорит нам: сохраняйте конфигурацию в среде выполнения. Поскольку среда выполнения управляется как раз "манифестами" (кукбуками/плейбуками) системы управления конфигурацией, методология 12 factor app явно говорит нам, что секреты являются частью манифестов.
Приведу аналогию: амортизаторы это часть автомобиля? Значит ли что автомобиль без амортизаторов плохой?
Всё-таки я не понимаю разницу. Может сможете объяснить это на конкретном примере? Как правильно доставлять изменения в случае multistage environments в рамках gitops. Или дадите ссылку на документацию, где описана принципиальная разница в процессах, на которую вы намекаете?
Можете пояснить в чем противоречие? Для меня это не очевидно.
Именно эта аналогия мне и не понятна:
У нас нет разницы apache - nginx. У нас flux в обоих окружениях. А также некоторый набор наших приложений и инфраструктурных сервисов, который очень похож (если не тождественен) от окружения к окружению.
Каким образом её можно улучшить на ваш взгляд?
Там чуть ниже цитата. Вот эта:
By applying GitOps best practices, there is a pre-defined, ultimate source of truth for both your infrastructure and application code that lets your development teams increase velocity and improve system reliability.
Не нашел в пункте
https://www.gitops.tech/#how-does-gitops-handle-dev-to-prod-propagation
упоминания про правило "один репозиторий = одно окружение". Не нашел там вообще упоминаний про репозитории. Только про окружения.
Я не туда смотрю?
Это про "сделать такой подход, чтобы проблема стала невозможна".
На самом деле ручные операции и configuration drift - давняя проблема подхода IaC.
Chef и Puppet это в какой-то степени решали за счет reconciliation loop, но там были фундаментальные проблемы с выделенными железными персистентными серверами.
Сейчас же у нас immutable infrastructure, и stateless. И за счет более строгих подходов можно нивелировать проблему. Но на мой взгляд, GitOps этого не делает даже близко.
Я рассматриваю подход, на базе тулинга, который сделали его авторы. Вы считаете такой способ не достаточно хорошим?
Выше я привёл цитаты из официального источника и мой вывод, который я сделал на основе их интерпретации.
Если вы считаете, что моё понимание неверное, можете изложить своё понимание, подкрепив его источниками?
Пожалуйста, не вырывайте мои фразы из контекста. Вот полный текст:
А что у нас GitOps говорит по поводу управления окружениями? А GitOps говорит: «А давайте у вас будет всего одно окружение, и вы не будете маяться дурью». Я, например, не уверен, у многих ли команд только одно окружение. GitOps-идеологи, похоже, тоже в этом не уверены. Поэтому они говорят: «Ну если вам очень нужен multistage, то сделайте это где-нибудь outside of the GitOps scope. В рамках вашей CI/CD-системы например».
На мой взгляд это достаточно близкий по смыслу перевод документации(с авторскими комментариями).
И здесь была мысль про то, что концепция GitOps игнорирует multistage, хотя это является важной частью эксплуатации приложений.
Как говорят мудрецы, в споре рождаются истина. Всегда готов пояснить моменты, показавшиеся спорными.
Гитопс декларирует
https://www.gitops.tech/#self-documenting-deployments
https://www.gitops.tech/#shared-knowledge-in-teams
Это заявка если не на снятие, то на уменьшение bus factor.
Что до (в том числе) отсутствия толерантности к ручным операциям, я изложил своё мнение в этих абзацах:
Одним из ключевых принципов DevOps является постулат о том, что нет плохих исполнителей, есть плохие процессы. Отсюда вытекает blameless culture и понимание того, что нужно организовать процессы так, чтобы проблема стала невозможна.
Но из-за ограниченности концепции GitOps она имеет слишком много пробелов и потенциальных проблем, слишком много вещей, которые нужно делать «out of GitOps scope». Всё это приводит к непониманию, как правильно организовать процессы, и, соответственно, к костылям и велосипедам со всеми вытекающими.
Какие именно аргументы не работают для gitlab?
Это иллюстрация того, что откаты в GitOps нужно хорошо проектировать. И рекомендации от авторов flux часто достаточно плохие.
Вы считаете по-другому?
Потому что гитопс прямо обещает простой и быстрый откат: https://www.gitops.tech/#easy-and-fast-error-recovery
Я просто обозначил что откат возможен только если ты позаботишься о нём в том числе outside of gitops scope. Считаете по-другому?