GitOps — голый император?
27 января 2023 г.Горячий взгляд 🔥🔥 из доброго места.
Прежде чем я начну метать искры, я хочу прояснить, что я думаю, что есть много преимуществ в том, чтобы записывать все в виде кода в гите. Статические определения, рецепты и спецификации того, как мы делаем наше программное обеспечение, полезны во всех отношениях. 🌈
Однако эти определения нам не помогают понять нашу динамическую среду, и это моя основная проблема с GitOps. В отношении GitOps делается много заявлений — он предлагает лучшую безопасность, исторические записи и решение для дрейфа и согласования. Я задаюсь вопросом, правда ли что-либо из этого, и в этой статье я объясню, почему.
GitOps заставляет меня вспомнить старую сказку Ганса Христиана Андерсена о том, что реально, а что выдумано. Император заявляет, что он одет, но что, если на самом деле он вообще ничего не носит?
Что такое GitOps?
Прежде чем мы углубимся, давайте установим базовый уровень для того, что мы называем GitOps на основе четырех принципов плетения
- Вся система описывается декларативно.
- Каноническое желаемое состояние системы задается в Git.
- Одобренные изменения, которые могут быть автоматически применены к системе.
- Программные агенты для обеспечения правильности и оповещения о расхождениях.
Как и в agile-манифесте, эти четыре принципа довольно легко принять. Но, как и в случае с agile, самое интересное — превратить теорию в практику.
Как выглядит GitOps на практике?
В основе Gitops лежит идея непрерывной работы программных агентов для сближения состояния системы с желаемым состоянием.
Итак, как согласовать эти состояния, используя типичный подход GitOps?
Мы устанавливаем оператора (или агента) в наш кластер, который «вытягивает» (подробнее об этом позже) желаемое состояние из репозитория git config, принимает решения и соответствующим образом корректирует рабочие нагрузки.
Это предлагается в качестве альтернативы стандартному конвейеру DevOps, который «проталкивает» изменения в кластер:
Итак, мы изложили теорию и описали базовую практику. Теперь о преимуществах GitOps. Как они материализуются, когда мы начинаем внедрять?
Дополнительная безопасность с GitOps? 🧐
Во-первых, добавлена безопасность. В чем преимущество подхода «на основе извлечения» по сравнению с простым внесением изменений в наш кластер? Основное преимущество GitOps в том, что ваш CI-сервер не имеет производственного доступа, поэтому мы можем сказать, что это повышает нашу безопасность.
| | Традиционный | DevOps | GitOps | |----|----|----|----| | Инфраструктура | Императив | декларативный | декларативный | | Желаемое состояние | Неотслеживаемый | Версия | Версия | | Утверждения изменений | Билеты | Запросы на вытягивание | Запросы на вытягивание | | Развертывания | Руководство | событие КИ | + Оператор GitOps | | Безопасность | Руководство | Секреты в КИ | + секреты инфры |
Однако действительно ли в этой настройке есть какая-то дополнительная безопасность? Если система CI может обновлять конфигурации, как GitOps предотвращает развертывание мошеннических рабочих нагрузок злоумышленником, имеющим доступ к CI? 🤔
История версий и среды
Еще одним важным преимуществом GitOps является история версий для среды. Это отчасти правда, но вы также получаете это со старым простым DevOps, предполагая, что ваш конвейер и информация о развертывании находятся в исходном репо. Эта история полезна, но она не является точной записью того, как на самом деле изменилась окружающая среда (подробнее об этом позже).
Откат
Проще ли откат с помощью GitOps? Я считаю, что вам лучше использовать обычный старый DevOps, просто отменив коммит. Преимущество здесь в том, что он делает откат стандартным рабочим процессом разработчика и версионирует исходный репозиторий. Что-то не работает? Просто git вернуться
Аварийное восстановление
Что происходит, когда весь ваш кластер выходит из строя? Что происходит, когда вы хотите создать новый кластер? Это справедливые вопросы. Но большинство команд не развертывают сине-зеленые кластеры. Большинство компаний имеют статический кластер/кластеры. В большинстве случаев аварийное восстановление не будет затруднено из-за необходимости запуска конвейеров развертывания, и я думаю, что это должно быть написано в сценарии без использования GitOps.
Так что да, я скептически отношусь к преимуществам. Но у меня больше сомнений, когда мы начинаем рассматривать компромиссы, на которые нам приходится идти при реализации GitOps. Давайте посмотрим на них.
Проблемы с GitOps
Первое большое вызов с GitOps — это эффект, который он оказывает на наши пайплайны. Отделение развертывания от более ранних этапов конвейеров приводит к тому, что они становятся распределенными. С точки зрения потока создания ценности это затрудняет понимание общего пути от фиксации до производства. Он отделяет более ранние этапы квалификации от более поздних.
Это важно, потому что исключает обратную связь с разработчиком из потока создания ценности. В этой настройке, если развертывание завершается сбоем, откуда приходит обратная связь? Как разработчики получают информацию о процессе развертывания? Как они могут улучшить процесс развертывания с помощью собственных уведомлений? Как они могут улучшить процесс развертывания?
Второй побочный эффект заключается в том, что разделение этих этапов на два набора инструментов увеличивает разрыв между разработкой и эксплуатацией.
Обычно инструменты GitOps запускаются и управляются центральной командой платформы. Часто система CI находится в ведении команды. Как сказал маршал Маклюэн: «Мы формируем наши инструменты, а затем наши инструменты формируют нас».
Разрыв увеличивается еще больше благодаря использованию отдельного репозитория конфигурации для хранения желаемых состояний:
Обычно репозитории git сосредоточены вокруг отдельных микросервисов с отдельным общим репозиторием для описания желаемого состояния сред. Один ориентирован на код и разработчиков, другой — на операции. Кроме того, нередко приходится писать сценарии связующего конвейера для обновления репозитория конфигурации.
Пересмотр push- и pull-запросов
Основное нововведение в GitOps, по-видимому, заключается в переносе операций на модель, основанную на вытягивании. Это кажется большим изменением, но при ближайшем рассмотрении я не думаю, что это правда. [Спасибо моему хорошему другу Хенрику Хёгу за то, что разъяснил мне это]
Как правило, оператор GitOps считывает конфигурацию из репозитория git, применяет к ней преобразования «ноль ко многим», а затем отправляет ее на сервер API kubernetes. Это именно то, что делает ваш инструмент развертывания в модели, основанной на push-уведомлениях! С помощью GitOps мы распределяем наш конвейер по двум асинхронным инструментам, используя репозиторий git в качестве семафора, но при обоих подходах мы отправляем изменения в наш кластер.
Она отлично подходит для Drift and Reconciliation, верно?
Еще одним важным преимуществом GitOps является цикл согласования — автоматическое исправление любого дрейфа или ручное изменение. Любые недокументированные изменения стираются, а среда согласовывается с определением git.
На первый взгляд, это кажется огромным бонусом. Однако я тоже придерживаюсь другого взгляда на это. Прежде чем мы перейдем к согласованию незадокументированных изменений, мы должны спросить, почему они вообще произошли. Может быть, мы не хотим, чтобы они помирились? Для внесения изменений вручную может быть очень веская причина, и мы можем не захотеть, чтобы среда восстанавливалась автоматически.
Другой причиной может быть саботаж, и в этом случае мы определенно хотим, чтобы люди участвовали в расследовании и управлении ситуацией. В любом случае дрейф конфигурации должен привести к надлежащему процессу управления инцидентами, а не к простому сообщению из цикла согласования, которое исчезнет в эфире.
А с технической стороны, мне кажется, в Kubernetes уже есть цикл согласования. Вы описываете свои развертывания и конфигурацию декларативно, и задача Kubernetes — сделать это правдой. Многоуровневые циклы согласования кажутся излишне сложными.
Репозиторий карты git не является территорией
Нам нравится думать, что репозиторий git config эквивалентен тому, как все меняется, но на самом деле существует разрыв между этими статическими определениями и тем, что на самом деле происходит в динамической автоматизации DevOps. Все эти разговоры о том, что GitOps предоставляет «единый источник правды», просто не соответствуют действительности. Если я хочу узнать, что на самом деле происходило в четверг вечером, нет простого способа добраться туда.
Конфигурация GitOps не дает информации о ручных изменениях, событиях масштабирования, неудачном согласовании и многих других пограничных случаях. Эти типы событий вызывают инциденты, но GitOps не обеспечивает ситуационную осведомленность, когда они происходят.
Когда происходит инцидент, нам действительно нужно понять, как все на самом деле изменилось. Большая проблема с современными GitOps заключается в том, что у разработчиков и операционных групп практически нет достоверных записей о фактических происходящих изменениях. Нам нужно четко понимать, что желаемые состояния не являются фактическими состояниями.
Статическое представление изменений полезно, но имеет ограничения
Я начал с того, что полностью за размещение рецептов, определений и спецификаций для желаемого DevOps в системе управления версиями. Он предлагает нам всевозможные преимущества. Давайте напомним себе, что они из себя представляют:
* Повышенная прозрачность: возможность делиться, проверять и проверять с помощью знакомой технологии. * Инструменты и рабочие процессы кода: позволяет использовать подходы на основе ветвления/запроса на включение для интеграции изменений. * Лучшее качество: позволяет добавлять линтеры, средства проверки и статический анализ в процессы автоматизации, а также обеспечивает согласованность изменений. * Неизменяемость: помогает свести к минимуму дрейф конфигурации. * Централизация: может помочь уменьшить «разрастание конфигурации»: конфигурация процессов распределена по нескольким неподключенным системам
Пока все хорошо, но у каждого статического определения есть динамическое выполнение. Происходят реальные события, асинхронно и автоматически, результаты которых нам нужно записывать и понимать.
| Статическое определение | Динамическое исполнение | |----|----| | Скрипт сборки | Составление/упаковка | | Набор тестов | Тестовые прогоны | | Файл развертывания | Развертывания | | Докер-файл | Сборка образа Docker | | Модель инфраструктуры | Изменения в инфраструктуре |
Динамичный мир буквально там, где происходит действие. Разработчикам нелегко вернуться от определения GitOps к событиям, изменениям, порядку и зависимостям.
Если вам все еще интересно, почему это важно, в книге Google SRE говорится, что "70 % сбоев вызваны изменения в живой системе». Поэтому, когда что-то пойдет не так, мы должны искать ответы в динамичном мире в первую очередь.
Выводы. Кто такой GitOps?
Как и в agile-манифесте, расплывчатое определение GitOps означает, что его можно и нужно применять самыми разными способами. Широкий церковный подход — это идеальная хитрость для ботаников. Является ли Terraform GitOps? Может быть? Я не знаю!
И, как и в Agile, все сталкиваются с FOMO. Что, если это будет следующая большая вещь? Мы прыгаем на подножку из страха остаться позади? Что касается agile, нам нужно спросить: «Кто такой agile?» Может быть, нам нужно спросить: «Кто такой GitOps?» Как всегда, нам действительно нужно задать себе вопрос: кому мы служим с помощью этих инструментов и какие проблемы мы пытаемся решить?
В конце «Новой одежды императора» люди вокруг императора продолжают хвалить его новый наряд, хотя и понимают, что он совершенно голый. Это неловкая ситуация, в которую может попасть любой из нас, когда мы делаем все возможное и хотим, чтобы это было правдой. Как ребенок в толпе, который кричит: «Но на Императоре вообще ничего нет!» иногда полезно все упростить, просто сказав, что вы видите.
Оригинал