Comments 140
Допустим, мы выкатили изменения в develop-окружение, протестировали всё и хотим выкатиться в stage. Каким образом мы можем это сделать? У нас — GitOps, поэтому мы, очевидно, хотим по максимуму использовать git-подход, то есть выполнить merge кода из dev в stage.
Почему очевидно? Мне в какой-то момент стало неочевидно. Тогда я предложил команде перестать притворяться, что develop достаточно стабилен, чтобы целиком раскатывать его на stage и затем на prod. Он почти никогда не стабилен: туда постоянно выкатывают что-нибудь свежее и там всегда висит что-нибудь недоделанное, а иной раз даже отложенное в долгий ящик. Кто-то предлагает обмазывать всё нестабильное feature-тогглами, но тогда код становится месивом из тогглов.
Короче, мы собираем stage из тех же самых веток, из которых собирается develop, но только после их адресного тестирования в develop. Уже потом тестируем stage в целом и раскатываем его на prod. А develop живёт практически как форк - он никуда не вмёрживается (кроме бранчей для разрешения конфликтов, но это другая история; в любом случае develop никогда не попадает в prod).
Естественно, это компромисс со своими минусами. Но он вполне покрывает условия с ограниченным числом сред, ручным тестированием (ибо пробелы в автотестах) и зависимыми командами (мобильщикам нужен свежий бэк). Сейчас хотим избавляться от этих статических сред (кроме прода, естественно) в пользу эфемерных. Типа создал PR - сразу получил в нём ссылку на отдельное окружение для тестирования. Дальше по желанию либо сразу в прод, либо накопить изменения в stage и уже потом в prod.
Короче, для меня теперь под большим вопросом очевидность проталкивания всей среды по этапам стабильности. И, возвращаясь к теме топика, такой подход исключает попадание develop-конфигурации в prod. Вполне можно рассмотреть. Не исключено также, что я несу чушь и заразил команду каким-то неортодоксальным пониманием develop/stage/prod, но в целом это сработало, и мы больше не ломаем голову относительно стабильности целых сред.
На самом деле, здесь речь идёт немного о другом — об инфраструктурном репозитории. Код, который в нём лежит, — это не код программы, а код, описывающий её деплой. Вы же говорите об артефакте, который собираете из программного кода и этот вопрос "outside of GitOps scope".
Окей, сижу краснею насколько я не в теме был. Но даже так, что мешает и в инфраструктурном репозитории собирать каждую среду отдельными бранчами, а не промоутить целиком develop в stage и потом в prod? Тогда специфика одной среды не будет перетекать в другую.
Если говорить об общих принципах и распространённых "хороших практиках", то у нас есть методология 12-factor app, в которой первый фактор говорит, что должна быть одна кодовая база, отслеживаемая в системе контроля версий, — множество развёртываний (https://12factor.net/ru/codebase ). Когда у вас несколько веток, код в которых принципиально отличается друг от друга, то между ними накапливается drift, код разъезжается и вам приходится тратить дополнительные силы на поддержку этой разницы. В частности, за это ругают gitflow, в котором предполагается несколько отдельных долгоживущих веток под разные нужды.
Но вообще я давал ссылки в статье на стратегии организации инфраструктурных репозиториев от авторов flux. Там много примеров, где одна ветка и несколько папок на окружения. Это близко к стратегии ветка на окружение, и это, на мой взгляд плохая практика (исходя из вышеизложенных соображений).
Все верно. Вообще подход gitflow для IaS не очень подходит. Поэтому переменные окружения лежат в одном git, helm , роли , манифесты и все остальное в другом. Монорепозиториев почти нет. Но, что бы к этому всему прийти, надо пройти несколько кругов ада.
Насколько я понял, идея была в том чтобы разделить build и deploy пайплайны, а так же использовать git в качестве хранилища исходного кода и конфигураций со всей историей их изменения (CMDB уровня бомж).
В этом случае ответственность Dev команды ограничивается сборкой приложения в виде артефакта (допустим в виде docker image). Как и куда оно будет раскатано уже не их забота - этим занимается DevOps команда в отдельном репозитории (или репозиториях), где описывает инфраструктуру и правила обновления приложений в ней.
Вопрос с деплоем в несколько environments можно решить маршрутизацией билдов в разные release train. Реализация будет зависеть от конкретной технологии. Например, docker images можно помечать специфичными тегами, на основе которых будет приниматься решение в какое окружение деплоить конкретную сборку. Таким образом сложность выгоняется на уровень управления версиями, где тактики уже давно хорошо проработаны.
Секреты и конфигурации точно так же версионируются как и сборки приложений. Вероятно вам потребуется специфичное хранилище, позволяющее адресовать секреты не только по имени, но и номеру версии (как GCP Secret Manager). Имя и номер версии секрета вы можете хранить в git, как часть текущего описания environment, что обеспечит нужный уровень воспроизводимости, а сами значения извлекать (или генерировать) в момент деплоя.
Опять Вы путаете GitOps и Helm. Это никак не связанные вещи. Helm очень плохо подходит для GitOps.
А что хорошо подходит?
Можете пояснить свою мысль? Почему helm плохо подходит для GitOps?
Для GitOps хорошо подходят "плоские" манифесты. В идеале готовые к применению в кластер. Хелм же делает свою магию в процессе применения. Есть темплейты и вельюсы. Проблемы с этим Вы хорошо описали в первой части статьи
Не совсем. Перед применением хелм делает плоский "релиз" и записывает его в release backend. По умолчанию это secret в неймспейсе релиза. Тоесть мы в любое время можем посмотреть ямлики, которые были применены в кластер. Причем хелм обычно хранит несколько последних релизов - мы можем делать откат например.
Теперь вопрос - у нас в секрете в кластере лежит эталонный ямлик текущего релиза. Какие проблемы в рамках общего reconciliation loop следить за дрифтом актуальной конфигурации?
Как, например, будет раскатываться релиз, если кто-то руками поменял configMap в приложении?
Или релиз в состоянии Failed?
Тут GitOps кончается и инженер идет в куб править руками
Как, например, будет раскатываться релиз, если кто-то руками поменял configMap в приложении?
Мне несколько раз в рамках обсуждения статей писали коментарии вида:
Ручные операции в кластере это ваши проблемы, а не проблемы гитопс. Просто отберите у всех доступ в кластер. У вас же гитопс. Он безопасен и не требует раздавать права.
Вы с этим не согласны?
Или релиз в состоянии Failed?
Тут GitOps кончается и инженер идет в куб править руками
Нене. У нас же гитопс. Git revert и всё в порядке. Это вот прям на сайте gitops.tech на главной странице в первых строках написано. Вы не согласны что гитопс решает эту проблему?
Ладно, расскажу как у нас сделано
Есть репозитории с аддонами. Если там лежит вендорский софт, поставляемый в виде хелм чарта (например istio или cilium), то в папочке положены манифесты, сделанные посредством `helm template`. Если манифесты самописные, то kustomize.
Есть стейт репа, в которой через kustomize собираются аддонны ссылками на конкретный тег в репы аддонов.
И есть плоская, отрендеренная стейт репа, в которую автоматически коммитится выхлоп `kustomize buld` стейт репозитория. На эту репу смотрит ArgoCD, опять же не на ветку, а на тег.
Соответственно процесс выкатки выглядит так: Инженер коммитит новую версию аддона, ставит тег, меняет тег в стейт репе, новый тег синкается в арго. Если надо откатить, тег в арго меняется на предыдущий.
А вот это вот действие - поменять тег в стейт репе, оно ручное?
Да, это коммит в репу. Во кусок kustomization:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- git::https://gitlab.mydomain/k8s/certmanager.git/bases/?ref=v1.1.1Инженер сначала ставит тег v1.1.2 на репозитории Сертменеджера, потом коммитит в стейтрепу
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- git::https://gitlab.mydomain/k8s/certmanager.git/bases/?ref=v1.1.2Выглядит кривовато КМК. Надеюсь такую схему вы сделали по каким-то реальным практическим соображениям, а не просто потому что захотелось гитопс.
Почему кривовато? Какие Вы видите минусы?
Ну во-первых вижу здесь отсутствие автоматизации. Toil automation - one of five SRE pillars так сказать.
Во-вторых человеческий фактор. У инженера может "соскочить пальчик" и это может привести к непредсказуемым последствиям.
Дублирование работы опять же. Постановка тега на целевой репозиторий плюс прописывание его в инфраструктурном.
Тайные знания. Не ознакомленный со схемой инженер может не сообразить что нужно пойти в репу и поправить там файл.
В принципе, если у вас медленные процессы и вы редко релизитесь, это наверное допустимо.
Деплоимся несколько раз в день, все изменения происходят через гит с ревью коллег и через этапы тестирования. Это как раз исключает человеческую ошибку полностью. Коммит в 2 репы как раз защищает от просачивания непротестированного кода в кластера. Это все хорошо задокументировано в README и на вики. За вновь присоединившимися инженерами устанавливаются менторство и особый контроль.
Всё верно. Выглядит как хрестоматийный пример muda 2-го порядка. Если вы понимаете о чем я.
К сожалению, не понимаю.
Это термин из "бережливого производства". Собственно та база, которая помогает делать работу осмысленно, сделать качественный целенаправленный скачок от Ops к DevOps, не собирая известные грабли самостоятельно. Рекомендую ознакомиться с google sre book и project fenix. Там про это хорошо описано.
Как раз наоборот. Бережливое производство это отказаться от хелма и не плодить лишних сущностей. Качественный скачок возможен, когда инструменты подбираются в соответствии с потребностями, а не потому, что они популярны есть видимость, что все с популярными инструментами умеют обращаться. Переход от DevOps к SRE возможен, когда инженер думает о качестве, тестируемости и обслуживаемости кода, который он пишет, а не сидит и ввчитывается в кудри типа таких:
{{- if .Values.ingress.enabled -}}
{{- $fullName := include "tttt.fullname" . -}}
{{- $svcPort := .Values.service.port -}}
{{- if semverCompare ">=1.14-0" .Capabilities.KubeVersion.GitVersion -}}
apiVersion: networking.k8s.io/v1beta1
{{- else -}}
apiVersion: extensions/v1beta1
{{- end }}Обе ваших статьи на 50% состоят из попыток доказать, что GitOps не работает потому, что helm.
У нас гитопс прекрасно работает. десятки наших кластеров в разных окружениях и на разных площадках обслуживаются без проблем из единого репозитория.
Хм. А как с вашей точки зрения бережливое производство относится к замене kubectl apply в ci-системе под ограниченной учеткой на скрипт пуша в гит и три (или четыре?) оператора, каждый из которых требует своих учеток, сервисаккаунтов, дополнительной страницы мониторинга, нового канала уведомлений? И это без хелма.
Какое-то у вас превратное понимание бережливого производства. Или вы настолько любите гитопс что готовы свободно трактовать бережливое производство в его пользу?
Допустим, мы выкатили изменения в develop-окружение, протестировали всё и хотим выкатиться в stage. Каким образом мы можем это сделать? У нас — GitOps, поэтому мы, очевидно, хотим по максимуму использовать git-подход, то есть выполнить merge кода из dev в stage.
В GitOps не делают merge описания одного окружения в описание другого окружения потому что в этом нет смысла.
Пытаться мержить код описания dev окружения в код описания stage окружения - это как пытаться смержить код apache и код nginx.
А вот в пределах одного окружения - там да, можно использовать стандартный подход с ветками, допустим в дев окружении появляется новое приложение, сделали под новую конфигурацию ветку, PR, ревью, тесты, merge.
Не очень понимаю, почему мы не можем относиться к инфраструктурному коду так же как к программному. Можете пояснить свою мысль?
Ты можешь применять подход с merge к инфраструктурному/программному коду в том случае если инфраструктурный/программный код относится к одной инфраструктуре/программе. Я вроде тебе аналогию простую привёл " мержить код описания dev окружения в код описания stage окружения - это как пытаться смержить код apache и код nginx "
Именно эта аналогия мне и не понятна:
У нас нет разницы apache - nginx. У нас flux в обоих окружениях. А также некоторый набор наших приложений и инфраструктурных сервисов, который очень похож (если не тождественен) от окружения к окружению.
Похож, но не одинаков. Он и не должен быть одинаков, потому что это разные окружения, они используют разную конфигурацию, и хранение этой конфигурации в гит - это и есть гитопс.
А когда у тебя в голове всякие мержи dev в production и гитфлоу - это про код одного приложения, и код в ветке разработки в момент сливания полностью и без изменений переносится в код основной ветки.
То что у тебя и там и там гит используется, не значит, что у тебя должны быть одинаковые процессы.
Всё-таки я не понимаю разницу. Может сможете объяснить это на конкретном примере? Как правильно доставлять изменения в случае multistage environments в рамках gitops. Или дадите ссылку на документацию, где описана принципиальная разница в процессах, на которую вы намекаете?
Может сможете объяснить это на конкретном примере?
Нельзя мёржить такой текст
ingress:
hosts:
- stage.example.comс таким
ingress:
hosts:
- example.comКак правильно доставлять изменения в случае multistage environments в рамках gitops.
Постановка вопроса некорректна. Нет "правильного", "лучшего" ответа. Есть решения, у этих решений есть плюсы и минусы. Вариантов "доставлять изменения" много, и, как уже было сказано, это не в рамках подхода GitOps. GitOps только говорит, что нужно описывать конфигурацию декларативно и хранить в гите, а как ты будешь изменения конфигурации добавлять в гит - это другой вопрос.
Или дадите ссылку на документацию, где описана принципиальная разница в процессах, на которую вы намекаете?
Я не знаю где достать "документацию по GitOps".
Ровно то же самое я описал в своей статье в главе Проблема нескольких окружений .
Только объяснения разницы я делал на основе разницы в инстансах баз данных, а не ингрессах, дал ссылки на источники на gitops.tech и таки дал рецепты решения этой проблемы.
Может вам стоит перечитать эту главу и обсудим её предметно?
Я бы сказал в общем, что с точки зрения GitOps не будет хорошей практикой держать разные среды в разных ветках и делать мержи между ними. Для GitOps среды принципиально различаются. Это не код приложения, который через ветки стабилизируется. Если проводить аналогию, тогда ветки с точки зрения GitOps могут означать разные кластера, то есть в одном кластере мы тестируем какие-то изменения, потом мержим в основную ветку и все раскатывается в продакшн кластер. И то это очень и очень с натяжкой, и даже так делать - это разложить себе грабли на будущее. Правильнее конфигурацию разных кластеров держать в разделенных директориях или репозиториях.
Если говорить строго, GitOps принципиально отказывается решать вопрос переноса версий ПО между окружениями. Я писал об этом в статье. Данный вопрос важный и этот тред прекрасно иллюстрирует мою мысль - когда какой-то вопрос не описан, каждый решает его сам при помощи собственных костылей и велосипедов.
Мерж кода - один из способов решения этого вопроса.
Другие способы связаны с активным скриптописанием. Тоесть stop scripting and start shipping не получается.
Можете рассказать как с вашей точки зрения этот вопрос решить правильно?
«А давайте у вас будет всего одно окружение, и вы не будете маяться дурью»
А давайте не будем перевирать то, что написано по ссылке? GitOps не ограничен одним окружением.
Это всё равно что сказать: "этот MySQL предлагает иметь только одно окружение, потому что я не могу использовать одну и ту же базу данных в проде и в деве, вот отстой".
Текст по ссылке, вольный перевод которого я привёл в статье:
GitOps doesn’t provide a solution to propagating changes from one stage to the next one. We recommend using only a single environment and avoid stage propagation altogether.
Можете предложить свой вариант перевода, если считаете, что мой не корректен?
Контекст разный. У тебя в тексте это звучит так, будто при использовании GitOps тебе в нельзя иметь других окружений вообще. Это несерьёзно, как может методика деплоя тебя ограничивать в количестве окружений? У них контекст про применимость подхода, и эта фраза там значит что лучше не надо смешивать в одном декларативном описании несколько окружений.
Пожалуйста, не вырывайте мои фразы из контекста. Вот полный текст:
А что у нас GitOps говорит по поводу управления окружениями? А GitOps говорит: «А давайте у вас будет всего одно окружение, и вы не будете маяться дурью». Я, например, не уверен, у многих ли команд только одно окружение. GitOps-идеологи, похоже, тоже в этом не уверены. Поэтому они говорят: «Ну если вам очень нужен multistage, то сделайте это где-нибудь outside of the GitOps scope. В рамках вашей CI/CD-системы например».
На мой взгляд это достаточно близкий по смыслу перевод документации(с авторскими комментариями).
И здесь была мысль про то, что концепция GitOps игнорирует multistage, хотя это является важной частью эксплуатации приложений.
Я как раз тебе на контекст и указал. У тебя контекст про окружения для команды, в том тексте, который ты переводишь, контекст управления окружением. Если разжевать, то в рамках одного репозитория советуется описывать одно окружение.
Не нашел в пункте
https://www.gitops.tech/#how-does-gitops-handle-dev-to-prod-propagation
упоминания про правило "один репозиторий = одно окружение". Не нашел там вообще упоминаний про репозитории. Только про окружения.
Я не туда смотрю?
Ну, речь здесь о том, что GitOps сам по себе не предоставляет способ как перекатывать версию приложения между дев-стейдж-прод средами. И это правда, потому что GitOps - это про статическое декларирование состояния, а не про динамику.
Но никто не мешает использовать GitOps для того, чтобы делать коммит сначала для дев среды, потом для стейдж, потом для прод с указанием нужных версий, это и будет решением multi-stage. Это можно и в CI систему уже завернуть.
А GitOps нам говорит: «Никогда не храните ваши пароли открытым текстом в Git-репозитории». Что можно сказать? Спасибо, кэп!
Ну кому кэп, а кому нет. Скажи ещё, ты ни разу не видел паролей в гите.
Дальнейшее словоблудие к GitOps имеет отношение постольку-поскольку. Secrets management сложен независимо от того, используешь ты GitOps или нет. Вот тот же алгоритм со сменой паролей - а что, если б ты GitOps не использовал, тебе пароли не надо менять было? Нет? У тебя наверное ротация паролей тогда настроена? А чем же тебе GitOps мешает настроить ротацию паролей? Или IAM использовать для авторизации? Или инструменты типа Vault?
Я встречал множество паролей, токенов и сертификатов в гите. И, как правило, люди их туда положившие прекрасно знали, что этого делать нельзя. Просто ленились сделать по-другому.
Что до использования vault-подобного тулинга в GitOps — я изложил свои соображения в статье. Можем рассмотреть их по существу.
git ещё более неединственным источником истины и тем самым идёт вразрез с GitOps-подходом
Этот аргумент ещё в первой статье меня возмутил. Да кто ж тебе сказал, что в GitOps один git репозиторий это единственный источник истины ВСЕГО? Ты доводишь идею до абсурда, а потом возражаешь уже тому абсурду, который сам же и выдумал.
Есть артефакты сборки, для них "источником истины" будет код приложения и настройка системы сборки. А потом репозиторий артефактов, например Container Registry. В GitOps у нас только тег образа и адрес реестра, а не весь образ.
Есть Helm чарты, для них может быть свой репозиторий и код. В описании окружения у нас есть указание где брать хелм чарт, какую версию, и какую конфигурацию применить.
В тех статья, на которые ты ссылаешься, про это точно пишут, например "There are at least two repositories: the application repository and the environment configuration repository."
Я ориентируюсь на описание GitOps от авторов концепции: https://www.weave.works/technologies/gitops/
Цитаты:
GitOps leverages Git as the single source of truth to define every part of a cloud-native system.
With the declaration of your system stored in a version-controlled system, and serving as your canonical source of truth, you have an ultimate repository from which everything is derived and driven.
At the center of our pull pipeline pattern is a single source of truth for manifests (or a config repo).
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.
Как вы можете заметить, в этих цитатах употребляются словообороты single source of truth, ultimate source of truth.
Не main source of truth или common source of truth.
Отсюда можно сделать вывод, что авторы концепции предполагают, что мы должны иметь возможность разрешить ЛЮБОЙ вопрос, связанный с конфигурацией нашего приложения просто посмотрев в гит.
Если вам кажется, что мой перевод не верен, или я что-то важное упустил в документации, прошу это аргументированно изложить.
Да хоть запереводись, если ты не понимаешь текст. Источник правды чего? Там в тексте написано, если что. Там где-то указано, что это источник правды ВСЕГО? В частности, где там написано, что git дожен быть источником правды для секретов, ведь ты этому удивляешься
использование внешних хранилищ секретов делает git ещё более неединственным источником истины
Выше я привёл цитаты из официального источника и мой вывод, который я сделал на основе их интерпретации.
Если вы считаете, что моё понимание неверное, можете изложить своё понимание, подкрепив его источниками?
Цитирую твоё цитирование.
single source of truth for manifests (or a config repo)
Где ты там увидел "single source of truth for everything" или "single source of truth for secrets"?
Там чуть ниже цитата. Вот эта:
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.
Ну значит текст в твоём прочтении сам себе противоречит, ок.
Можете пояснить в чем противоречие? Для меня это не очевидно.
Ты понял что у тебя гит это источник правды для всего, при этом там же на той же странице прямо говорится что это источник правды для манифестов.
Вообще-то в предыдущем ответе я привёл цитату
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 явно говорит нам, что секреты являются частью манифестов.
Хранилище и манифесты - это разные вещи.
Образ контейнера хранится в реестре - это хранилище.
В манифесте указывается версия - это source of truth для деплоя приложения. Инструментарий внутри кластера отвечает за доставку образа с данной версией.
Также и секретами. Vault - это хранилище, зашифрованный пароль в репозитории - тоже хранилище. Манифест говорит о том, где секрет лежит. Контроллер в кластере достает секрет и предоставляет его приложению.
Конфигурация = манифесты, она хранится в репозитории и является этим самым источником правды.
Хранилище это другое.
В этом подходе источник истины распространяется на хранилище и его содержимое в том числе. Содержимое хранилищ может быть изменено, эти изменения могут быть не зарегистрированы (и не отображены в гит) но напрямую повлиять на функционал приложения. Это нужно по крайней мере учитывать.
Я бы назвал git в данном случае не single а main source of truth.
Давайте подумаем. GitOps покрывает только stage деплоя. Но, поскольку git не может являться единственным источником истины, про откат мы должны думать на стадии сборки наших артефактов
Давайте подумаем, да. Если у тебя нет предыдущих артефактов сборки и предыдущего кода, то никакой SuperMegaOps тебе не даст сделать откат, если у него нет машины времени под капотом. Почему ты записываешь это в минусы именно подходу GitOps?
Потому что гитопс прямо обещает простой и быстрый откат: https://www.gitops.tech/#easy-and-fast-error-recovery
Я просто обозначил что откат возможен только если ты позаботишься о нём в том числе outside of gitops scope. Считаете по-другому?
да, там ещё не написано, что этот подход будет работать, только если
ты после git revert сделал git push
при этом в нужный репозиторий
и у тебя есть на это права
и компьютер у тебя при этом включен
и интернет есть
и AWS при этом сам не лежит
и ты живой и можешь нажимать на кнопки.
Да. Уж обманули так обманули, на самом деле всё сложно и ещё кучу условий надо соблюсти.
Такой флоу, где в реестре образов нет предыдущих версий - плохой флоу.
Откатывали продакшн, откатили стейджинг внезапно.
Если у тебя не гранулярные коммиты, которые затрагивают сразу несколько окружений, то ты ССЗБ. Это можно и в пуш модели сделать через жопу, когда у тебя пайплайн обновляет версии сразу на всех окружениях, и там нельзя отдельно обновить/откатить одно.
Gitlab может быть единственным источником истины
То есть в случае гитлаба вот эти аргументы из предыдущей статьи не работают чтоли? А что поменялось?
в данном конкретном случае не может быть единственным источником правды. У нас есть по крайней мере два ресурса — два артефакта вне git, от которых этот Helm-релиз зависит
И это работает прекрасно, пока не случается каких-то ручных операций. Например, ваш Ops guy уволился.
GitOps нигде не декларирует что есть защита от бас фактора или что оно будет нормально работать с ручными операциями.
Допустим, где-то есть кластер Kubernetes, в котором он поставил Flux и дал ему вручную в обход flux-fleet доступ в ваши инфраструктурные репозитории.
Допустим, он где-то поднял ещё один гитлаб, добавил ключи доступа для синка реп и периодически деплоит в левый кластер.
GitOps нигде не декларирует что есть защита от бас фактора или что оно будет нормально работать с ручными операциями.
Гитопс декларирует
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». Всё это приводит к непониманию, как правильно организовать процессы, и, соответственно, к костылям и велосипедам со всеми вытекающими.
Погоди погоди. GitOps декларирует какие-то вещи, которые будут происходить, если ты будешь следовать подходу GitOps. В каком месте у тебя
пока не случается каких-то ручных операций
это следование подходу GitOps?
Это про "сделать такой подход, чтобы проблема стала невозможна".
На самом деле ручные операции и configuration drift - давняя проблема подхода IaC.
Chef и Puppet это в какой-то степени решали за счет reconciliation loop, но там были фундаментальные проблемы с выделенными железными персистентными серверами.
Сейчас же у нас immutable infrastructure, и stateless. И за счет более строгих подходов можно нивелировать проблему. Но на мой взгляд, GitOps этого не делает даже близко.
Ещё раз, вопрос был достаточно простой, в твоём понимании ручные операции - это GitOps? Если да, то ок, я с тобой согласен, твой GitOps - плохой. Если нет, то я не понимаю, почему ты обвиняешь GitOps в проблемах, которые вызваны ручными операциями.
Приведу аналогию: амортизаторы это часть автомобиля? Значит ли что автомобиль без амортизаторов плохой?
Ты увиливаешь от ответа. Если это игра в "за кем последнее слово тот и прав", то я сдаюсь. На следующий коммент, в котором не будет ответа на простой вопрос, является ли ручная правка следованием GitOps, я промолчу.
Я уже ответил на этот вопрос.
Ручные правки являются фундаментальной проблемой. Ты с ней сталкиваешься в том числе когда делаешь GitOps.
Являются ли ручные правки частью GitOps? - НЕТ
Должен ли GitOps с ними бороться? - ДА
Борется ли GitOps с ручными правками? - ПЫТАЕТСЯ
Как у него это получается? - ПОСРЕДСТВЕННО
Так понятнее?
Наконец-то.
Ты путаешь методологию (GitOps) и инструмент (fluxcd). GitOps это подход при котором у тебя конфигурация хранится в git, и любой инструмент который используется для "доставки" конфигурации должен использовать git как источник. Всё. Поэтому
Должен ли GitOps с ними бороться?
НЕТ.
Борьба с ручными правками - это уже детали реализации. Если инструмент тебе такое обещает и не делает - позор ему, такому инструменту, но GitOps тут не при чём. Поэтому правильнее было бы в следующих вопросах наверное (сомневаюсь потому что не работал с Flux) поменять:
Должен ли FluxCD с ними бороться? - ...
Борется ли FluxCD с ручными правками? - ...
Как у него это получается? - ...
А сам GitOps, как методология, тут не при чём, ещё раз повторяю. Ты можешь реализовать его как push так и pull моделью, можешь в качестве инструмента использовать FluxCD/ArgoCD, а можешь Crossplane/Ansible/Terraform или вообще bash скрипты с kubectl/helm/kustomize. Можешь защищаться от ручных правок, строить процесс с review и тестами, а можешь плюнуть и без проверки делать apply. И всё это будет GitOps в каком-то приближении - до тех пор пока ты манифесты у тебя кладутся в git и только оттуда применяются к кластеру каким либо автоматизированным способом.
Ты путаешь методологию (GitOps) и инструмент (fluxcd). GitOps это подход при котором у тебя конфигурация хранится в git, и любой инструмент который используется для "доставки" конфигурации должен использовать git как источник.
Всё.
Нет. Это как раз только начало. Моя статья - сборник кейсов, в которых можно применить GitOps и сборник проблем, которые при этом могут случиться. Я отдельно указал это в дисклеймере к статьям.
Вы считаете что делая GitOps вы не столкнётесь с ручными изменениями на инфраструктуре? Или что ими можно пренебречь?
Твоя статья утверждает что GitOps бесполезен. В доказательство ты приводишь ручные правки или что в манифесте HelmRelease можно указать неточную версию (latest ещё укажи и жалуйся, ага?), или что артефакты из репы могут пропасть, или ещё какой-то бред.
ПДД бесполезен, потому что светофоры могут не работать а водители превышать скорость.
Сборник кулинарных рецептов бесполезен, потому я их не читаю и жарю яичницу.
ВУЗы бесполезны потому что я там протирал штаны и пропускал лекции.
CIOPS (это не опечатка, не гитопс, а ciops за который ты топишь, как я понимаю, и я не вижу, почему этот аргумент не должен работать против ciops) бесполезен, потому что после каждого релиза автоматически выкатываемого через пайплайны в гитлабе админ идёт и правит манифесты руками, скотина такая.
Судя по содержанию коментариев, вы не прочитали мои статьи. Взять хотябы это замечение что инфраструктурные репозитории мержить нельзя.
Меж тем в них я пытался дать системную картинку. Описать предпосылки -> обещания -> практическую реализацию -> анализ обещаний через практическую реализацию -> выводы. Причем снабдил это множеством ссылок на теорию и документацию потому что практика без теории слепа.
Вы же прошли статью по диагонали, выбрали несколько моментов, которые не понравились и пытаетесь их обсуждать вне контекста. Как в той притче когда человек нашел хвост слона и утверждал что слон это верёвка.
Ты уводишь диалог в сторону. Читал я статью или нет, правильно ты перевёл с английского или не правильно, это всё демагогия и увёртки. По сути ты ничего внятного не пишешь. И не надо на это отвечать, это метаспор, я не буду тебе доказывать, что читал твою статью.
Ты утверждаешь что GitOps бесполезен, используя аргументы, в которых описываемая ситуация не является следствием применения GitOps, а является следствием некомпетентного использования инструментов. То есть у тебя нет логической связи от GitOps к твоим аргументам. Я тебе привёл несколько неувязок в статье, ни на одну ты не смог ответить нормально.
Жаль, что вы фокусируетесь на моментах, которые вам кажутся спорными и отказываетесь видеть общую картину. Я сталкивался с многими странными решениями в своей практике, и к любой вещи подхожу на основе закона Мерфи: если что-то может быть сделано не так, это будет сделано не так. Это принцип, с позиции которого я писал и эту статью. Для меня неожиданно что этот подход вызвал у вас столько недоумения, потому что я считаю, что любой специалист с достаточным опытом рано или поздно приходит к этой позиции.
Развивайте системное мышление, повышайте уровень технической грамотности, будьте позитивным и уважительным и вас определённо ждёт успех в будущем.
Спасибо!
Все просто, нехер делать кликбейтные заголовки для статей. И никто не будет макать в несоответствие между заголовком и содержимым.
Можем пойти от противного. Что по-вашему дал нам гитопс?
Многие проблемы именно связаны с Helm и с тем фактом, что Helm управляет манифестами, а FluxCD управляет Helm чартами/релизами. Тут действительно может быть неприятно. Но они решают эту проблему и скоро предоставят свои первые результаты:
Итого
Вторая спорная статья с буллщит аргументами.
Спасибо за статью! Использую GitOps + FluxCD уже несколько лет благополучно. Начинал только с инфраструктурной части, а последний год и деплой приложения переключил с CI Ops на Git Ops и не жалею. Попробую обозначить главные пункты, с которыми не согласен, отдельными тредами под своим комментарием :)
Потому что в данном конкретном случае конфигурация вашего приложения будет зависеть уже от четырёх репозиториев (репозиторий приложения c чартом, репозиторий «единой точки конфигурации платформы», инфраструктурный репозиторий flux, репозиторий с файлами terraform) и двух систем деплоя (flux и terraform).
здесь не нашел какой-то громкой большой проблемы, если процессы настроены, устаканены, задокументированы - то есть когда ops команда хорошо делает свое дело, а не "тяп ляп - и так сойдет"
1 - terraform репозиторий по умолчанию является "провижинингом инфраструктуры", и это просто должен быть общий стандарт, все знают, что именно там создается кластер и его уникальные специфические значения - никакой проблемы
2 - репозитории с чартом и «единой точки конфигурации платформы» можно смело смержить, не знаю зачем разделять; или же чарт может лежать рядом с кодом приложения; оба способа понятны
3 - инфра репозиторий может существовать, а может и нет, здесь каждый под себя строит процесс; я думаю его нужно отделять только если инфрой занимается совсем отдельная команда; но тогда и процессы внутри компании должны быть четко разделены; но уж точно 100% изменения в приложении не должны никак быть связаны с инфра репозиторием
в общем, я не понимаю совсем аргумент "много репозиториев - это плохо"
для меня это "хорошая структура"
Я правильно понимаю, что этот комментарий скорее в поддержку моей мысли?
это очевидно
речь идёт о случае когда у нас много микросервисов и values для них хранятся в едином месте
существование инфра репозитория - фундаментальное требование гитопс
Есть такой принцип программирования - KISS (keep it simple, stupud).
Много репозиториев это не плохо при условии что это хорошо спроектировано. Согласно моему опыту, в отдельные репозитории нужно выносить только явно используемые совместно вещи. Если вы просто вынесете в отдельный репозиторий настройки всех приложений, то возникнет просто разрыв между приложением и его конфигурацией, который будет не очевиден и который потребуется покрыть документацией. Если вы добавите к этому репозиторий глобальных настроек приложенй, то просто будете просто теряться между репозиториями - в какой из них положить тот или иной конфигурационный параметр.
В качестве резюме - если создание отдельного репозитория сможет сократить сложность вашей системы и/или ваши трудозатраты, - во всех остальных случаях лучше этого избегать.
Первый — valuesFiles
Следующий вариант — valuesFrom
Есть еще один очень удобный вариант. Использовать механизм патчей от kustomize. Если совсем не любите/не используете kustomize, то можно остаться на хелм чартах, но использовать патчи. И это будет выглядеть как-то так:
patches:
- patch: |-
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
name: myapp
spec:
values:
clusterCustomVar: newValue
target:
kind: HelmRelease
name: myappЭто опять же не позволит сделать stage propagation через merge.
Почему я настаиваю на мерже изменений для доставки изменений по окружениям? Если у нас окружения описаны отдельными репозиториями или папками в гите, и конфигурацию там мы изменяем вручную, либо при помощи каких-то скриптов, то это потенциально приводит нас к ситуации когда накапливается environment drift.
Проблема секретов
Это вообще широкая тема за рамками GitOps, я бы совсем не стал сюда добавлять это. GitOps предлагает и поддерживает разные подходы для этого, но ничего не прописывает стандартом. Каждый для себя выбирает сам.
Тема широкая, согласен, но она фундаментальная. Это та вещь, которая must have. И обойти её было бы по крайней мере не правильно.
В гитопс есть понятие Git as the single source of truth. Мне было интересно как сделать управление секретами, чтобы следовать этой идее.
Кстати как вы относитесь к идее Git as the single source of truth? Считаете ли вы её важной для гитопс?
Да, конечно, это идея фундаментальна. Но кажется мы ее слегка по-разному понимаем. Я понимаю так, что Git хранит описание желаемого состояния. GitOps инструменты помогают приводить целевую инфраструктуру к этому желаемому состоянию и следить за тем, чтобы не происходило отклонения от этого состояния.
Хорошо. А что в этом подходе специфично для GitOps?
GitOps специфика для меня = никаких ручных действий с инфраструктурой, любое изменение - это git commit. И если инфраструктуру стереть в пепел, ее можно полностью восстановить исходя из состояния, которое зафиксировано на репозитории.
Ну давайте по порядку
никаких ручных действий с инфраструктурой, любое изменение - это 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 в гите?
IaC безусловно входит в GitOps.
Для меня вообще грань эта едва уловима, эти понятия схожи. Разве что IaC просто говорит нам хранить все в виде кода, а GitOps добавляет поверх этого еще автоматический процесс синхронизации с целевой средой.
Что мы сейчас с вами обсуждаем?
Ну я тоже потерялся. Тред начинался с секретов.
GitOps добавляет поверх этого еще автоматический процесс синхронизации с целевой средой.
Парадигма "синхронизации конфигурации" стара как мир. Впервые идея декларативного описания инфраструктуры и автоматическая синхронизация конфигурации с ним была реализована в cfengine (первая версия 1993 год).
Если говорить о развитии парадигм, то сейчас главенствует immutable infrastructure. Полностью автоматизированные пайплайны доставки её необходимый аттрибут. Я описывал это в первой части статьи.
Возможно вы имеете в виду разницу между pull и push подходом? Pull-подход был основным в SCM второго поколения - puppet и chef. SCM-системы третьего поколения (ansible, salt,terraform) от него отошли. Как думаете почему? (ответ - pull подход очень ресурсозатратен и не может до конца предотвратить configuration drift)
Кроме того гитопс всего лишь рекомендует использовать pull. С push-подходом он тоже ок.
Для меня вообще грань эта едва уловима, эти понятия схожи.
Ну так можете объяснить эту грань? Мы ведь говорим про IT. Строгая теоретическая база её фундаментальное свойство. Вот вы явно адепт или апологет гитопс. Чувствуется что вы любите эту концепцию. Что мне нужно чтобы делать гитопс?
Покачто вы описываете идеи, самая свежая из которых появилась не менее деясти лет назад. Самое оригинальное из того что вы сказали это превращение давно и хорошо известной хорошей практики держать IaC в гите в обязательное требование. Этого достаточно?
Вот у меня например дженкинс и пайплайны как код. У меня дженкинсфайл, который билдит имидж, sed'ит его в шаблон ямлика и аплаит ямлик в куб. Всё это лежит в гите и триггерится по пушу в гит. У меня гитопс?
Ну я тоже потерялся. Тред начинался с секретов.
Не совсем. Тред начинался с обсуждения секретов в рамках одной вполне определённой идеи.
И какая из них безопаснее при условии, что они обе имеют админские права? Это риторический вопрос. Потому что админские права есть админские права.
Хороший риторический вопрос. Но при сравнении CI системы против GitOps, здесь речь скорее про то, что не нужно в CI систему класть пользователя с доступом в кластер. В этом и находится ключевое различие.
Почему в CI систему нельзя класть пользователя с доступом в кластер?
Во-первых хранилище секретов это один из важнейших функционалов CI систем. Мы можем достаточно гибко заводить секреты, раздавать на них права и защищать от кражи.
Во-вторых есть множество способов интеграции CI систем с kubernetes. От авторотирующихся токенов в специальных модулях до установки раннера в кластер и использования сервисаккаунтов (схема очень близкая к контроллерам flux).
Но моя основная мысль здесь - к безопасности нужно подходить осмысленно. Гитопс утвержданием что он безопасен по умолчанию вводит в заблуждение.
Почему в CI систему нельзя класть пользователя с доступом в кластер?
Не утверждаю, что нельзя. Я имею в виду, что в случае GitOps мы этого не делаем, и следственно не добавляем точку хранения доступа в инфраструктуру. А в случае CI Ops делаем. И это обычно и является тем пунктом, которые ставится GitOps подходу в плюсы.
Сомнительный/неоднозначный плюс.
Во-первых мы точно также можем не делать это в CIOps.
Во-вторых замена непосредственного доступа на апосредованный на мой взгляд не сильно поднимает безопасность.
А как не делать это в CIOps? Что имеется в виду?
не сильно поднимает безопасность.
не сильно, согласен, но немного поднимает
они еще добавляют один пункт, который я не упомянул
For that, your environment only needs access to your repository and image registry. That’s it. You don’t have to give your developers direct access to the environment.
но тут на самом деле разного рода разработчики бывают, не всем будет приятно совсем не видеть напрямую, что происходит с контейнерами
По ходу тут явное передёргивание. Действие "положить ключ доступа к кластеру kubernetes в CI систему" трактуется как "дать ключ разработчику". Это севершенно не верно. В CI системе мы можем при желании запретить доступ разработчика к этому ключу.
Единственный наверное кейс, в котором безопасность с GitOps увеличивается, это когда CI-систему и кубовые кластера эксплуатируют разные команды, и команде CI-щиков не хочется выдавать ключи доступа к кластерам. И то этот случай можно решить установкой раннера в кластере и использование сервисакаунта.
Ну плюс на раннере можно выполнить произвольный скрипт, а на контроллере флюкс только создание объекта в кубе, но это не особо существенное различие.
Процедура отката
Общий комментарий на всю секцию. Вы, кажется, просто перечислили несколько способов как делать не надо.
На самом деле процедура отката = git revert коммита, который привел к обновлению приложения. То есть либо версии образа, либо версии хелм чарта. И система откатывается. На этом все.
С точки зрения инфраструктуры может быть чуть сложнее, в том плане, что в коммите может быть и много структурных изменений. И вопрос перетекает в git-гигену - правильный набор изменений внутри коммита сделает откат возможным через revert. И это в разы, в разы удобнее, чем ходить по кластерам руками править конфигурации. Мне кажется, тут бессмысленно спорить)
Единственный существенный минус `git revert`, который я вижу, это когда происходит предварительная мутация структур баз данных и нужно сначала предусмотреть откат на этом уровне перед откатом приложения. Но это тоже не в рамках GitOps, это про искусство сохранения обратной совместимости и т.п.
Основная мысль здесь была в том, что откат нужно хорошо спроектировать. Следование пути гитопс не гарантирует возможность откатиться. Возможно я это чуточку многословно изложил, с избыточным количеством примеров, но мысль именно такая.
Хорошая мысль, поддерживаю на 100%.
Но опять же, откат нужно спроектировать в любой системе. Поэтому это не минус/плюс GitOps подхода. GitOps подход просто дает возможность делать это через `git revert`, и это приятно.
Здесь я стриггерился на этот пункт
https://www.gitops.tech/#easy-and-fast-error-recovery
Он выглядит так будто "git revert всё что вам нужно". Это явная брехня.
А что у нас насчёт CI Ops? В рамках CI Ops на Gitlab нам не нужно делать кучу дополнительных телодвижений для обеспечения функционирования GitOps. Нам нужно:
Сделать CI-скрипт сборкой и публикаций докер-образа.
Добавить в скрипт деплой Helm-релиза через Helm apply.
Создать аккаунт для доступа CI-системы в Kubernetes.
Я бы в целом сказал, что вы замыкаете обсуждения на уровне "деплоя приложения", хотя есть еще большой аспект управления Kubernetes инфраструктурой и ее наполнением, для чего GitOps инструменты очень хорошо подходят, и здесь CI система совсем не подходит.
Но даже если говорить только про деплой приложения, то я бы добавил еще ряд пунктов:
разработать удобную и масштабируемую CI шаблонизацию
проработать удобные нотификации от CI систем
позаботиться о том, чтобы из енва и приложения можно было бы определить из какого билда оно прилетело (тут благо почти все CI системы это уже умеют в аннотации проставлять, но мало ли)
при каких-то изменениях CI скриптов проходиться по n репозиториев приложений (мое любимое, даже с максимальной шаблонизацией CI шаблонов и автоматизацией массовых git апдейтов это всегда весело)
продумать и решить вопрос привязки енва к вашему git flow
решать вопрос падающих helm upgrade на этапе деплоя (retries, timeouts, etc)
Это все просто с ходу пришло в голову по опыту связки CI + helm. Очень рад был уйти от этого и переключиться на FluxCD + kustomize. Не могу сказать, что сразу решены все проблемы, но по общему ощущению всё сильно стабильнее.
Обсуждение я замыкаю на уровне деплоя приложения потому что гитопс замыкается на уровне деплоя приложения. Тоесть это не 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 ?
При всем уважении, этот ответ - это "подгон под ответ".
Ну то есть, при том, что я считаю, что GitOps проще, а вы - что CI Ops проще, мы тут можем сколь угодно долго спорить, но останемся при своем мнении.
Я находился на стороне CI Ops продолжительное время, была очень продуманная шаблонизация с инклюдами, были выверенные временем деплойменты через helm, прошел через все возможные грабли.
Но когда перешел на GitOps + FluxCD, я просто почувствовал насколько это проще.
Пожалуй, это моя главная мысль в этой ветке.
А можете пояснить почему стало проще? Я описал свои претензии к гитопс в статье. В кратце это
Количество скриптов CI не уменьшается, добавяются новые инфрастуктурные сервисы и доступы, увеличивается сложность инфрыструктуры и пайплайна.
Я отразил это в чеклистах.
Сразу скажу, буду субъективен, и части задач, которые вы решаете, у меня на данный момент просто нет.
1) CI часть упростилась, стадия с деплойментом свелась к `git push`
2) Нет дрифта конфигурации, любые изменения откатываются сами - это пожалуй один из самых больших жирных плюсов для меня
3) Удобнее использовать `git revert` как откат версии, это просто работает, не заходя в кластер
4) Мониторинг и отладка падений тоже нравится, объект HelmRelease всегда содержит логи и ошибки от вызова хелма, по логам контроллеров можно вообще всю историю событий установить для всех объектов
5) Не забываем про историю изменений через git history
Большинство из перечисленных вами пунктов - это единоразовая работа на старте. После этого об этом не беспокоишься. Такие вещи меня совсем не смущают, пока не надо что-либо повторять регулярно.
С CI Ops мне много приходилось делать руками в кластере, чтобы чинить состояние. С GitOps этого делать практически не приходится и всегда можно вернуться в заведомо работоспособную точку.
1) А как вы генерите то что нужно запушить? Как решаете вопрос stage propagation? У вас всего одно окружение?
2) Вы не используете флюкс с хелмом?
3) Как вы определяете на какой комит откатиться? У вас репозиторий на каждое окружение каждого приложения? Как вы определяете что конфигурация в конкретном комите рабочая?
4) Вы не используете нотификации о прохождении пайплайнов? А если билд или пуш сфэйлится?
5) Вам хватает git history? Как вы определяете какая конфигурация выкатилась, а какая упала например?
С CI Ops мне много приходилось делать руками в кластере, чтобы чинить состояние.
А что помешало сделать это через перезапуск стейджей пайплайнов? У вас монолитные пайплайны?
1) CI пайплайн просто пушит версию приложения сначала в dev, потом в stage, потом в prod - три разных kustomization.yaml файла. Версия генерится в момент сборки.
2) Для деплоя своих приложений хелм не используем. Для кластерной обвязки (мониторинг, логгинг, безопасность и тп), используем.
3) Вообще редки ситуации, когда нужно прямо в далекое прошлое откатываться, чаще всего это в виде "задеплоили, что-то пошло не так, откатили", и тут не надо много ума определить куда откатиться. У нас монорепа для флакса, там хранится состояние всех сред со списком версий всех текущих приложений.
4) Конечно используем. Любой упавший пайплайн о себе сообщает.
5) Хватает. Если честно, тут сложно ответить абстрактно, проще было бы на конкретном примере. Обычно есть какая-то проблема, она исследуется, дальше понимаем когда она возникла - в этой точке по времени будет какой-то коммит, который нужно откатить.
А что помешало сделать это через перезапуск стейджей пайплайнов? У вас монолитные пайплайны?
Перезапуск стейджей - это все равно ручное действие. Retries не сильно распространенная фича, насколько мне известно. На самом деле, я этот пункт немного не додумал, здесь не переход CI Ops на GitOps помог, а с helm на kustomize скорее, ибо с helm действительно часто приходилось сражаться.
1) Выглядит так будто у вас очень маленький проект, для которого хватает кастомайза, либо ваши кастомайзы должны быть адом копипаста. Вы пересобираете имиджи для каждого окружения? Вы настолько уверены в повторяемости сборок? Мне интересно какой у вас стек и какое медианное количество собственных строк кода на проект. SBOM вы составляли?
2) Закономерно. Хелм экстремально популярен. Все основные проекты развивают свои хелм чарты. Даже если основа деплоя проекта - оператор, обвязку к нему тоже как правило заворачивают в чарт.
4) Тоесть внедрение гитопс заставило вас принести в инфру ещё одну систему алертинга?
5) Интересно сколько команд в вашей организации, сколько у них проектов и как часто они релизятся. По моим ощущениям, после двадцати проектов с недельным релизным циклом разбираться в инфраструктурных гитах становится уже достаточно сложно.
Перезапуск стейджей - это все равно ручное действие.
Вы не считаете git revert ручным действием? У вас он как-то автоматизирован?
Приходите на мой доклад на devopsconf подискутировать вживую?
Что такое GitOps и почему он (почти) бесполезен. Часть 2