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

  • Статья

Внимание

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

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

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

  • Создание кластера Kubernetes с поддержкой Azure Arc.
  • Подключение репозиториев приложений и GitOps к Azure Repos.
  • Импорт конвейеров CI/CD.
  • Подключение Реестра контейнеров Azure (ACR) к Azure DevOps и Kubernetes.
  • Создание группы переменных среды.
  • Развертывание сред dev и stage.
  • Тестирование сред приложений.

Если у вас нет подписки Azure, создайте бесплатную учетную запись, прежде чем приступить к работе.

Azure Cloud Shell

В Azure есть Azure Cloud Shell, интерактивная оболочка среды, с которой можно работать в браузере. Для работы со службами Azure можно использовать Bash или PowerShell с Cloud Shell. Для запуска кода из этой статьи можно использовать предварительно установленные команды Cloud Shell. Ничего дополнительного в локальной среде устанавливать не нужно.

Начало работы с Azure Cloud Shell

Вариант Пример и ссылка
Нажмите кнопку Попробовать в правом верхнем углу блока кода или команд. При нажатии кнопки Попробовать код или команда не копируется в Cloud Shell автоматически. Screenshot that shows an example of Try It for Azure Cloud Shell.
Чтобы открыть Cloud Shell в браузере, перейдите по адресу https://shell.azure.com или нажмите кнопку Запуск Cloud Shell. Button to launch Azure Cloud Shell.
Нажмите кнопку Cloud Shell в строке меню в правом верхнем углу окна портала Azure. Screenshot that shows the Cloud Shell button in the Azure portal

Чтобы использовать Azure Cloud Shell, выполните следующие действия:

  1. Запустите Cloud Shell.

  2. Нажмите кнопку Копировать в блоке кода (или блоке команд), чтобы скопировать код или команду.

  3. Вставьте код или команду в окно сеанса Cloud Shell, нажав клавиши CTRL+SHIFT+V в Windows и Linux или CMD+SHIFT+V в macOS.

  4. Нажмите клавишу ВВОД, чтобы запустить код или команду.

Подготовка к работе

В этом учебнике предполагается, что вы знакомы с Azure DevOps, Azure Repos, Azure Pipelines и Azure CLI.

Импорт репозиториев приложений и GitOps в Azure Repos

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

  • репозиторий приложения arc-cicd-demo-src
    • URL-адрес: https://github.com/Azure/arc-cicd-demo-src
    • Содержит пример приложения Azure для голосования, которое будет развернуто с помощью GitOps.
  • репозиторий arc-cicd-demo-gitops GitOps
    • URL-адрес: https://github.com/Azure/arc-cicd-demo-gitops
    • Используется в качестве основы для ресурсов кластера, в которых размещено приложение Azure для голосования.

См. дополнительные сведения об импорте репозиториев Git.

Примечание.

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

Подключение репозитория GitOps

Для непрерывного развертывания приложения подключите репозиторий приложений к кластеру, в котором используется GitOps. Репозиторий GitOps под названием arc-cicd-demo-gitops содержит основные ресурсы, позволяющие запустить приложение в кластере arc-cicd-cluster.

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

Созданное подключение GitOps будет автоматически выполнять следующие действия:

  • синхронизация манифестов в каталоге манифестов;
  • обновление состояния кластера.

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

  1. Создайте новое подключение GitOps к только что импортированному репозиторию arc-cicd-demo-gitops в Azure Repos.

    az k8s-configuration create \
   --name cluster-config \
   --cluster-name arc-cicd-cluster \
   --resource-group myResourceGroup \
   --operator-instance-name cluster-config \
   --operator-namespace cluster-config \
   --repository-url https://dev.azure.com/<Your organization>/<Your project>/_git/arc-cicd-demo-gitops \
   --https-user <Azure Repos username> \
   --https-key <Azure Repos PAT token> \
   --scope cluster \
   --cluster-type connectedClusters \
   --operator-params='--git-readonly --git-path=arc-cicd-cluster/manifests'

  2. Убедитесь, что Flux использует в качестве базового пути только каталог arc-cicd-cluster/manifests. Определите путь с помощью следующего параметра оператора:

    --git-path=arc-cicd-cluster/manifests

    Примечание.

    Если используется строка подключения HTTPS и возникают проблемы с подключением, убедитесь, что в URL-адресе не указан префикс имени пользователя. Например, из https://alice@dev.azure.com/contoso/project/_git/arc-cicd-demo-gitops необходимо удалить alice@. Вместо этого укажите пользователя с помощью --https-user, например --https-user alice.

  3. Проверить состояние развертывания можно на портале Azure.

    • В случае успеха в кластере будут созданы пространства имен dev и stage.

Импорт конвейеров CI/CD

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

Репозиторий приложений содержит папку .pipeline с конвейерами, которые будут использоваться для запросов PR, CI и CD. Импортируйте и переименуйте три конвейера, предоставленные в примере репозитория.

Имя файла конвейера Description
.pipelines/az-vote-pr-pipeline.yaml Конвейер PR для приложения с именем arc-cicd-demo-src PR
.pipelines/az-vote-ci-pipeline.yaml Конвейер CI для приложения с именем arc-cicd-demo-src CI
.pipelines/az-vote-cd-pipeline.yaml Конвейер CD для приложения с именем arc-cicd-demo-src CD

Подключение к ACR

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

Подключение ACR к Azure DevOps

В процессе непрерывной интеграции вы развернете контейнеры приложений в реестре. Для начала создайте подключение к службе Azure.

  1. В Azure DevOps перейдите на страницу настроек проекта и откройте страницу Подключения службы. На TFS откройте страницу Службы, воспользовавшись значком Параметры в верхней строке меню.
  2. Выберите + Новое подключение службы и выберите необходимый тип подключения службы.
  3. Заполните поля параметров для подключения службы. Для работы с этим руководством:
    • Присвойте подключению службы имя arc-demo-acr.
    • Выберите myResourceGroup в качестве группы ресурсов.
  4. Выберите Предоставить разрешение на доступ для всех конвейеров.
    • Этот параметр позволяет авторизовать файлы конвейера YAML для подключений служб.
  5. Нажмите кнопку ОК, чтобы создать подключение.

Подключение ACR к Kubernetes

Разрешите на кластере Kubernetes извлечение образов из ACR. Если он частный, потребуется проверка подлинности.

Подключение ACR к имеющимся кластерам AKS

Интегрируйте имеющуюся службу ACR с существующими кластерами AKS с помощью следующей команды:

az aks update -n arc-cicd-cluster -g myResourceGroup --attach-acr arc-demo-acr

Создание секрета для извлечения образа

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

Создайте секрет извлечения образа с помощью следующей команды kubectl. Повторите эти действия для пространств имен dev и stage.

kubectl create secret docker-registry <secret-name> \
    --namespace <namespace> \
    --docker-server=<container-registry-name>.azurecr.io \
    --docker-username=<service-principal-ID> \
    --docker-password=<service-principal-password>

Чтобы не задавать imagePullSecret для каждого объекта Pod, рекомендуется добавить imagePullSecret в учетную запись службы в пространствах имен dev и stage. Дополнительные сведения см. в учебнике по Kubernetes.

Создание групп переменных среды

Группа переменных репозитория приложений

Создайте группу переменных с именем az-vote-app-dev. Задайте следующие значения:

Переменная Значение
AZ_ACR_NAME (например, экземпляр ACR. azurearctest.azurecr.io)
AZURE_SUBSCRIPTION (ваше подключение к службе Azure, у которого, согласно предыдущим инструкциям в учебнике, должно быть имя arc-demo-acr)
AZURE_VOTE_IMAGE_REPO Полный путь к репозиторию приложения Azure для голосования, например azurearctest.azurecr.io/azvote
ENVIRONMENT_NAME Разработка
MANIFESTS_BRANCH master
MANIFESTS_FOLDER azure-vote-manifests
MANIFESTS_REPO arc-cicd-demo-gitops
ORGANIZATION_NAME Имя организации Azure DevOps
PROJECT_NAME Имя проекта GitOps в Azure DevOps
REPO_URL Полный URL-адрес репозитория GitOps
SRC_FOLDER azure-vote
TARGET_CLUSTER arc-cicd-cluster
TARGET_NAMESPACE dev

Подготовка группы переменных среды

  1. Клонируйте группу переменных az-vote-app-dev.
  2. Измените имя на az-vote-app-stage.
  3. Убедитесь, что для соответствующих переменных имеются следующие значения:
Переменная Значение
ENVIRONMENT_NAME Этап
TARGET_NAMESPACE stage

Теперь все готово для развертывания в средах dev и stage.

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

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

  1. На главной странице проекта в Azure DevOps перейдите в раздел Project settings.
  2. Выберите Repositories.
  3. Выберите <GitOps Repo Name>.
  4. Выберите Security.
  5. Для <Project Name> Build Service (<Organization Name>) добавьте разрешения Contribute, Contribute to pull requests и Create branch.

Дополнительные сведения см. в разделе:

Первое развертывание среды разработки

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

Конвейер CI

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

  1. Убедитесь, что доступ осуществляется именно к переменной AZURE_SUBSCRIPTION.
  2. Авторизуйте использование.
  3. Перезапустите конвейер.

Конвейер CI выполняет следующие действия:

  • Убеждается, что изменение в приложении проходит все автоматические проверки качества для развертывания.
  • Выполняет все дополнительные проверки, которые невозможно выполнить в конвейере PR.
    • В GitOps конвейер публикует также артефакты для фиксации, которая будет развернута конвейером CD.
  • Убеждается, что образ Docker изменен и отправлен новый образ.

Конвейер CD

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

При успешном запуске конвейера CI активирует конвейер CD для завершения процесса развертывания. Развертывание в каждой среде выполняется с приращением.

Совет

Если конвейер CD не активируется автоматически, выполните следующие действия.

  1. Убедитесь, что имя соответствует триггеру ветви в .pipelines/az-vote-cd-pipeline.yaml.
    • Оно должно иметь значение arc-cicd-demo-src CI.
  2. Перезапустите конвейер CI.

После создания изменений шаблона и манифеста в репозитории GitOps конвейер CD создаст фиксацию, отправит ее и создаст PR для утверждения.

  1. Откройте ссылку на PR, указанную в выходных данных задачи Create PR.

  2. Проверьте изменения в репозитории GitOps. Должно отображаться следующее:

    • Изменение шаблона Helm верхнего уровня.
    • Низкоуровневые манифесты Kubernetes, отражающие базовые изменения в требуемом состоянии. Эти манифесты развертывает Flux.

  3. Если все верно, утвердите и завершите PR.

  4. Через несколько минут Flux подхватит изменения и начнет развертывание.

  5. Перенаправьте порт локально с помощью kubectl и убедитесь, что приложение работает правильно, с помощью этой команды:

    kubectl port-forward -n dev svc/azure-vote-front 8080:80

  6. Просмотрите приложение Azure для голосования в браузере по адресу http://localhost:8080/.

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

Настройка утверждений среды

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

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

  1. В проекте Azure DevOps перейдите в среду, которую необходимо защитить.
  2. Перейдите в раздел утверждения и проверки для ресурса.
  3. Нажмите кнопку создания.
  4. Укажите утверждающих и необязательное сообщение.
  5. Щелкните Создать еще раз, чтобы завершить добавление проверки утверждения вручную.

Дополнительные сведения см. в учебнике по определению утверждений и проверок.

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

Внесение изменений в приложение

С помощью этого базового набора шаблонов и манифестов, представляющих состояние в кластере, вы внесете небольшое изменение в приложение.

  1. В репозитории arc-cicd-demo-src измените файл azure-vote/src/azure-vote-front/config_file.cfg.

  2. Так как вопрос "Кто вам больше нравится: кошки или собаки?" не получил достаточно голосов, чтобы увеличить их число, измените его на вопрос "Что лучше: вкладки или пространства".

  3. Зафиксируйте изменения в новой ветви, отправьте ее и создайте запрос на вытягивание.

    • Это типичный процесс разработки, который запустит жизненный цикл CI/CD.

Конвейер проверки PR

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

Файлы Dockerfile и Helm диаграммы Helm приложения могут использовать анализ кода так же, как и приложение.

Ошибки, обнаруженные при анализе кода, могут варьироваться:

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

Примечание.

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

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

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

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

Совет

В реальной среде не забудьте установить политики ветви, которые позволят убедиться, что в PR передаются проверки качества. Дополнительные сведения см. в статье Установка политик ветви.

Утверждения процессов CD

При успешной активации выполнения конвейера CI запускается конвейер CD для завершения процесса развертывания. Так же как и при первом выполнении конвейера CD, развертывание в каждой среде выполняется с приращением. В этот раз вам потребуется утвердить конвейер в каждой среде развертывания.

  1. Утвердите развертывание в среде dev.
  2. После создания изменений шаблона и манифеста в репозитории GitOps конвейер CD создаст фиксацию, отправит ее и создаст PR для утверждения.
  3. Откройте ссылку на PR, указанную в задаче.
  4. Проверьте изменения в репозитории GitOps. Должно появиться следующее:
    • Изменение шаблона Helm верхнего уровня.
    • Низкоуровневые манифесты Kubernetes, отражающие базовые изменения в требуемом состоянии.
  5. Если все верно, утвердите и завершите PR.
  6. Дождитесь завершения развертывания.
  7. В рамках базового теста проверки сборки перейдите на страницу приложения и убедитесь, что в приложении для голосования теперь отображается вопрос о том, что лучше: вкладки или пространства.
    • Перенаправьте порт локально с помощью kubectl и убедитесь, что приложение работает правильно, с помощью этой команды: kubectl port-forward -n dev svc/azure-vote-front 8080:80.
    • Просмотрите приложение Azure для голосования в браузере по адресу http://localhost:8080/ и убедитесь, что варианты голосования изменились на вкладки и пространства.
  8. Повторите шаги 1–7 для среды stage.

Развертывание завершено. На этом рабочий процесс CI/CD заканчивается.

Очистка ресурсов

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

  1. Удалите подключение в конфигурации GitOps для Azure Arc.

    az k8s-configuration delete \
--name cluster-config \
--cluster-name arc-cicd-cluster \
--resource-group myResourceGroup \
--cluster-type connectedClusters

  2. Удалите пространство имен dev.

    • kubectl delete namespace dev

  3. Удалите пространство имен stage.

    • kubectl delete namespace stage

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

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

Перейдите к нашей концептуальной статье, чтобы узнать больше о GitOps и конфигурациях в Kubernetes с поддержкой Azure Arc.

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