Поделиться через


Рабочий процесс CI/CD с помощью GitOps (Flux версии 2)

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

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

Архитектура

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

Схема, на которой показана архитектура CI/CD GitOps.

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

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

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

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

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

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

Конвейер PR

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

Конвейер CI

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

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

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

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

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

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

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

Конвейер CD

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

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

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

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

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

Кластеры Kubernetes

По крайней мере один кластер Kubernetes с поддержкой Azure Arc или Служба Azure Kubernetes (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. Когда все среды получили успешные развертывания, конвейер завершается.

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