Рабочий процесс CI/CD на основе GitOps (Flux v2)

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

В этой статье описывается, как GitOps вписывается в полный жизненный цикл изменений приложения с помощью Azure Arc, Azure Repos и Azure Pipelines. Он также предоставляет пример одного изменения приложения в управляемых средах Kubernetes с использованием GitOps.

Архитектура

На этой схеме показан рабочий процесс CI/CD для приложения, развернутого в одной или нескольких средах Kubernetes.

Чтобы скачать схемы архитектуры в высоком разрешении, перейдите на страницу Jumpstart Gems.

Репозиторий кода приложения

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

Изменения в этом репозитории вызывают конвейер PR или CI, который запускает процесс развертывания.

Реестр контейнеров

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

Дополнительные сведения см. в статье "Использование и обслуживание общедоступного содержимого с помощью задач реестра контейнеров Azure".

Конвейер PR

Запросы на вытягивание от разработчиков, сделанных в репозиторий приложений, создаются при успешном запуске конвейера PR. Этот конвейер выполняет основные контрольные точки качества, такие как линтинг и модульные тесты на коде приложения. Конвейер проверяет приложение и lints Dockerfiles и шаблоны Helm, используемые для развертывания в среде Kubernetes. Образы Docker должны создаваться и тестироваться, но не загружаться. Оставьте длительность конвейера относительно короткой, чтобы обеспечить быструю итерацию.

Конвейер CI

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

На этом этапе можно выполнять тесты приложений, которые слишком ресурсоемки для потока PR, включая:

• Отправка образов в реестр контейнеров
• Создание образов, линтинг и тестирование
• Создание шаблонов необработанных ФАЙЛОВ YAML

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

Расширение кластера Flux

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

Дополнительные сведения см. в руководстве по развертыванию приложений с помощью GitOps с Flux версии 2.

Конвейер CD

Конвейер CD автоматически активируется успешной сборкой CI. В этой среде конвейера значения, специфичные для среды, вставляются в ранее опубликованные шаблоны, и создается новый pull request в репозитории GitOps с этими значениями. Этот пулл-реквест содержит предлагаемые изменения в требуемом состоянии одного или нескольких кластеров Kubernetes. Администраторы кластера просматривают пулл-реквест и одобряют слияние в репозиторий GitOps. Конвейер ожидает слияния pull request, после чего Flux синхронизируется и применяет изменения состояния.

Репозиторий GitOps

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

Соединитель GitOps

Соединитель GitOps создает соединение между агентом Flux и конвейером GitOps Repository/CD. Хотя изменения применяются к кластеру, Flux уведомляет соединитель GitOps о каждом изменении этапа и проверке работоспособности. Этот компонент служит адаптером. Система понимает, как взаимодействовать с репозиторием Git, и обновляет статус коммита Git, чтобы прогресс синхронизации был виден в репозитории GitOps. Когда развертывание завершится (успешно или неудачно), соединитель уведомляет конвейер CD, чтобы он мог продолжать выполнение действий после развертывания, таких как тестирование интеграции.

Кластеры Kubernetes

По крайней мере один кластер Kubernetes с поддержкой Azure Arc или Azure Kubernetes Service (AKS) обслуживает различные среды, необходимые приложению. Например, один кластер может обслуживать среду разработки и качества обслуживания с помощью разных пространств имен. Второй кластер может упростить разделение сред и более точное управление.

Пример рабочего процесса

В качестве разработчика приложений Алиса:

• Записывает код приложения.
• Определяет, как запустить приложение в контейнере Docker.
• Определяет шаблоны, запускающие контейнер и зависимые службы в кластере Kubernetes.

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

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

1. Алиса изменяет шаблон развертывания, отправляет его в удаленную ветвь, называемую alice в репозиторий приложения, и открывает пул-реквест для проверки в отношении ветви main.

2. Алиса просит свою команду пересмотреть изменения.

   • Конвейер PR выполняет проверку.
   • После успешного запуска конвейера PR и утверждения команды изменения объединяются.

3. Затем конвейер CI запускается, проверяет изменения Алисы и успешно завершает выполнение.

   • Это изменение безопасно для развертывания в кластере, а артефакты сохраняются в запуске конвейера CI.

4. Успешный запуск конвейера CI активирует конвейер CD.

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

5. Команда Алисы проверяет и утверждает её пулреквест.

   • Изменение объединяется в целевую ветвь, соответствующую среде.

6. В течение нескольких минут Flux замечает изменение в репозитории GitOps и подгружает изменение Алисы.

   • Из-за изменения образа Docker потребуется обновление подов приложения.
   • Flux применяет изменение к кластеру.
   • Flux сообщает о состоянии развертывания обратно в репозиторий GitOps через соединитель GitOps.

7. Конвейер CD запускает автоматические тесты, чтобы проверить, что новое развертывание завершилось успешно и работает должным образом, как ожидалось.

   Замечание

   Для дополнительных сред, предназначенных для развертывания, конвейер CD выполняет итерацию, создавая пулл-реквест для следующей среды и повторяет шаги 4-7. Многим процессам может потребоваться дополнительное утверждение для более рискованных внедрений или сред, таких как изменение, связанное с обеспечением безопасности, или эксплуатационная среда.

8. Когда все среды получили успешные развертывания, конвейер завершается.

Дальнейшие шаги

• Ознакомьтесь с нашим руководством по реализации CI/CD с помощью GitOps.
• Узнайте о создании подключений между кластером и репозиторием Git с помощью конфигураций Flux.