Что такое GitOps на основе агентов и чем он отличается от CI/CD?

GitOps — это методология разработки, которая рекомендует использовать файлы с версиями в репозиториях системы управления версиями для определения и управления вашей инфраструктурой. Представление вашей архитектуры в виде декларативных файлов дает возможность проверить текущую конфигурацию вашей системы, объединить изменения от нескольких участников и откатиться к более раннему состоянию.

Пока что этот подход похож на Infrastructure as Code (IaC). Однако GitOps — это больше, чем просто IaC: успешная реализация будет включать автоматизированный механизм для применения файлов конфигурации к работающим компонентам инфраструктуры. Слияние изменений должно привести к переходу состояния вашей инфраструктуры в состояние, описанное измененным содержимым репозитория.

Для этого требуется мост между вашей платформой управления исходным кодом и поставщиком инфраструктуры, позволяющий передавать текущее состояние между ними. Существуют различные способы реализации этого моста, каждый из которых возлагает уникальный набор обязанностей на задействованные платформы. В этой статье мы рассмотрим модель развертывания на основе агента (или на основе запроса), а затем сравним ее с подходом, основанным на принудительной рассылке.

Что такое агент?

GitOps на основе агента относится к запуску процесса внутри вашей инфраструктуры, который облегчает развертывание. Процесс отвечает за поддержание связи с платформой управления исходным кодом, на которой размещены ваши файлы IaC.

Агент — это активная часть вашей инфраструктуры. Он будет периодически подключаться к вашему репозиторию Git, проверять наличие изменений и добавлять новые коммиты в вашу среду развертывания. Затем агент предпримет действия, чтобы применить извлеченные изменения к своему окружению, инициируя соответствующий переход состояния.

Агенты могут предоставлять дополнительные функции, такие как встроенный мониторинг развертывания, ведение журнала и оповещение. Они постоянно информируют вас о деятельности в вашей инфраструктуре. Агент обеспечивает интеграцию с вашими существующими инструментами для отображения соответствующей информации в соответствующих местах.

Модель агента отличается от традиционного взгляда на непрерывную интеграцию и непрерывное развертывание (CI/CD) тем, что в ней отсутствует концепция конвейера, привязанного к триггеру. Вместо этого существует автоматический цикл согласования, который извлекает изменения по мере их появления. Новые коммиты и слияния только косвенно вызывают изменения в вашей инфраструктуре. Прежде чем агент получит новые данные, может пройти некоторое время.

Несколько поставщиков предлагают агенты, которые можно использовать для реализации рабочих процессов GitOps. GitLab теперь поддерживает этот подход как предпочтительный способ развертывания в Kubernetes через агент GitLab для Kubernetes. Агент подключается к экземпляру GitLab из вашего кластера, а затем обеспечивает двустороннюю связь для развертывания изменений и отправки информации обратно в ваши репозитории.

Flux от Weaveworks — это еще один вариант, который работает с любым репозиторием Git и включает возможности оповещения. Flux теперь является проектом-инкубатором в рамках Cloud Native Computing Foundation (CNCF). Он работает как оператор Kubernetes, который получает изменения, внесенные в ваши подключенные репозитории Git.

Преимущества агента

GitOps на основе агентов имеет множество преимуществ, которые делают его привлекательным для различных заинтересованных сторон. Во-первых, существует четкое различие между обязанностями: ваша платформа управления исходным кодом неизменна, и ей не нужно заниматься подключением к вашей инфраструктуре. Агент должен быть снабжен учетными данными репозитория, но в остальном он самодостаточен. После запуска он узко сосредоточен на обнаружении и применении изменений.

Такое разделение проблем может помочь вам точно определить проблемы и причины сбоев при развертывании. Как правило, вы можете сразу отказаться от платформы управления исходным кодом. Если он работает и ваша основная ветвь содержит правильные изменения, расхождения в фактическом состоянии вашей инфраструктуры должны быть связаны с проблемой синхронизации агентов.

Агенты также предлагают более высокую степень автоматизации, чем GitOps на основе push-уведомлений. Чтобы успешно внедрить поток на основе push, вам необходимо настроить репозиторий с учетными данными для вашей инфраструктуры и создать конвейеры CI, которые запускают правильные сценарии для передачи ваших изменений. Эти сценарии нужно будет копировать во все ваши проекты, поддерживать с течением времени и тщательно обрабатывать для защиты ваших конфиденциальных учетных данных.

Системы на основе агентов лишены этих проблем. После установки агента вы получаете выгоду от надежной модели развертывания, которая менее подвержена изменениям. Существует гораздо меньше переменных, связанных с подключением к репозиторию Git, чем с успешным доступом к производственной среде, такой как кластер Kubernetes. Следовательно, имеет смысл перенести изменения из более простой системы в более сложную.

Еще одним преимуществом является положительное влияние агентов на безопасность. Они работают внутри вашей инфраструктуры, поэтому вы можете избежать доступа к ней извне. Хотя вам нужно будет предоставить доступ к вашему репозиторию Git, это гораздо менее рискованно, чем предоставление двери в вашу производственную среду. Воздействие токена проекта GitHub может привести только к утечке исходного кода и ваших файлов IaC — серьезное событие, но оно меркнет по сравнению с мыслью о потере токена рабочей учетной записи Kubernetes. Это может привести к краже данных, последующему вымогательству и необратимой компрометации системы.

А как насчет GitOps на основе push?

Альтернативной стратегией является модель на основе push-уведомлений, при которой изменения передаются в вашу инфраструктуру вашей платформой управления исходным кодом или промежуточной системой. Связь инициируется чем-то, работающим за пределами среды развертывания. Push-сообщения заставляют инфраструктуру получать новое состояние от управляющего сервера.

GitOps на основе push обычно реализуется в ваших конвейерах CI. Вы используете эту модель, если у вас есть конвейер, настроенный для подключения к кластеру Kubernetes, и вы используете kubectl apply для создания развертываний. Другой пример — конвейер, который запускает rsync для синхронизации содержимого вашего репозитория с удаленным хостом.

Ограничения этого подхода заключаются в его неспособности предложить преимущества, связанные с агентами, которые мы рассмотрели выше. Вам необходимо вручную настроить каждый репозиторий с соответствующим подключением к инфраструктуре, открыть свои среды для внешнего доступа и взять на себя ответственность за поддержку сценариев развертывания с течением времени.

Однако GitOps, основанный на push-уведомлениях, по-прежнему имеет некоторые уникальные преимущества. Одним из важных факторов является его привычность: вы можете продолжать использовать инструменты, которые вы уже знаете и на которые опираетесь при разработке, такие как kubectl, helm и docker. Это помогает свести к минимуму различия между локальным и оперативным развертыванием.

Обработка ошибок также может быть проще. Подходы, основанные на выталкивании, как правило, кажутся более синхронными, что может быть полезно для определения последовательности событий, ведущих к сбою. Хотя агенты дают вам четкую отправную точку (сам агент), вам остается фильтровать события, соответствующие действиям этого агента. Эти мероприятия могут охватывать десятки различных проектов и циклов согласования. Таким образом, возможность начать с определенного запуска конвейера CI может быть полезна для обеспечения немедленной обратной связи во время отладки.

Наконец, есть аргумент, что модель на основе push на самом деле лучше адаптируется к будущим изменениям инфраструктуры. Внедрение Pulls означает, что вы связываете свою систему с конкретными ожиданиями выбранного вами агента. Это может быстро усложнить ситуацию, если вам нужно выполнить развертывание на новой платформе, где этот агент не поддерживается. Сценарий Push-подхода здесь более гибкий. Это позволяет вам обслуживать несколько различных сред за счет включения условной логики, которая выполняет правильные действия для целевой платформы.

Краткое содержание

GitOps на основе агента относится к запуску активного компонента в вашей инфраструктуре, который обращается к исходному репозиторию для извлечения и применения изменений. Это инвертирует модель на основе Push, в которой вы запускаете сценарии в конвейерах CI для создания развертываний и применения изменений состояния.

Рабочий процесс Push распространен, легко понятен и имеет некоторые важные преимущества. Однако управляемые агентами «вытягивания» привлекают все больше внимания в облачной экосистеме, поскольку поставщики и разработчики начинают осознавать их преимущества.

Принятие подхода на основе извлечения может сократить время обслуживания, повысить безопасность ваших сред и помочь вам выявить сбои, когда изменения не применяются. Агенты также могут упростить настройку периферийных функций, таких как оповещения и агрегирование метрик, ускоряя процесс внедрения DevOps без ручного создания сложных сценариев непрерывной интеграции.