Рабочий процесс CI/CD при использовании GitOps с Kubernetes с поддержкой Azure Arc

Важно!

Рабочий процесс, описанный в этом документе, использует GitOps с Flux версии 1. GitOps с Flux версии 2 теперь доступен для кластеров Kubernetes с поддержкой Azure Arc и Служба Azure Kubernetes (AKS); узнайте о рабочем процессе CI/CD с помощью GitOps с Flux версии 2. Мы рекомендуем перейти на Flux версии 2 как можно скорее.

Поддержка ресурсов конфигурации кластера flux версии 1, созданных до 1 января 2024 г., завершится 24 мая 2025 г. Начиная с 1 января 2024 г. вы не сможете создавать новые ресурсы конфигурации кластера Flux версии 1.

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

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

Архитектура

Рассмотрите приложение, развернутое в одной или нескольких средах Kubernetes.

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

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

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

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

Конвейер PR

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

Конвейер CI

Конвейер CI приложения выполняет все этапы конвейера PR, а также развертывает тестирование и проверки развертывания. Конвейер можно запускать для каждой фиксации или с постоянной ритмичностью с помощью группы фиксаций. На этом этапе выполняется тестирование приложения, которое является слишком продолжительным для конвейера PR. Отправьте созданные образы Docker в Реестр контейнеров Azure в процессе подготовки к развертыванию. Замененный шаблон можно проверить с помощью набора тестовых значений. На этом этапе образы, используемые во время выполнения службы, необходимо проверить, создать и протестировать. В частности, в сборке CI артефакты публикуются на этапе CD для использования их в процессе подготовки к развертыванию.

Flux

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

Конвейер CD

Конвейер CD автоматически запускается успешно выполняемыми сборками CI. Он использует опубликованные ранее шаблоны, заменяет значения среды и открывает запрос на вытягивание в репозитории GitOps, чтобы отправить запрос на изменение требуемого состояния одного или нескольких кластеров Kubernetes. Администраторы кластера проверяют изменение состояния и утверждают слияние в репозитории GitOps. Затем конвейер ожидает завершение запроса на вытягивание, что позволяет Flux выбрать изменение состояния.

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

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

Кластеры Kubernetes

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

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

Действия, которые выполняет разработчик приложения Алиса:

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

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

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

1. Алиса изменяет шаблон развертывания, отправляет его в удаленную ветвь в репозитории приложения и открывает запрос на вытягивание для проверки.
2. Алиса запрашивает у своей команды проверку этого изменения.
   • Конвейер PR выполняет проверку.
   • После успешного запуска конвейера команда отключается, и изменение объединяется.
3. Конвейер CI проверяет изменение Алисы и успешно его выполняет.
   • Это изменение надежно развертывается в кластере, при этом артефакты сохраняются в конвейере CI.
4. Алиса объединяет изменение и запускает конвейер CD.
   • Конвейер CD выбирает артефакты, сохраненные в конвейере CI, который запущен Алисой.
   • Конвейер CD подставляет шаблоны со значениями, зависящими от среды, и изменяет состояние существующего кластера в репозитории GitOps.
   • Конвейер CD создает в репозитории GitOps запрос на вытягивание с помощью требуемых изменений состояния кластера.
5. Команда Алисы проверяет и утверждает запрос.
   • Изменение объединяется в целевую ветвь, соответствующую среде.
6. В течение нескольких минут Flux обнаруживает изменение в репозитории GitOps и извлекает изменение Алисы.
   • Из-за изменения образа Docker под приложения необходимо обновить.
   • Flux применяет изменение к кластеру.
7. Алиса проверяет конечную точку приложения, чтобы убедиться в успешном выполнении развертывания.

   Примечание.

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

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

Следующие шаги

Дополнительные сведения о создании подключений между кластером и репозиторием Git в качестве ресурса конфигурации с помощью Kubernetes с поддержкой Azure Arc