Учебник. Реализация CI/CD с помощью GitOps (Flux версии 2)

Статья
11/05/2024

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

Создайте кластер Kubernetes с поддержкой Azure Arc или AKS.
Подключите репозитории приложения и GitOps к Azure Repos или GitHub.
Реализуйте поток CI/CD с помощью Azure Pipelines или GitHub.
Подключите Реестр контейнеров Azure к 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.
Нажмите клавишу ВВОД, чтобы запустить код или команду.

Необходимые компоненты

Выполните инструкции из предыдущего учебника, чтобы узнать, как развернуть GitOps для среды CI/CD.
Проанализируйте преимущества и архитектуру этого компонента.
Убедитесь, что у вас есть следующее:
- Подключенный кластер Kubernetes с поддержкой Azure Arc с именем arc-cicd-cluster.
- Подключенная Реестр контейнеров Azure с интеграцией AKS или проверкой подлинности кластера, отличной от AKS.
Установите последние версии этих расширений Kubernetes с поддержкой Azure Arc и Kubernetes Configuration CLI:
```
az extension add --name connectedk8s
az extension add --name k8s-configuration
```
- Чтобы обновить эти расширения до последних версий, выполните следующие команды:
```
az extension update --name connectedk8s
az extension update --name k8s-configuration
```

Подключение Реестр контейнеров Azure к Kubernetes

Включите кластер Kubernetes для извлечения изображений из Реестр контейнеров Azure. Если это закрыто, требуется проверка подлинности.

Подключение Реестр контейнеров Azure к существующим кластерам AKS

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

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

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

Чтобы подключить не AKS и локальные кластеры к Реестр контейнеров Azure, создайте секрет извлечения образа. 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.

В зависимости от предпочитаемого оркестратора CI/CD можно выполнить инструкции по Azure DevOps или GitHub.

Реализация CI/CD с помощью Azure DevOps

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

Сначала выполните следующие действия:

Войдите в Azure DevOps Services.
Убедитесь, что у вас есть разрешения "Администратор сборки" и "Администратор проекта" для Azure Repos и Azure Pipelines.

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

Импортируйте репозиторий приложений и репозиторий GitOps в Azure Repos. В этом руководстве используйте следующие репозитории:

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

Дополнительные сведения об импорте репозиториев 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 flux create \
   --name cluster-config \
   --cluster-name arc-cicd-cluster \
   --namespace flux-system \
   --resource-group myResourceGroup \
   -u 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 \
   --branch master \
   --kustomization name=cluster-config prune=true path=arc-cicd-cluster/manifests

Совет

Для кластера AKS (а не кластера с поддержкой Arc), используйте -cluster-type managedClusters.

Проверить состояние развертывания можно на портале Azure.
- В случае успеха в кластере будут созданы пространства имен dev и stage.
- Вы также можете подтвердить, что на странице портал Azure кластера на вкладке fGitOps создается конфигурацияcluster-config.

Импорт конвейеров 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

Подключение Реестр контейнеров Azure к Azure DevOps

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

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

Настройка подключения службы PR

Конвейер CD управляет PR в репозитории GitOps. Для этого требуется подключение к службе. Чтобы настроить это подключение, выполните указанные ниже действия.

В Azure DevOps перейдите на страницу настроек проекта и откройте страницу Подключения службы. На TFS откройте страницу Службы, воспользовавшись значком Параметры в верхней строке меню.
Выберите +Создать подключение к службе и выберите Generic тип.
Заполните поля параметров для подключения службы. Для работы с этим руководством:
- URL-адрес сервера https://dev.azure.com/<Your organization>/<Your project>/_apis/git/repositories/arc-cicd-demo-gitops
- Оставьте имя пользователя и пароль пустым.
- Назовите подключение службы azdo-pr-connection.
Выберите Предоставить разрешение на доступ для всех конвейеров.
- Этот параметр позволяет авторизовать файлы конвейера YAML для подключений служб.
Нажмите кнопку ОК, чтобы создать подключение.

Установка соединителя GitOps

Добавьте репозиторий соединителя GitOps в репозитории Helm:
```
   helm repo add gitops-connector https://azure.github.io/gitops-connector/
```

Установите соединитель в кластер:

   helm upgrade -i gitops-connector gitops-connector/gitops-connector \
      --namespace flux-system \
      --set gitRepositoryType=AZDO \
      --set ciCdOrchestratorType=AZDO \
      --set gitOpsOperatorType=FLUX \
      --set azdoGitOpsRepoName=arc-cicd-demo-gitops \
      --set azdoOrgUrl=https://dev.azure.com/<Your organization>/<Your project> \
      --set gitOpsAppURL=https://dev.azure.com/<Your organization>/<Your project>/_git/arc-cicd-demo-gitops \
      --set orchestratorPAT=<Azure Repos PAT token>

Примечание.

Azure Repos PAT token должны иметь Build: Read & execute и Code: Full разрешения.

Настройте Flux для отправки уведомлений в соединитель GitOps:

cat <<EOF | kubectl apply -f -
apiVersion: notification.toolkit.fluxcd.io/v1beta1
kind: Alert
metadata:
  name: gitops-connector
  namespace: flux-system
spec:
  eventSeverity: info
  eventSources:
  - kind: GitRepository
    name: cluster-config
  - kind: Kustomization
    name: cluster-config-cluster-config 
  providerRef:
    name: gitops-connector
---
apiVersion: notification.toolkit.fluxcd.io/v1beta1
kind: Provider
metadata:
  name: gitops-connector
  namespace: flux-system
spec:
  type: generic
  address: http://gitops-connector:8080/gitopsphase
EOF

Дополнительные сведения об установке см. в репозитории соединителя GitOps.

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

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

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

Переменная	Значение
AZURE_SUBSCRIPTION	(ваше подключение к службе Azure, у которого, согласно предыдущим инструкциям в учебнике, должно быть имя arc-demo-acr)
AZ_ACR_NAME	Имя Azure ACR, например arc-demo-acr
ENVIRONMENT_NAME	Разработка
MANIFESTS_BRANCH	`master`
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`
VOTE_APP_TITLE	Приложение для голосования
AKS_RESOURCE_GROUP	Группа ресурсов AKS. Требуется для автоматического тестирования.
AKS_NAME	Имя AKS. Требуется для автоматического тестирования.

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

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

Переменная	Значение
ENVIRONMENT_NAME	Этап
TARGET_NAMESPACE	`stage`

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

Создание сред

В проекте Azure DevOps создайте Dev и Stage среды. Дополнительные сведения см. в разделе "Создание и назначение среды".

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

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

На главной странице проекта в Azure DevOps перейдите в раздел Project settings.
Выберите Repos/Repositories.
Выберите Security.
<Project Name> Build Service (<Organization Name>) Для и для Project Collection Build Service (<Organization Name>) поля поиска (введите в поле поиска, если оно не отображается), разрешите Contribute, Contribute to pull requestsи Create branch.
Перейдите к Pipelines/Settings
Параметр выключения Protect access to repositories in YAML pipelines

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

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

После создания конвейеров 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, созданный конвейером в репозиторий GitOps.
Проверьте изменения в репозитории GitOps. Должно отображаться следующее:
- Изменение шаблона Helm верхнего уровня.
- Низкоуровневые манифесты Kubernetes, отражающие базовые изменения в требуемом состоянии. Эти манифесты развертывает Flux.
Если все верно, утвердите и завершите PR.
Через несколько минут Flux подхватит изменения и начнет развертывание.
Отслеживайте состояние фиксации Git на вкладке "Журнал фиксации". После этого succeededконвейер CD запускает автоматическое тестирование.
Перенаправьте порт локально с помощью 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 для завершения процесса развертывания. В этот раз вам потребуется утвердить конвейер в каждой среде развертывания.

Утвердите развертывание в среде dev.
После создания шаблона и манифеста репозитория GitOps конвейер CD создает фиксацию, отправляет его и создает 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, используемых в этом руководстве, см . на схеме потоков Azure DevOps GitOps.

Реализация CI/CD с помощью GitHub

В этом руководстве предполагается знакомство с GitHub, GitHub Actions.

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

Вилку репозитория приложений и репозиторий GitOps. В этом руководстве используйте следующие репозитории:

репозиторий приложений 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 для голосования.

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

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

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

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

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

az k8s-configuration flux create \
   --name cluster-config \
   --cluster-name arc-cicd-cluster \
   --namespace cluster-config \
   --resource-group myResourceGroup \
   -u  https://github.com/<Your organization>/arc-cicd-demo-gitops.git \
   --https-user <Azure Repos username> \
   --https-key <Azure Repos PAT token> \
   --scope cluster \
   --cluster-type connectedClusters \
   --branch master \
   --kustomization name=cluster-config prune=true path=arc-cicd-cluster/manifests

Проверить состояние развертывания можно на портале Azure.
- В случае успеха в кластере будут созданы пространства имен dev и stage.

Установка соединителя GitOps

Добавьте репозиторий соединителя GitOps в репозитории Helm:
```
   helm repo add gitops-connector https://azure.github.io/gitops-connector/
```

Установите соединитель в кластер:

   helm upgrade -i gitops-connector gitops-connector/gitops-connector \
      --namespace flux-system \
      --set gitRepositoryType=GITHUB \
      --set ciCdOrchestratorType=GITHUB \
      --set gitOpsOperatorType=FLUX \
      --set gitHubGitOpsRepoName=arc-cicd-demo-src \
      --set gitHubGitOpsManifestsRepoName=arc-cicd-demo-gitops \
      --set gitHubOrgUrl=https://api.github.com/repos/<Your organization> \
      --set gitOpsAppURL=https://github.com/<Your organization>/arc-cicd-demo-gitops/commit \
      --set orchestratorPAT=<GitHub PAT token>

Настройте Flux для отправки уведомлений в соединитель GitOps:

cat <<EOF | kubectl apply -f -
apiVersion: notification.toolkit.fluxcd.io/v1beta1
kind: Alert
metadata:
  name: gitops-connector
  namespace: flux-system
spec:
  eventSeverity: info
  eventSources:
  - kind: GitRepository
    name: cluster-config
  - kind: Kustomization
    name: cluster-config-cluster-config
  providerRef:
    name: gitops-connector
---
apiVersion: notification.toolkit.fluxcd.io/v1beta1
kind: Provider
metadata:
  name: gitops-connector
  namespace: flux-system
spec:
  type: generic
  address: http://gitops-connector:8080/gitopsphase
EOF

Дополнительные сведения об установке см. в репозитории соединителя GitOps.

Создавайте секреты GitHub

Создание секретов репозитория GitHub

Секретный	Значение
AZURE_CREDENTIALS	Учетные данные для Azure в следующем формате {"clientId":"GUID","clientSecret":"GUID","subscriptionId":"GUID","GUID","tenantId":"GUID"}
AZ_ACR_NAME	Имя Azure ACR, например arc-demo-acr
MANIFESTS_BRANCH	`master`
MANIFESTS_FOLDER	`arc-cicd-cluster`
MANIFESTS_REPO	`https://github.com/your-organization/arc-cicd-demo-gitops`
VOTE_APP_TITLE	Приложение для голосования
AKS_RESOURCE_GROUP	Группа ресурсов AKS. Требуется для автоматического тестирования.
AKS_NAME	Имя AKS. Требуется для автоматического тестирования.
PAT	Токен GitHub PAT с разрешением на pr в репозиторий GitOps

Создание секретов среды GitHub

Создайте az-vote-app-dev среду со следующими секретами:

Секретный	Значение
ENVIRONMENT_NAME	Разработка
TARGET_NAMESPACE	`dev`

Создайте az-vote-app-stage среду со следующими секретами:

Секретный	Значение
ENVIRONMENT_NAME	Этап
TARGET_NAMESPACE	`stage`

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

Рабочий процесс разработки CI/CD

Чтобы запустить рабочий процесс разработки CI/CD, измените исходный код. В репозитории приложений обновите значения в .azure-vote/src/azure-vote-front/config_file.cfg файле и отправьте изменения в репозиторий.

Рабочий процесс разработки CI/CD:

Убеждается, что изменение в приложении проходит все автоматические проверки качества для развертывания.
Выполняет все дополнительные проверки, которые невозможно выполнить в конвейере PR.
Убеждается, что образ Docker изменен и отправлен новый образ.
Публикует артефакты (теги изображений Docker, шаблоны манифестов, Utils), которые будут использоваться на следующих этапах CD.
Развертывает приложение в среде разработки.
- Создает манифесты в репозитории GitOps.
- Создает pr в репозиторий GitOps для утверждения.

Найдите pr, созданный конвейером в репозиторий GitOps.
Проверьте изменения в репозитории GitOps. Должно отображаться следующее:
- Изменение шаблона Helm верхнего уровня.
- Низкоуровневые манифесты Kubernetes, отражающие базовые изменения в требуемом состоянии. Эти манифесты развертывает Flux.
Если все верно, утвердите и завершите PR.
Через несколько минут Flux подхватит изменения и начнет развертывание.
Отслеживайте состояние фиксации Git на вкладке "Журнал фиксации". После этого succeededрабочий CD Stage процесс начнется.
Перенаправьте порт локально с помощью kubectl и убедитесь, что приложение работает правильно, с помощью этой команды:
```
kubectl port-forward -n dev svc/azure-vote-front 8080:80
```
Просмотрите приложение Azure для голосования в браузере по адресу http://localhost:8080/.
Проголосуйте за избранные варианты и приготовьтесь к внесению ряда изменений в приложение.

Рабочий процесс этапа CD

Рабочий процесс этапа CD запускается автоматически после успешного развертывания приложения в среде разработки и уведомляет действия GitHub через соединитель GitOps.

Рабочий процесс этапа CD:

Запуск тестов дыма приложений в среде разработки
Развертывает приложение в среде Stage.
- Создает манифесты в репозитории GitOps
- Создает pr в репозиторий GitOps для утверждения

После объединения манифестов в среду Stage и Flux успешно применяет все изменения, состояние фиксации Git обновляется в репозитории GitOps. Развертывание завершено.

Подробный обзор всех шагов и методов, реализованных в рабочих процессах CI/CD, используемых в этом руководстве, см. на схеме потока GitHub GitOps.

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

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

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

az k8s-configuration flux delete \
      --name cluster-config \
      --cluster-name arc-cicd-cluster \
      --resource-group myResourceGroup \
      -t connectedClusters --yes

Удаление соединителя GitOps:

helm uninstall gitops-connector -n flux-system
kubectl delete alerts.notification.toolkit.fluxcd.io gitops-connector -n flux-system
kubectl delete providers.notification.toolkit.fluxcd.io  gitops-connector -n flux-system

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

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

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

Концепция: процесс CD с примером реализации GitOps : изучение потока CI/CD с помощью GitOps

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

Учебник. Реализация CI/CD с помощью GitOps (Flux версии 2)

Azure Cloud Shell

Необходимые компоненты

Подключение Реестр контейнеров Azure к Kubernetes

Подключение Реестр контейнеров Azure к существующим кластерам AKS

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

Реализация CI/CD с помощью Azure DevOps

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

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

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

Подключение Реестр контейнеров Azure к Azure DevOps

Настройка подключения службы PR

Установка соединителя GitOps

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

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

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

Создание сред

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

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

Конвейер CI

Конвейер CD

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

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

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

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

Реализация CI/CD с помощью GitHub

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

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

Установка соединителя GitOps

Создавайте секреты GitHub

Создание секретов репозитория GitHub

Создание секретов среды GitHub

Рабочий процесс разработки CI/CD

Рабочий процесс этапа CD

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

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

Обратная связь

Дополнительные ресурсы