Понимание принципов OpenGitOps для улучшения рабочих процессов программного обеспечения

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

Роль Git как единственного источника правды подразумевается терминологией. Однако фактическая реализация процессов, управляемых GitOps, исторически была открыта для интерпретации. Эта двусмысленность теперь разрешена стандартами OpenGitOps, попыткой, поддерживаемой CNCF, определить принципы, которые приводят к воспроизводимым системам GitOps.

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

1. Декларативное состояние

Первый принцип гласит, что все системы, управляемые GitOps, должны иметь декларативное выражение своего состояния. Вы должны определить, как выглядит идеальное состояние в настоящий момент времени, вместо того, чтобы давать конкретные инструкции о том, как собрать это состояние.

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

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

Декларативная конфигурация обычно используется с инструментами «инфраструктура как код», такими как Ansible и Terraform. Вы пишете файлы конфигурации, которые определяют компоненты инфраструктуры, которые вы хотите сделать доступными. Инструменты преобразуют ваши объявления в вызовы и команды API, которые предоставляют необходимые ресурсы. Платформа оркестрации контейнеров Kubernetes — еще один пример декларативной системы.

2. Версии и неизменяемость

Второй принцип OpenGitOps гласит, что состояние вашей системы должно иметь полную версию на протяжении всего ее жизненного цикла. Именно здесь Git действительно вступает в игру, позволяя вам фиксировать ваши файлы конфигурации, объединять изменения, внесенные другими соавторами, и изменять свое состояние с течением времени.

В сочетании с декларативными определениями состояния управление версиями дает вам гарантированный способ отката системы, если что-то пойдет не так. Проверка более старой фиксации и повторное применение файлов конфигурации вернет систему в ее состояние на тот момент времени.

Хранение состояния таким образом также помогает обеспечить неизменность. Единственный метод внесения изменений в вашу инфраструктуру должен заключаться в модификации файла в вашем репозитории. Следуя этому принципу, вы можете утверждать, что состояние системы фактически отражает объявления в вашем исходном коде. Следует избегать изменения состояния путем прямого изменения компонентов вашей инфраструктуры, поскольку это приведет к несоответствию между реальным состоянием системы и «желаемым» состоянием в вашем репозитории управления.

3. Агенты по запросу

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

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

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

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

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

4. Постоянное примирение

Последний принцип OpenGitOps касается непрерывной сверки. Это возможно благодаря комбинированному использованию декларативных определений состояния с агентами на основе запроса.

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

Непрерывное согласование определяет рабочие процессы GitOps как динамические процессы, которые адаптируются к изменяющимся условиям в режиме реального времени. Агенты GitOps далеки от простого развертывания «установил и забыл», агенты GitOps — это активные компоненты, которые постоянно работают для поддержания желаемого состояния. Это позволяет завершить день с уверенностью в том, что развертывание по-прежнему работает должным образом.

Заключение

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

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

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