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

В этом руководстве описано, как настроить решение 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

• репозиторий GitOps arc-cicd-demo-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 заполняет каталог манифеста дополнительными манифестами для развертывания приложения.

1. Создайте новое подключение 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.

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

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

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

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

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

Имя файла конвейера	Описание
.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:

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

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

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

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

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

1. Добавьте репозиторий GitOps Connector в репозитории Helm:

      helm repo add gitops-connector https://azure.github.io/gitops-connector/
   

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

      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.

3. Настройте 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. Требуется для автоматического тестирования.

Этап группы переменных среды

1. Клонируйте группу переменных az-vote-app-dev.

2. Измените имя на az-vote-app-stage.

3. Убедитесь, что для соответствующих переменных имеются следующие значения:

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

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

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

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

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

Конвейер CD использует токен безопасности текущей сборки для аутентификации в репозитории GitOps. Для создания новой ветви, отправки изменений и создания PR необходимы дополнительные разрешения для конвейера. Чтобы включить эти разрешения, сделайте следующее.

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

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

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

После создания конвейеров 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, созданный конвейером в репозиторий GitOps.

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

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

3. Если все выглядит хорошо, утвердите и завершите PR.

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

5. Отслеживайте git commit состояние на вкладке "Журнал фиксации". Как только оно становится succeeded, поток CD запускает автоматическое тестирование.

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

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

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

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

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

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

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

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. Зафиксируйте изменения в новой ветви, отправьте её и создайте pull request. Эта последовательность шагов — это типичный поток разработчика, который запускает жизненный цикл CI/CD.

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

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

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

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

Примечание.

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

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

• Отслеживание полезной статистики по типам ошибок.
• Найдите первый коммит, в котором они были обнаружены.
• Ссылки в стиле трассировки стека ведут к разделам кода, которые вызвали ошибку.

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

Совет

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

Одобрения процессов CD

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

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

• GitOps репозиторий arc-cicd-demo-gitops

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

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

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

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

Подключение GitOps, создаваемое автоматически:

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

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

1. Создайте новое подключение 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
   

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

   • При успешном выполнении вы увидите пространства имен dev и stage, созданные в вашем кластере.

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

1. Добавьте репозиторий коннектора GitOps в репозитории Helm:

      helm repo add gitops-connector https://azure.github.io/gitops-connector/
   

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

      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>
   

3. Настройте 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 Connector.

Создавайте секреты 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

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

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

1. Создайте 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, шаблоны манифестов, утилиты), используемые на следующих стадиях CD.
• Развертывает приложение в среде разработки.
  • Создает манифесты в репозитории GitOps.
  • Создает PR в репозиторий GitOps для утверждения.

После завершения этих шагов:

1. Найдите PR, созданный потоком в репозиторий GitOps.

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

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

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

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

5. Отслеживайте git commit состояние на вкладке "Журнал фиксации". Как только оно succeeded, запускается CD Stage рабочий процесс.

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

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

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

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

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

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

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

• Выполнение тестов на дым для приложения в среде Dev.
• Развертывает приложение в среде Stage.
  • Создает манифесты в репозитории GitOps
  • Создает запрос на добавление в репозиторий GitOps для утверждения

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

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

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

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

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

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

2. Удалите соединитель 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