Учебник по реализации 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 автоматически. | |
Чтобы открыть Cloud Shell в браузере, перейдите по адресу https://shell.azure.com или нажмите кнопку Запуск Cloud Shell. | |
Нажмите кнопку Cloud Shell в строке меню в правом верхнем углу окна портала Azure. |
Чтобы использовать Azure Cloud Shell, выполните следующие действия:
Запустите Cloud Shell.
Нажмите кнопку Копировать в блоке кода (или блоке команд), чтобы скопировать код или команду.
Вставьте код или команду в окно сеанса Cloud Shell, нажав клавиши CTRL+SHIFT+V в Windows и Linux или CMD+SHIFT+V в macOS.
Нажмите клавишу ВВОД, чтобы запустить код или команду.
Подготовка к работе
В этом учебнике предполагается, что вы знакомы с Azure DevOps, Azure Repos, Azure Pipelines и Azure CLI.
Войдите в Azure DevOps Services.
Выполните инструкции из предыдущего учебника, чтобы узнать, как развернуть GitOps для среды CI/CD.
Проанализируйте преимущества и архитектуру этого компонента.
Убедитесь, что у вас есть следующее:
- Подключенный кластер Kubernetes с поддержкой Azure Arc с именем arc-cicd-cluster.
- Подключенный Реестр контейнеров Azure (ACR) с интеграцией AKS или проверкой подлинности кластера без использования AKS.
- Разрешения "Администратор сборки" и "Администратор проекта" для Azure Repos и Azure Pipelines.
Установите следующие расширения >Kubernetes Cli с поддержкой Azure Arc = 1.0.0:
az extension add --name connectedk8s az extension add --name k8s-configuration
Чтобы обновить эти расширения до последних версий, выполните следующие команды:
az extension update --name connectedk8s az extension update --name k8s-configuration
Импорт репозиториев приложений и 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 заполнит каталог манифеста дополнительными манифестами для развертывания приложения.
Создайте новое подключение 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'
Убедитесь, что 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
.Проверить состояние развертывания можно на портале 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.
- В Azure DevOps перейдите на страницу настроек проекта и откройте страницу Подключения службы. На TFS откройте страницу Службы, воспользовавшись значком Параметры в верхней строке меню.
- Выберите + Новое подключение службы и выберите необходимый тип подключения службы.
- Заполните поля параметров для подключения службы. Для работы с этим руководством:
- Присвойте подключению службы имя arc-demo-acr.
- Выберите myResourceGroup в качестве группы ресурсов.
- Выберите Предоставить разрешение на доступ для всех конвейеров.
- Этот параметр позволяет авторизовать файлы конвейера YAML для подключений служб.
- Нажмите кнопку ОК, чтобы создать подключение.
Подключение 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 |
Подготовка группы переменных среды
- Клонируйте группу переменных az-vote-app-dev.
- Измените имя на az-vote-app-stage.
- Убедитесь, что для соответствующих переменных имеются следующие значения:
Переменная | Значение |
---|---|
ENVIRONMENT_NAME | Этап |
TARGET_NAMESPACE | stage |
Теперь все готово для развертывания в средах dev
и stage
.
Предоставление дополнительных разрешений для службы сборок
Конвейер CD использует маркер безопасности работающей сборки для проверки подлинности в репозитории GitOps. Для создания новой ветви, отправки изменений и создания запросов на вытягивание требуются дополнительные разрешения для конвейера.
- На главной странице проекта в Azure DevOps перейдите в раздел
Project settings
. - Выберите
Repositories
. - Выберите
<GitOps Repo Name>
. - Выберите
Security
. - Для
<Project Name> Build Service (<Organization Name>)
добавьте разрешенияContribute
,Contribute to pull requests
иCreate branch
.
Дополнительные сведения см. в разделе:
- Предоставление разрешений на управление версиями для службы сборок
- Управление разрешениями учетной записи службы сборок
Первое развертывание среды разработки
После создания конвейеров CI и CD запустите конвейер CI, чтобы развернуть приложение в первый раз.
Конвейер CI
Во время первоначального выполнения конвейера CI может произойти ошибка авторизации ресурсов при чтении имени подключения службы.
- Убедитесь, что доступ осуществляется именно к переменной AZURE_SUBSCRIPTION.
- Авторизуйте использование.
- Перезапустите конвейер.
Конвейер CI выполняет следующие действия:
- Убеждается, что изменение в приложении проходит все автоматические проверки качества для развертывания.
- Выполняет все дополнительные проверки, которые невозможно выполнить в конвейере PR.
- В GitOps конвейер публикует также артефакты для фиксации, которая будет развернута конвейером CD.
- Убеждается, что образ Docker изменен и отправлен новый образ.
Конвейер CD
Во время первоначального выполнения конвейера CD вам будет предложено предоставить ему доступ к репозиторию GitOps. Когда появится этот запрос на предоставление конвейеру разрешения на доступ к ресурсу, выберите "Просмотреть". Затем нажмите "Разрешить", чтобы предоставить разрешение на использование репозитория GitOps для текущего и последующих запусков конвейера.
При успешном запуске конвейера CI активирует конвейер CD для завершения процесса развертывания. Развертывание в каждой среде выполняется с приращением.
Совет
Если конвейер CD не активируется автоматически, выполните следующие действия.
- Убедитесь, что имя соответствует триггеру ветви в
.pipelines/az-vote-cd-pipeline.yaml
.- Оно должно иметь значение
arc-cicd-demo-src CI
.
- Оно должно иметь значение
- Перезапустите конвейер CI.
После создания изменений шаблона и манифеста в репозитории GitOps конвейер CD создаст фиксацию, отправит ее и создаст PR для утверждения.
Откройте ссылку на PR, указанную в выходных данных задачи
Create PR
.Проверьте изменения в репозитории GitOps. Должно отображаться следующее:
- Изменение шаблона Helm верхнего уровня.
- Низкоуровневые манифесты Kubernetes, отражающие базовые изменения в требуемом состоянии. Эти манифесты развертывает Flux.
Если все верно, утвердите и завершите PR.
Через несколько минут Flux подхватит изменения и начнет развертывание.
Перенаправьте порт локально с помощью
kubectl
и убедитесь, что приложение работает правильно, с помощью этой команды:kubectl port-forward -n dev svc/azure-vote-front 8080:80
Просмотрите приложение Azure для голосования в браузере по адресу
http://localhost:8080/
.Проголосуйте за избранные варианты и приготовьтесь к внесению ряда изменений в приложение.
Настройка утверждений среды
При развертывании приложения можно не только внести изменения в код или шаблоны, но и непреднамеренно привести кластер к неисправному состоянию.
Если работа среды разработки прерывается после развертывания, не следует переводить его в последующие среды с помощью утверждений среды.
- В проекте Azure DevOps перейдите в среду, которую необходимо защитить.
- Перейдите в раздел утверждения и проверки для ресурса.
- Нажмите кнопку создания.
- Укажите утверждающих и необязательное сообщение.
- Щелкните Создать еще раз, чтобы завершить добавление проверки утверждения вручную.
Дополнительные сведения см. в учебнике по определению утверждений и проверок.
При следующем выполнении конвейера CD конвейер будет приостановлен после создания запроса на вытягивание GitOps. Убедитесь, что изменение синхронизировано правильно и передает базовые функциональные возможности. Утвердите проверку в конвейере, чтобы разрешить перенос изменений в следующую среду.
Внесение изменений в приложение
С помощью этого базового набора шаблонов и манифестов, представляющих состояние в кластере, вы внесете небольшое изменение в приложение.
В репозитории arc-cicd-demo-src измените файл
azure-vote/src/azure-vote-front/config_file.cfg
.Так как вопрос "Кто вам больше нравится: кошки или собаки?" не получил достаточно голосов, чтобы увеличить их число, измените его на вопрос "Что лучше: вкладки или пространства".
Зафиксируйте изменения в новой ветви, отправьте ее и создайте запрос на вытягивание.
- Это типичный процесс разработки, который запустит жизненный цикл CI/CD.
Конвейер проверки PR
Конвейер PR — это первая линия защиты от неисправности при внесении изменений. Обычно проверки качества кода приложения включают анализ кода и статический анализ. С точки зрения GitOps необходимо также обеспечить такой же уровень качества для развертываемой итоговой инфраструктуры.
Файлы Dockerfile и Helm диаграммы Helm приложения могут использовать анализ кода так же, как и приложение.
Ошибки, обнаруженные при анализе кода, могут варьироваться:
- от неправильно отформатированных файлов YAML
- до несоблюдения рекомендаций, например по настройке ограничений на использование приложением ресурсов ЦП и памяти.
Примечание.
Чтобы извлечь максимальную пользу из анализа кода Helm в реальном приложении, необходимо подставить значения, похожие на те, которые используются в реальной среде.
Ошибки, обнаруженные во время выполнения конвейера, отображаются в разделе результатов теста среды выполнения. Здесь можно выполнять следующие действия:
- Отслеживание полезной статистики по типам ошибок.
- Поиск первой фиксации, для которой они были обнаружены.
- Выполнение трассировки стека для стилевых ссылок на разделы кода, которые вызывают ошибку.
После завершения выполнения конвейера вы будете уверены в качестве кода приложения и шаблона, который будет его развертывать. Теперь можно утвердить и завершить запрос на вытягивание. Перед активацией конвейера CD будет выполнен повторный запуск CI, при котором будут повторно созданы шаблоны и манифесты.
Совет
В реальной среде не забудьте установить политики ветви, которые позволят убедиться, что в PR передаются проверки качества. Дополнительные сведения см. в статье Установка политик ветви.
Утверждения процессов CD
При успешной активации выполнения конвейера CI запускается конвейер CD для завершения процесса развертывания. Так же как и при первом выполнении конвейера CD, развертывание в каждой среде выполняется с приращением. В этот раз вам потребуется утвердить конвейер в каждой среде развертывания.
- Утвердите развертывание в среде
dev
. - После создания изменений шаблона и манифеста в репозитории GitOps конвейер CD создаст фиксацию, отправит ее и создаст PR для утверждения.
- Откройте ссылку на PR, указанную в задаче.
- Проверьте изменения в репозитории GitOps. Должно появиться следующее:
- Изменение шаблона Helm верхнего уровня.
- Низкоуровневые манифесты Kubernetes, отражающие базовые изменения в требуемом состоянии.
- Если все верно, утвердите и завершите PR.
- Дождитесь завершения развертывания.
- В рамках базового теста проверки сборки перейдите на страницу приложения и убедитесь, что в приложении для голосования теперь отображается вопрос о том, что лучше: вкладки или пространства.
- Перенаправьте порт локально с помощью
kubectl
и убедитесь, что приложение работает правильно, с помощью этой команды:kubectl port-forward -n dev svc/azure-vote-front 8080:80
. - Просмотрите приложение Azure для голосования в браузере по адресу http://localhost:8080/ и убедитесь, что варианты голосования изменились на вкладки и пространства.
- Перенаправьте порт локально с помощью
- Повторите шаги 1–7 для среды
stage
.
Развертывание завершено. На этом рабочий процесс CI/CD заканчивается.
Очистка ресурсов
Если вы не собираетесь использовать это приложение в дальнейшем, удалите все его ресурсы, выполнив следующие действия.
Удалите подключение в конфигурации GitOps для Azure Arc.
az k8s-configuration delete \ --name cluster-config \ --cluster-name arc-cicd-cluster \ --resource-group myResourceGroup \ --cluster-type connectedClusters
Удалите пространство имен
dev
.kubectl delete namespace dev
Удалите пространство имен
stage
.kubectl delete namespace stage
Следующие шаги
Из этого учебника вы узнали, как настроить полный рабочий процесс CI/CD, который реализует DevOps от разработки приложений до его развертывания. Изменения в приложении автоматически активируют проверку и развертывание, которые контролируются утверждениями вручную.
Перейдите к нашей концептуальной статье, чтобы узнать больше о GitOps и конфигурациях в Kubernetes с поддержкой Azure Arc.