Комментарии 55
Прошу прощения если мой комментарий вас обидел. Давайте поясню.
Не стоит путать концепцию 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, но сами для себя не можете это сделать.
Вышла вторая часть и в ней есть вывод что такое гитопс по моему мнению.
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. (Здесь всё понятно? Перевод нужен?)
Тоесть под названием гитопс вам фактически продают тулинг. Просто ещё один способ что-то задеплоить.
Если кто-то считает, что он хорошо подходит на его процессы - это нормально. Но ни о каком прорыве/серебряной пуле речи не идёт.
GitOps на самом деле хорошая концепция, но вы от нее слишком много хотите.
Есть вариант хранить конфиги окружений на машинах, но тогда появляется проблема как их версионировать, как их поддерживать нескольким девопсам, как синхронизировать окружения, как обновить не лазя лишний раз в продуктовый контур. На все эти вопросы отвечает GitOps. Вы храните конфиге в гите и раскатываете из гита так же как вы раскатываете софт.
Да конфиг использует внешние артефакты для своей работы, но это так же плюс. Ибо если в этот конфиг каждый раз вносить хеш сборки ручками то можно замучаться. А так новая версия сервиса накатывается автоматом с ее релизом.
Дьявол кроется в деталях.
Хранить конфигурацию в гите и раскатывать их из гита придумали задоооооолго до гитопса (посмотрите тот же тест Лимончелли).
Я хочу от концепции ровно то, что она заявляет - от гита как единственного источника истины до key benefits + пунктов why i should use gitops.
И во второй части статьи обязательно раскрою как GitOps (конкретно flux2) реализует эти пункты. Как говорится, не переключайтесь.
Честно пытался осилить статью. Честно.
Что такое GitOps и почему он (почти) бесполезен
... Если коротко, то GitOps не является «Серебряной пулей» ... Так что такое GitOps?
Что такое GitOps и зачем он нужен
В этом разделе не раскрывается, что такое GitOps. Ok, читаем дальше
GitOps — панацея от всех ваших проблем. Или нет
Ребята, вам нужен GitOps ... Сайт ... утверждает, что GitOps - это инфраструктура ...
Сарказм: а другие сайты в интернете утверждают про инопланетян и 100500 теорий заговора. Так что такое GitOps?
Логика работы Flux с Helm
Э-э-э, а это причём? Так Helm самое популярное packaging application! Правда, потом выясняется, что это только для kubernetes (видимо, без него не существует GitOps). Так, здесь появляется git репозиторий. Уже хорошо. Их у нас много, набиты кодом. Что по поводу GitOps?
Чек-лист для GitOps
Уже? GitOps - непонятно, но чек-лист - он есть.
Небольшой взгляд в сторону: ну есть скрипты ci/cd. Много кто хранит их в git репозитории. Да что далеко ходить: тот же gitlab настоятельно склоняет к этому. В отдельном хранить репозитории или нет - по моему оба подхода (иногда сильно различны) имеют как плюсы, так и минусы.
Так в чём смысл выделения отдельного понятия GitOps? Что такое GitOps? Пожалуйста, для людей не в теме чуть по-подробнее.
Там картинка есть. GitOps in 1 slide. На английском правда, но знание английского - обязательная вещь для ИТ-шника.
Переведу его для вас: GitOps это паттерн разработки/управления системами. Имеется в виду информационные системы и управление их конфигурацией.
Далее в том же разделе идёт достаточно подробное описание паттерна. Git - единственный источник истины, момент про CD тулинг и два репозитория. Если на ваш взгляд я их не полно изложил, там есть ссылки на сайт, целиком посвященный GitOps - можете разобраться самостоятельно.
И я категорически не понимаю что вас смущает в том, что я рассматриваю один из самых распространённых вариантов реализации GitOps? С Helm и Kubernetes.
Причем я подробно, по шагам, рассматриваю процесс доставки приложения в рамках процессов GitOps.
Если вы настолько не в теме, возможно вам нужно начать с какого-то более простого материала?
Кстати про сравнение CIOps с GitOps будет во второй части статьи. Но опять же судя по всему это может быть для вас сложновато.
Если help-chartы и образы докера создаются из гита автоматически (именно так и выглядит), то принцип "гит — единственный источник правды" не нарушен. Просто часть правды потребляется через посредников
Хелм чарт это "лёгкая" зависимость. Но её, как правило, нужно делать out of gitops scope и тут могут быть варианты, - например в HelmRelease у вас диапазон версий чарта, а та часть пайплайна, которая должна собрать и запушить в репозиторий последнюю версию чарта сфэйлилась - в итоге у вас новый имидж на старом чарте, и глядя в гит вы просто не можете понять что пошло не так. Или сервис репозитория чартов слетел и был восстановлен из бэкапа (не самого свежего), - всё консистентность окружения нарушена.
Что до сборки докер имиджа - пвторяемость сборок докер имиджей это фундаментальная проблема. Тут слишком много чего может пойти не так, - от незафиксированной зависимости в библиотеках до содержимого кэша на сборщике.
Если вы утверждаете, что ваши сборки имиджей на 100% повторяемые, то либо вы большой молодец и провели очень большую работу чтобы это было так, либо вы что-то не знаете.
Хорошей практикой чтобы гарантировать повторяемость выкатов является испоьзование так называемых "золотых имиджей", - когда мы собираем один имидж и прогоняем его через все наши окружения и именно его доставляем на продакшен. ТОлько тогда мы можем гарантировать, что доставили на прод именно то что оттестировали.
И это не учитывается в GitOps вообще никак. Даже намёка нет на накую возможность.
а та часть пайплайна, которая должна собрать и запушить в репозиторий последнюю версию чарта сфэйлилась - в итоге у вас новый имидж на старом чарте, и глядя в гит вы просто не можете понять что пошло не так.
Хуже того, может отключится электричество или упасть сеть и разобраться, что пошло не так "глядя в гит" тоже не получится.
Что до сборки докер имиджа - пвторяемость сборок докер имиджей это фундаментальная проблема.
У нас была аналогичная проблема с повторяемостью сборок (правда не образов докера а образов всего ПО маршрутизатора). Решили путём вынесения всей среды в образ докера, а сборки, соответственно, в контейнер.
Не совсем понял почему нельзя реализовать повторяемость сборок в гитопс. Например дженкинс собирает некий билд и пушит в регистри с тэгом build-1.0-b1. Используем в пайплайнах и манифестах этот имидж с этим тэгом. Собираем другой билд build-1.0-b2 и тд
Причин может быть много. В основном они связаны с подключаемыми библиотеками и внешними зависимостями.
Например в моей практике был случай, когда интеграционные тесты падали на некторых сборках. Это было потому что сборка производилась на четырёх раннерах, и на одном из них в кеше залип базовый имидж с неправильной библиотекой, который сопредельная команда собрала неправильно, потом перепушила с тем же тегом. И поймать это было ой как сложно.
Вообще я заметил что люди гитопс слишком прямо воспринимают. "У вас секреты не в гите - у вас не гитопс!".
По поводу "артефактов вне гита" вообще странный посыл. Никого не удивляют Gemfile.lock, go.mod и т.д. в репозитории для фиксации зависимостей, но вот тег докер имаджа или хелм чарта уже не канон.
Вот прям под каждым словом подпишусь. У вас же программы бинарные, а код вполне себе текстом является. Почему же тогда вас смущает docker-образ, но бинарник, полученный путём компиляции, не смущает.
Тоесть по-вашему секреты не в гите позволяют гиту оставаться единственным источником правды?
У нас база на проде отвалилась от воркеров. Гит не менялся. В чем же может быть проблема? Неучто кто-то снёс секрет в волте?
Про повторяемость сборок докер имиджей я уже писал выше. Мы не можем их гарантировать на 146%.
Ну раз вы не можете гарантировать повторяемость - тогда это к вам же вопросы, а не к gitops.
Люди бьются, чтобы у них была повторяемая среда. Чтобы их системы сборки изо дня в день выдавали один и тот же результат, а вы нивелируете их усилия своим отношением - у нас не получилось - ни у кого не получилось. Пока я это вижу и в статье и в ответах автора.
Повторяемость мы можем гарантировать с использованием концепции golden image.
Заметка была о другом. Повторяемость это краеуголный камень доставки приложений. И он полностью проигнорирован в GitOps.
И нет, это не очевидно.
Зависит от того как вы воспринимаете гитопс как концепцию. Если для вас опредление компании weaveworks является догмой - то да, секреты не в гите не позволяют быть единственным источником правды. Ещё можно вспоминать mutation вебхуки которые дополнят поля в манифестах, или OCIRepository который не гит. Да и много чего ещё. Я просто пользуюсь концепцией reconciliation loop и источника данных в гите. Как в Chef да.
Повторяемость сборок - это сложно, полностью согласен. Можно зайти чуть сбоку - собрать один раз, подписать образ с помощью cosign. И проверять на стадии деплоя (Flux это умеет делать). Всё таки чаще мы хотим задеплоить на прод тот же имадж что првоерили ранее. А не собрать ну точно такой же гарантирую это.
Очень много боли приносит fluxcd image automation bot.
Суть в том, что он как бы автоматизирует перезаписывание тегов во всяких манифестах типа такого:
apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
name: podinfo
namespace: default
spec:
images:
- name: ghcr.io/stefanprodan/podinfo
newName: ghcr.io/stefanprodan/podinfo # {"$imagepolicy": "flux-system:podinfo:name"}
newTag: 5.0.0 # {"$imagepolicy": "flux-system:podinfo:tag"}И в дальнейшем он просто создает коммит в репозиторий, в котором подменяет newName на что-то другое в соответствии с каким-то своим другим манифестом.
И вот вся эта идея превращается в минное поле: такие файлы помечаются комментарием do not edit, но по сути они превращаются в мины замедленного действия, потому что они могут быть случайно перемещены при рефакторинге, они могут быть переформатированы утилитой автоформатирования. Просто случайно по запарке быть отредактированными.
И каждый раз это приводит ко всяким чудесным неожиданностям типа мерж конфликтов. Ну это если есть несколько окружений и под каждое окружение по своей ветке. Да и в целом выходит, что описание ресурса дублируется дважды: один раз в манифесте для automation бота, а второй раз собственно в том файле, где бот автоматически перезаписывает поле.
А еще такое бывает, что даже когда нет автообновления версий, то все равно этот бот используется, просто версия на которую нужно обновить ресурс в том же самом automation манифесте и записывается. В результате обновления окружений перестают быть атомарными, получается все в две ступени:
1. Мержим в ветку окружения обновление версии в flux automation манифест
2. flux bot видит обновление в манифесте и коммитит в эту ветку само обновление ресурса.
С этим есть проблема, что если он не сможет выполнить второй шаг, то первая часть то применится.
Короче говоря, как-то все это очень хрупко и проблемно выглядит. Ну или я совершенно не понимаю заложенных во все это принципов и идей.
По своему опыту могу лишь сказать что отдельный бранч для окружения делает сильно больно и неудобно. Теряется видимость. Могу порекомендовать попробовать подход с kustomize overlays. Либо генерация ямлов из верхнеуровневой абстракции, но опять таки в одном бранче всё.
Почему у вас дублирование и опасность при перемещении не очень понятно пока. Если можно пример будет понятнее.
После прочтения не покидает ощущение, что статья является не критикой gitops, а антирекламой flux.
Как уже выше заметили - наличие registry не отменяет принципа единого источника правды. Просто некоторые системы понимают один формат, в некоторые он другой и, соответственно, внедрение некой подписи выглядит как достойное расширение - есть коммит в git - он подписан ключем maintainer, далее по цепочке "подписываются" или тегируются артефакты. И вот у вас есть стройная цепочка. Главное, чтобы CD сам в Git не лез.
Мысль в статье явно не окончена, хотелось бы увидеть следующие части. Вроде как оттенок у статьи негативный, при этом содержимое - просто рассказ про то, как это работает. Как пользователь и пропагандист GitOps/Flux с опытом, могу сказать, что все описанное - вполне себе преимущества данного подхода. Поэтому хочется услышать в чем все-таки автор видит проблемы и какие предлагаются альтернативы. Спасибо за статью!
И если GitOps — это в первую очередь история про инструментарий
И вот здесь все пошло наклонной. Сам подход "git - источник правда" очень хорош. Но workflow у всех разный. И может так случиться, что для вашей реализации подхода GitOps больше подойдут совсем другие инструменты. Если вы чувствуете, что реализация GitOps у вас идет со скрипом, попробуйте остановиться и подумать "правильные ли инструменты я использую".
Сам подход "git - источник правда" очень хорош.
Подход хорош только на бумаге. Но если реализовать его только частично (чарт, имидж, секреты вне гита), то источник правды получается очень посредственный. Плюс получается очень много затрат на его реализацию.
Не проще ли принять то, что мир не идеален и попытаться сделать то же самое более лёгким и простым путём?
Об этом во второй части статьи.
попытаться сделать то же самое более лёгким и простым путём?
Так и я о том же. Выберите инструменты по душе.
Не проще ли принять то, что мир не идеален
Смотря что вы под этим имеете в виду. В моем опыте подход "git - источник правды" работает отлично. Всегда есть артефакты, контейнеры и виртуалки. Но они все собраны из кода и конфигов в гите. Всегда можно понять, из какого тега или коммита мы их получили. Меня спрашивают "Откуда это?". А я в ответ - ссылку на репу. А там и коммит, и комментарий, и номер тикета. А в тикете и описание, и заказчик, и исполнитель. А еще ссылка на pull request с review. Сразу весь контекст.
Если где-то что-то сделано руками по уважительной причине, человеку говорят "Молодец. А теперь реализуй это в гите и собери оттуда". Не все моменты можно решить техническими средствами. Иногда нужно просто напоминать людям, чтобы они соблюдали соглашения.
Хотя может быть, вы не эту проблему пытаетесь решить. Может быть, вам больше актуальна непрерывная доставка?
Чтобы Git оставался единственным источником истины, нужно Docker образы маркировать тэгами равными Git commit hash. Helm chart можно вообще генерить на ходу CICD pipeline, а после деплоя выбрасывать.
Не всё так просто. Кейс из практики:
Мы тегировали имидж по git commit hash, запушили его в registry, потом была автоматическая чистка регистри от образов старше полугода. Спот ноды, на которых крутилось приложение перезаказались и новые поды тупо не смогли подняться. Мы повторяем сборку этого имиджа, но в коде есть незафиксированная транзитивная зависимость от библиотечки, которая за пол года стала несовместима с текущими вызовами и часть функционала приложения просто ломается.
Так тут у вас проблема в другом - у вас мастер сломан билд не работает уже полгода. Gitops здесь не при чем и никак эту проблему решать и не должен
Отсутствие внешней библиотеки относится к внешним, неконтролируемым факторам. Это все равно, что заявлять, что Gitops - плохой, потому что не помог при отключении интернета и падении астероида
Плюс фактор самостоятельного отстрела себе ног. Используйте доп тэг latest и чистите старые имажи если они не latest. И ваши волосы станут мягкими и шелковистыми
Да это просто пример, иллюстрирующий что гит - плохой источник истины, если он не имеет связи с артефактами.
Два запуска сборки артефакта на одном комите могут дать совершенно разные результаты. Причин может быть тысяча - от незафиксированных зависимостей до кешей на сборщике.
И в гиотпс нет рецепта как сделать его хорошим источником истины.
Это нужно понимать чтобы выстроить качественный, стабильный процесс доставки программного обеспечения.
Git - это лучший источник истины. Другого лучше пока не придумали. Ну разве только что может быть блокчейн? Попробуйте подстроить его под нужды девопс, посмотрим.
Мир изменчив, гит не может сохранить все детали реализации вселенной вокруг себя.
Вывод - гитопс плохой, да здравствует CIops (во второй части статьи).
По моему, это какой-то детский идеализм, который не помогает продукту работать и приносить прибыль.
Используйте доп тэг latest и чистите старые имажи если они не latest
А можно подробнее пожалуйста? Звучит очень удобно, но я не понимаю как такое сделать
Вот запушил я после сборки имадж под двумя тэгами: myimage:mytag-123 и myimage:latest
Дальше я хочу удалить предыдущие 122 имаджа (тэга), как понять что они не latest, а вот mytag-123 - latest?
Дайджесты сравнивать?
Короче вопрос такой: надо самому что-то выдумать или есть готовые и простые решения?)
Всё становится сильно проще, если убрать из цепочки helm или хотя бы добавить промежуточный стейт репозиторий с плоскими отрендеренными манифестами, на который смотрит Флакс/арго
Helm слишком удобный и популярный инструмент чтобы его убирать. Можно рендерить тимплейты из чарта и ложить их в инфраструктурный репозиторий, но тогда мы лишаемся как минимум хелм хуков и функции lookup. Проще убрать из цепочки gitops.
Или проще убрать лукапы и хуки. Очень легко аргументировать, когда волен задавать все вводные и подбирать те определения, которые удобнее.
Хелм это всего лишь sed на стероидах. Гиперусложнен и избыточен. Без него процессы поставки сильно упрощаются.
Я бы сказал что для полноценного GitOps требуется очень высокая зрелость ИТ в компании, нужно что бы разработчики сами были и dev и ops и sre и так далее, для того что бы использовать прям GitOps GitOps.
Я предпочитаю смешанный подход, когда мы работаем вокруг git, но без чрезмерной абстракции и всяких модных и порой лишних (на мой взгляд) инструментов.
Спасибо за статью, но у нее есть один существенный недостаток. Она не отвечает на тот вопрос, который выносит в заголовок.
Создается впечатление, что вы пытаетесь понять что такое GitOps, но сами для себя не можете это сделать. На мой взгляд это происходит потому, что вы изначально ограничиваете себя только техническими соображениями и не допускаете, что причиной может выступать что то еще. Технические детали важны и технические соображения приведенные вами верны, но в данном случае они не являются существенными.
GitOps, как и микросервисная архитектура, появились и быстро закрепились в индустрии потому, что решают управленческую задачу. Они позволяют создать в компании условия, при которых технические границы повторяют границы административные, разграничивая ответственность между отдельными командами и даже отдельными людьми. Как следствие, достигаются несколько целей. Например, снижается сложность управления людьми, а так же повышается прозрачность процессов. Что в итоге при правильном использовании выражается в деньгах.
Если быть конкретным, GitOps позволяет рассматривать процесс CI/CD как два независимых процесса, с разными зонами ответственности. И тем самым решить извечную боль всех сисадминов и программистов, когда вторым через систему автоматизации постоянно необходимо так или иначе предоставлять администраторский доступ к продакшену. Даже если это происходит не явно, границы ответственности тут несколько размыты и не могут быть жестко проведены. Используя GitOps, мы имеем отдельно CI процесс и отдельно CD процесс, причем их можно рассматривать как различные и не связанные во времени и пространстве. Команда эксплуатации и инфраструктуры, которая отвечает за Kubernetes, может спать спокойно не опасаясь, что кто то скопировав из системы автоматизации токен начнет "только на пять минут, очень надо" производить миграцию базы данных, менять конфигурацию системы и так далее. Причем это изменение никак в коде не отразится и о нем никак узнать будет нельзя.
У вас неверное понимание определений CI CD. Это достаточно частая ошибка, и в начале статьи я специально дал их каноническое определение со ссылкой на источники. Поскольку они появились задолго до GitOps, нет нужды их пересматривать.
Что до обещаний улучшенной безопасности GitOps, это я рассмотрю этот вопрос во второй части статьи. Опубликую на следующей неделе.
Обычно, когда находят ошибку в рассуждении, дают понять человеку где же именно он ошибся и что в его рассуждениях не верно. Это считается хорошим тоном и уважением к собеседнику. И ни в коем случае не ссылаться на свою же статью, с которой собеседник очевидно не согласен. Я с таким же успехом могу предложить вам перечитать мой коментарий. Вашу статью я прочитал и вынужден заключить, что содержательного подхода там не содержиться, по крайней мере для меня. В любом случае, вы имеете право на свое мнение.
А теперь по существу. Вы действительно думаете, что раз данные определения и принципы не эволюционируют, не изменяются, и не обретают порой иное, иногда даже противоположное изначальному содержание?
Вам привели в коментариях пример FluxCD Image Automation controller, где слепое следование принципу Single Source of State приводит к абсурду и я не вижу причин разворачивать это еще больше. Считать за истину этот принцип сегодня может только тот, кто не работает с реальными системами в боевых окружениях и не понимает всю возникающую проблематику и ньюансы. Уже почти все интерпретируют GitOps шире и не загоняют сами себя в ненужные рамки, прикрываясь устаревшими понятиями. Хотя нужно признать, что одно это не делает эти понятия плохими. В свое время они являлись важными вехами в становлении и развитии нашей профессии. Вы цепляетесь за устаревшую концепцию и, указывая на это, хотите доказать, что она не работает. Но дело в том, что практическая деятельность уже давно решила эту проблему и сегодня никто уже не использует GitOps в контексте "Гит как единственный источник правды", только если он по какой то причине не продолжает цепляться за догмы. Ибо не нужно.
Прошу прощения если мой комментарий вас обидел. Давайте поясню.
Не стоит путать концепцию 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, но сами для себя не можете это сделать.
Вышла вторая часть и в ней есть вывод что такое гитопс по моему мнению.
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. (Здесь всё понятно? Перевод нужен?)
Тоесть под названием гитопс вам фактически продают тулинг. Просто ещё один способ что-то задеплоить.
Если кто-то считает, что он хорошо подходит на его процессы - это нормально. Но ни о каком прорыве/серебряной пуле речи не идёт.
Что такое GitOps и почему он (почти) бесполезен