Внедрение GitOps для доставки нативных облачных приложений

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

Теперь есть новый вид операций.

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

Что такое GitOps?

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

Термин GitOps был ограничен Weaveworks в 2017 году и в первую очередь был направлен на управление развертыванием Kubernetes. Однако теперь он превратился в поддержку других решений для управления инфраструктурой, таких как Terraform.

Цель GitOps — упростить и оптимизировать процесс разработки. Это приводит к созданию воспроизводимой инфраструктуры с надлежащим управлением состоянием, которая одновременно:

• Увеличивает общую видимость
• Снижает накладные расходы на управление инфраструктурой приложений

GitOps позволяет разработчикам или команде Ops объявлять свою инфраструктуру как код и управлять версиями через Git. Всякий раз, когда требуется новое изменение, создается запрос на вытягивание с новым изменением, выполняющий конвейер CI / CD для подготовки или изменения инфраструктуры.

Кроме того, GitOps предлагает пользователям гибкость для выбора любого инструмента, технологии или платформы и использования тех же методов DevOps при создании инфраструктуры.

Принципы GitOps

Есть несколько основных принципов, которые применяются при реализации и работе с GitOps. Давайте взглянем.

Декларативная система

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

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

Состояние системы контролируется версиями в Git

Все декларативные состояния хранятся в системе с контролем версий, которая действует как единственный источник истины. При таком подходе с управлением версиями все изменения инфраструктуры системы доступны в хронологическом порядке, что позволяет пользователям легко определять изменения инфраструктуры с течением времени. Это также полезно при:

• Исправление проблем
• Аудит
• Откаты

Изменения применяются автоматически после утверждения

Когда выполняется запрос на вытягивание или слияние, он будет проверен, а затем утвержден, поскольку все изменения хранятся в Git.

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

Преимущества подхода GitOps

GitOps позволяет организациям оптимизировать стратегии предоставления инфраструктуры и развертывания приложений. Это приводит к широкому спектру преимуществ /

Легкость управления инфраструктурой

GitOps позволяет пользователям легко управлять инфраструктурой как частью общего процесса DevOps, быстро тестируя и развертывая изменения с помощью:

• Инструменты CI / CD
• Автоматическое развертывание
• Более короткие петли обратной связи

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

Повышенная продуктивность

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

Это приводит к повышению продуктивности как разработчиков, так и команды эксплуатации, что в конечном итоге приводит к ускорению разработки и развертывания.

Повышенная надежность и стабильность

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

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

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

• Легко определить такие отклонения между заявленной инфраструктурой и реальной инфраструктурой.
• Быстро смягчите их

Стандартизация

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

• Сквозные рабочие процессы
• Стандартизированные структуры кода
• Документация
• Методы тестирования

Это вводит стандартизованные и полностью воспроизводимые конфигурации инфраструктуры.

Повышенная безопасность

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

• Ответственные пользователи
• Время развертывания данных
• Затронутые ресурсы
• И т.п.

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

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

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

Как реализовать GitOps

Если в вашей организации уже есть правильно реализованный конвейер DevOps с использованием Git в качестве инструмента SCM, внедрение GitOps для покрытия инфраструктуры — довольно простой процесс. Просто:

1. Добавьте код инфраструктуры в репозиторий Git.
2. Настройте конвейер CI / CD, чтобы включить репозиторий инфраструктуры как часть конвейера доставки.

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

• GitHub
• BitBucket
• Azure Repos
• GitLab
• И т.п.

Затем идет конвейерная платформа CI / CD, которая сводится к вашим предпочтительным и знакомым инструментам платформы. Такие инструменты, как Jenkins и CircleCI, можно использовать с любым репозиторием git. BitBucket Pipeline и GitLab Pipelines предпочитают собственные репозитории кода. Какой бы ни была выбранная платформа конвейера, его основная цель будет заключаться в следующем:

• Автоматизируйте процесс доставки.
• Обеспечьте четкий рабочий процесс между репозиторием Git и платформой управления инфраструктурой.

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

• Оператор Kubernetes
• Облачный оператор Terraform
• Оператор службы Azure
• И т.п.

Рабочий процесс GitOps

Теперь у нас есть репозиторий Git и правильно настроенный конвейер CI / CD. Инженер инфраструктуры:

1. Объявите инфраструктуру как код.
2. Отправьте код в репозиторий Git.
3. Создайте запрос на перенос.

После этого этот код может быть рассмотрен и изучен другим членом команды и, наконец, утвержден, что запускает конвейер CI / CD. Затем конвейер сообщит об этом оператору Git, который примет все изменения и желаемое новое состояние.

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

Если состояния разные, он будет беспрепятственно организовать и подготовить базовую инфраструктуру в соответствии с желаемым состоянием.

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

Пример GitOps

Давайте возьмем реальный сценарий GitOps, где веб-приложение развертывается в облачной среде.

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

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

Это запускает конвейер GitOps CI / CD и инициализирует оператор git. Затем оператор git сравнит состояния. Эта новая конфигурация идентифицирует это как изменение состояния и автоматически настраивает базовую инфраструктуру в соответствии с желаемым состоянием.

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

Но что произойдет, если развертывание не удастся или ошибка конфигурации вызовет проблемы с сетью?

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

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

Оптимизированные автоматизированные конвейеры

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