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

Статья
01/15/2025

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

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

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

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

Выполните инструкции из предыдущего учебника, чтобы узнать, как развернуть 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 кластера на вкладке GitOps создается конфигурация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. Для создания новой ветви, отправки изменений и создания PR необходимы дополнительные разрешения для конвейера. Чтобы включить эти разрешения, сделайте следующее.

В Azure DevOps откройте Параметры проекта.
В разделе Репозитории выберите Repos.
Выберите Безопасность.
Найдите <Project Name> Build Service (<Organization Name>) и (используйте поиск, если они не отображаются), а также разрешить участие, внести вклад в запросы на вытягивание и создать ветвьProject Collection Build Service (<Organization Name>).
В разделе "Конвейеры" выберите "Параметры".
Отключите защищенный доступ к репозиториям в конвейерах YAML.

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

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

После создания конвейеров 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 commit "Журнал фиксации ". После этого 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 в реальном приложении, замените значения, которые достаточно похожи на значения, которые будут использоваться в реальной среде.

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

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

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

Совет

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

Создание секретов репозитория 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 commit "Журнал фиксации". После этого 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 к 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

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

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

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

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