Tutorial: Implementar a CI/CD com o GitOps (Flux v2)

Neste tutorial, você configurará uma solução de CI/CD usando GitOps com Flux v2 e clusters Kubernetes habilitados para Azure Arc ou Azure Kubernetes Service (AKS). Usando o aplicativo Azure Vote de exemplo, você:

• Crie um cluster Kubernetes ou AKS habilitado para Azure Arc.
• Conecte seu aplicativo e repositórios GitOps ao Azure Repos ou GitHub.
• Implemente o fluxo de CI/CD com o Azure Pipelines ou o GitHub.
• Conecte seu Registro de Contêiner do Azure ao Azure DevOps e Kubernetes.
• Crie grupos de variáveis de ambiente ou segredos.
• Implante os dev ambientes e stage .
• Teste os ambientes de aplicativos.

Se não tiver uma subscrição do Azure, crie uma conta gratuita antes de começar.

Azure Cloud Shell

O Azure aloja o Azure Cloud Shell, um ambiente de shell interativo que pode utilizar através do seu browser. Pode utilizar o Bash ou o PowerShell com o Cloud Shell para trabalhar com os serviços do Azure. Você pode usar os comandos pré-instalados do Cloud Shell para executar o código neste artigo, sem precisar instalar nada em seu ambiente local.

Para iniciar o Azure Cloud Shell:

Opção	Exemplo/Ligação
Selecione Experimentar no canto superior direito de um código ou bloco de comandos. Selecionar Experimentar não copia automaticamente o código ou comando para o Cloud Shell.
Aceda a https://shell.azure.com ou selecione o botão Iniciar Cloud Shell para abrir o Cloud Shell no browser.
Selecione o botão Cloud Shell na barra de menus, na parte direita do portal do Azure.

Para usar o Azure Cloud Shell:

1. Inicie o Cloud Shell.

2. Selecione o botão Copiar em um bloco de código (ou bloco de comando) para copiar o código ou comando.

3. Cole o código ou comando na sessão do Cloud Shell selecionando Ctrl+Shift+V no Windows e Linux ou selecionando Cmd+Shift+V no macOS.

4. Selecione Enter para executar o código ou comando.

Pré-requisitos

• Conclua o tutorial anterior para aprender a implantar o GitOps em seu ambiente de CI/CD.

• Entenda os benefícios e a arquitetura desse recurso.

• Verifique se você tem:

  • Um cluster Kubernetes habilitado para Azure Arc conectado chamado arc-cicd-cluster.
  • Um Registo de Contentores do Azure ligado com integração AKS ou autenticação de cluster não AKS.

• Instale as versões mais recentes destas extensões da CLI de configuração do Kubernetes e Kubernetes habilitadas para Azure Arc:

  az extension add --name connectedk8s
  az extension add --name k8s-configuration
  

  • Para atualizar essas extensões para a versão mais recente, execute os seguintes comandos:

    az extension update --name connectedk8s
    az extension update --name k8s-configuration
    

Conectar o Registro de Contêiner do Azure ao Kubernetes

Habilite seu cluster Kubernetes para extrair imagens do seu Registro de Contêiner do Azure. Se for privado, a autenticação é necessária.

Conectar o Registro de Contêiner do Azure a clusters AKS existentes

Integre um Registro de Contêiner do Azure existente com clusters AKS existentes usando o seguinte comando:

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

Criar um segredo de pull de imagem

Para conectar clusters locais e não AKS ao seu Registro de Contêiner do Azure, crie um segredo de pull de imagem. O Kubernetes usa segredos de extração de imagem para armazenar as informações necessárias para autenticar seu registro.

Crie um segredo de pull de imagem com o seguinte kubectl comando. Repita para os dev namespaces e 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>

Para evitar ter que definir um imagePullSecret para cada Pod, considere adicionar o imagePullSecret à conta Service nos dev namespaces e stage . Para obter mais informações, consulte o tutorial do Kubernetes.

Dependendo do orquestrador de CI/CD de sua preferência, você pode continuar com instruções para o Azure DevOps ou para o GitHub.

Implementar CI/CD com o Azure DevOps

Este tutorial pressupõe familiaridade com o Azure DevOps, Azure Repos and Pipelines e Azure CLI.

Certifique-se de concluir as seguintes etapas primeiro:

• Entre nos Serviços de DevOps do Azure.
• Verifique se você tem permissões "Administrador de Compilação" e "Administrador de Projeto" para Repositórios do Azure e Pipelines do Azure.

Importar repositórios de aplicativos e GitOps para o Azure Repos

Importe um repositório de aplicativos e um repositório GitOps para o Azure Repos. Para este tutorial, use os seguintes repositórios de exemplo:

• arc-cicd-demo-src repositório de aplicativos

  • URL: https://github.com/Azure/arc-cicd-demo-src
  • Contém o exemplo de Aplicativo de Votação do Azure que você implantará usando o GitOps.
  • Importar o repositório com nome arc-cicd-demo-src

• arc-cicd-demo-gitops repositório GitOps

  • URL: https://github.com/Azure/arc-cicd-demo-gitops
  • Funciona como uma base para seus recursos de cluster que abrigam o Aplicativo Azure Vote.
  • Importar o repositório com nome arc-cicd-demo-gitops

Saiba mais sobre como importar repositórios Git.

Nota

Importar e usar dois repositórios separados para repositórios de aplicativos e GitOps pode melhorar a segurança e a simplicidade. As permissões e a visibilidade do aplicativo e dos repositórios GitOps podem ser ajustadas individualmente. Por exemplo, o administrador do cluster pode não encontrar as alterações no código do aplicativo relevantes para o estado desejado do cluster. Por outro lado, um desenvolvedor de aplicativos não precisa saber os parâmetros específicos para cada ambiente - um conjunto de valores de teste que fornecem cobertura para os parâmetros pode ser suficiente.

Conecte o repositório GitOps

Para implantar continuamente seu aplicativo, conecte o repositório de aplicativos ao cluster usando o GitOps. Seu repositório GitOps arc-cicd-demo-gitops contém os recursos básicos para colocar seu aplicativo em execução no cluster arc-cicd-cluster .

O repositório GitOps inicial contém apenas um manifesto que cria os namespaces dev e stage correspondentes aos ambientes de implantação.

A conexão GitOps que você criar irá, automaticamente:

• Sincronize os manifestos no diretório de manifesto.
• Atualize o estado do cluster.

O fluxo de trabalho CI/CD preenche o diretório de manifesto com manifestos extras para implantar o aplicativo.

1. Crie uma nova conexão GitOps com seu repositório arc-cicd-demo-gitops recém-importado no 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
   

   Gorjeta

   Para um cluster AKS (em vez de um cluster habilitado para Arc), use -cluster-type managedClusters.

2. Verifique o estado da implantação no portal do Azure.

   • Se for bem-sucedido, você verá ambos os dev namespaces criados stage no cluster.
   • Você também pode confirmar que, na página do portal do Azure do seu cluster, uma configuração cluster-config é criada na guia fGitOps .

Importar os pipelines de CI/CD

Agora que você sincronizou uma conexão GitOps, precisa importar os pipelines de CI/CD que criam os manifestos.

O repositório de aplicativos contém uma .pipeline pasta com pipelines usados para PRs, CI e CD. Importe e renomeie os três pipelines fornecidos no repositório de exemplo:

Nome do arquivo de pipeline	Description
.pipelines/az-vote-pr-pipeline.yaml	O pipeline de PR do aplicativo, chamado arc-cicd-demo-src PR
.pipelines/az-vote-ci-pipeline.yaml	O pipeline de CI do aplicativo, chamado arc-cicd-demo-src CI
.pipelines/az-vote-cd-pipeline.yaml	O pipeline de CD do aplicativo, chamado arc-cicd-demo-src CD

Conectar o Registro de Contêiner do Azure ao Azure DevOps

Durante o processo de CI, você implanta seus contêineres de aplicativo em um registro. Comece criando uma conexão de serviço do Azure:

1. No Azure DevOps, abra a página Conexões de serviço na página de configurações do projeto. No TFS, abra a página Serviços no ícone de configurações na barra de menu superior.
2. Escolha + Nova conexão de serviço e selecione o tipo de conexão de serviço que você precisa.
3. Preencha os parâmetros para a conexão de serviço. Para este tutorial:
   • Nomeie a conexão de serviço arc-demo-acr.
   • Selecione myResourceGroup como o grupo de recursos.
4. Selecione Conceder permissão de acesso a todos os pipelines.
   • Esta opção autoriza arquivos de pipeline YAML para conexões de serviço.
5. Escolha OK para criar a conexão.

Configurar conexão de serviço PR

O pipeline de CD manipula PRs no repositório GitOps. Ele precisa de uma conexão de serviço para fazer isso. Para configurar esta ligação:

1. No Azure DevOps, abra a página Conexões de serviço na página de configurações do projeto. No TFS, abra a página Serviços no ícone de configurações na barra de menu superior.
2. Escolha + Nova conexão de serviço e selecione o Generic tipo.
3. Preencha os parâmetros para a conexão de serviço. Para este tutorial:
   • URL do servidor https://dev.azure.com/<Your organization>/<Your project>/_apis/git/repositories/arc-cicd-demo-gitops
   • Deixe o nome de utilizador e a palavra-passe em branco.
   • Nomeie a conexão de serviço azdo-pr-connection.
4. Selecione Conceder permissão de acesso a todos os pipelines.
   • Esta opção autoriza arquivos de pipeline YAML para conexões de serviço.
5. Escolha OK para criar a conexão.

Instalar o conector GitOps

1. Adicione o repositório GitOps Connector aos repositórios Helm:

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

2. Instale o conector no cluster:

      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>
   

   Nota

   Azure Repos PAT token deve ter Build: Read & execute e Code: Full permissões.

3. Configure o Flux para enviar notificações para o conector 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
   

Para obter os detalhes sobre a instalação, consulte o repositório do GitOps Connector .

Criar grupos de variáveis de ambiente

Grupo de variáveis do repositório de aplicativos

Crie um grupo de variáveis chamado az-vote-app-dev. Defina os seguintes valores:

Variável	Value
AZURE_SUBSCRIPTION	(sua Conexão de Serviço do Azure, que deve ser arc-demo-acr do início do tutorial)
AZ_ACR_NAME	Nome do Azure ACR, por exemplo arc-demo-acr
ENVIRONMENT_NAME	Programador
MANIFESTS_BRANCH	master
MANIFESTS_REPO	arc-cicd-demo-gitops
ORGANIZATION_NAME	Nome da organização do Azure DevOps
PROJECT_NAME	Nome do projeto GitOps no Azure DevOps
REPO_URL	URL completo para o repositório GitOps
SRC_FOLDER	azure-vote
TARGET_CLUSTER	arc-cicd-cluster
TARGET_NAMESPACE	dev
VOTE_APP_TITLE	Pedido de voto
AKS_RESOURCE_GROUP	Grupo de recursos AKS. Necessário para testes automatizados.
AKS_NAME	Nome AKS. Necessário para testes automatizados.

Grupo de variáveis de ambiente de estágio

1. Clone o grupo de variáveis az-vote-app-dev .
2. Altere o nome para az-vote-app-stage.
3. Assegure os seguintes valores para as variáveis correspondentes:

Variável	Value
ENVIRONMENT_NAME	Fase
TARGET_NAMESPACE	stage

Agora você está pronto para implantar nos dev ambientes e stage .

Criar ambientes

Em seu projeto de DevOps do Azure, crie Dev e Stage ambientes. Para obter detalhes, consulte Criar e direcionar um ambiente.

Dê mais permissões ao serviço de compilação

O pipeline de CD usa o token de segurança da compilação em execução para autenticar no repositório GitOps. São necessárias mais permissões para que o pipeline crie uma nova ramificação, envie alterações por push e crie solicitações pull.

1. Vá para Project settings a página principal do projeto Azure DevOps.
2. Selecione Repos/Repositories.
3. Selecione Security.
4. Para o <Project Name> Build Service (<Organization Name>) e para o Project Collection Build Service (<Organization Name>) (digite no campo de pesquisa, se ele não aparecer), permita Contribute, Contribute to pull requestse Create branch.
5. Aceda a Pipelines/Settings
6. Opção de desligamento Protect access to repositories in YAML pipelines

Para obter mais informações, consulte:

• Conceder permissões VC ao serviço de compilação
• Gerenciar permissões de conta de serviço de compilação

Implantar o ambiente de desenvolvimento pela primeira vez

Com os pipelines de CI e CD criados, execute o pipeline de CI para implantar o aplicativo pela primeira vez.

Gasoduto CI

Durante a execução inicial do pipeline de CI, você pode obter um erro de autorização de recurso ao ler o nome da conexão de serviço.

1. Verifique se a variável que está sendo acessada está AZURE_SUBSCRIPTION.
2. Autorize o uso.
3. Execute novamente o pipeline.

O pipeline de IC:

• Garante que a alteração do aplicativo passe por todas as verificações de qualidade automatizadas para implantação.
• Faz qualquer validação extra que não pôde ser concluída no pipeline de RP.
  • Específico para GitOps, o pipeline também publica os artefatos para a confirmação que serão implantados pelo pipeline de CD.
• Verifica se a imagem do Docker foi alterada e se a nova imagem foi enviada por push.

Pipeline de CD

Durante a execução inicial do pipeline de CD, você precisa conceder ao pipeline acesso ao repositório GitOps. Selecione Exibir quando solicitado que o pipeline precisa de permissão para acessar um recurso. Em seguida, selecione Permitir para conceder permissão para usar o repositório GitOps para as execuções atuais e futuras do pipeline.

A execução bem-sucedida do pipeline de CI aciona o pipeline de CD para concluir o processo de implantação. Você implantará em cada ambiente de forma incremental.

Gorjeta

Se o pipeline de CD não acionar automaticamente:

1. Verifique se o nome corresponde ao gatilho de ramificação em .pipelines/az-vote-cd-pipeline.yaml
   • Deverá ser arc-cicd-demo-src CI.
2. Execute novamente o pipeline de CI.

Depois que o modelo e as alterações de manifesto no repositório GitOps forem gerados, o pipeline de CD cria uma confirmação, envia por push e cria uma RP para aprovação.

1. Encontre o PR criado pelo pipeline para o repositório GitOps.

2. Verifique as alterações no repositório GitOps. Deverá ver:

   • Alterações no modelo de leme de alto nível.
   • Manifestos Kubernetes de baixo nível que mostram as alterações subjacentes para o estado desejado. O Flux implanta esses manifestos.

3. Se tudo estiver bem, aprove e conclua o PR.

4. Após alguns minutos, o Flux pega a alteração e inicia a implantação.

5. Monitore o status de confirmação do Git na guia Histórico de confirmação. Quando estiver succeeded, o pipeline de CD inicia testes automatizados.

6. Encaminhe a porta localmente usando kubectl e verifique se o aplicativo funciona corretamente usando:

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

7. Exiba o aplicativo Azure Vote em seu navegador em http://localhost:8080/.

8. Vote nos seus favoritos e prepare-se para fazer algumas alterações no aplicativo.

Configurar aprovações de ambiente

Após a implantação do aplicativo, você não só pode fazer alterações no código ou nos modelos, mas também pode colocar o cluster em um estado incorreto sem querer.

Se o ambiente de desenvolvimento revelar uma interrupção após a implantação, evite que ele vá para ambientes posteriores usando aprovações de ambiente.

1. Em seu projeto de DevOps do Azure, vá para o ambiente que precisa ser protegido.
2. Navegue até Aprovações e Verificações do recurso.
3. Selecione Criar.
4. Forneça os aprovadores e uma mensagem opcional.
5. Selecione Criar novamente para concluir a adição da verificação de aprovação manual.

Para obter mais detalhes, consulte o tutorial Definir aprovação e verificações .

Da próxima vez que o pipeline de CD for executado, o pipeline será pausado após a criação do GitOps PR. Verifique se a alteração foi sincronizada corretamente e passa a funcionalidade básica. Aprove a verificação do pipeline para permitir que a alteração flua para o próximo ambiente.

Fazer uma alteração de aplicativo

Com esse conjunto de linha de base de modelos e manifestos que representam o estado no cluster, você fará uma pequena alteração no aplicativo.

1. No repositório arc-cicd-demo-src, edite azure-vote/src/azure-vote-front/config_file.cfg o arquivo.

2. Como "Cats vs Dogs" não está recebendo votos suficientes, altere-o para "Tabs vs Spaces" para aumentar a contagem de votos.

3. Confirme a alteração em uma nova ramificação, envie-a por push e crie uma solicitação pull. Essa sequência de etapas é o fluxo típico do desenvolvedor que inicia o ciclo de vida do CI/CD.

Pipeline de validação de RP

O gasoduto PR é a primeira linha de defesa contra uma mudança defeituosa. As verificações usuais de qualidade do código do aplicativo incluem revestimento e análise estática. Do ponto de vista do GitOps, você também precisa garantir a mesma qualidade para a infraestrutura resultante a ser implantada.

Os gráficos Dockerfile e Helm do aplicativo podem usar linting de maneira semelhante ao aplicativo.

Os erros encontrados durante o revestimento variam de arquivos YAML formatados incorretamente a sugestões de práticas recomendadas, como a definição de limites de CPU e memória para seu aplicativo.

Nota

Para obter a melhor cobertura do Helm linting em uma aplicação real, você precisará substituir valores que são razoavelmente semelhantes aos usados em um ambiente real.

Os erros encontrados durante a execução do pipeline aparecem na seção de resultados do teste da execução. A partir daqui, pode:

• Acompanhe as estatísticas úteis sobre os tipos de erro.
• Encontre a primeira confirmação na qual eles foram detetados.
• O estilo de rastreamento de pilha vincula as seções de código que causaram o erro.

Quando a execução do pipeline for concluída, você terá garantido a qualidade do código do aplicativo e do modelo que o implanta. Agora você pode aprovar e concluir o PR. O CI será executado novamente, regenerando os modelos e manifestos, antes de acionar o pipeline de CD.

Gorjeta

Em um ambiente real, não se esqueça de definir políticas de filial para garantir que o RP passe em suas verificações de qualidade. Para obter mais informações, consulte Definir políticas de filial.

Aprovações de processos de CD

Uma execução bem-sucedida do pipeline de CI aciona o pipeline de CD para concluir o processo de implantação. Desta vez, o pipeline exige que você aprove cada ambiente de implantação.

1. Aprove a implantação no dev ambiente.
2. Depois que o modelo e as alterações de manifesto no repositório GitOps forem gerados, o pipeline de CD cria uma confirmação, envia por push e cria uma RP para aprovação.
3. Verifique as alterações no repositório GitOps. Você deve ver:
   • Alterações no modelo de leme de alto nível.
   • Manifestos Kubernetes de baixo nível que mostram as alterações subjacentes para o estado desejado.
4. Se tudo estiver bem, aprove e conclua o PR.
5. Aguarde pela conclusão da implementação.
6. Como um teste de fumaça básico, navegue até a página do aplicativo e verifique se o aplicativo de votação agora exibe Tabs vs Spaces.
   • Encaminhe a porta localmente usando kubectl e verifique se o aplicativo funciona corretamente usando: kubectl port-forward -n dev svc/azure-vote-front 8080:80
   • Exiba o aplicativo Azure Vote em seu navegador e http://localhost:8080/ verifique se as opções de votação foram alteradas para Guias vs Espaços.
7. Repita as etapas de 1 a 7 para o stage ambiente.

A implantação está concluída.

Para obter uma visão geral detalhada de todas as etapas e técnicas implementadas nos fluxos de trabalho de CI/CD usados neste tutorial, consulte o diagrama de fluxo GitOps do Azure DevOps.

Implementar CI/CD com o GitHub

Este tutorial pressupõe familiaridade com o GitHub, GitHub Actions.

Aplicação Fork e repositórios GitOps

Fork um repositório de aplicativos e um repositório GitOps. Para este tutorial, use os seguintes repositórios de exemplo:

• arc-cicd-demo-src repositório de aplicativos

  • URL: https://github.com/Azure/arc-cicd-demo-src
  • Contém o exemplo de Aplicativo de Votação do Azure que você implantará usando o GitOps.

• arc-cicd-demo-gitops repositório GitOps

  • URL: https://github.com/Azure/arc-cicd-demo-gitops
  • Funciona como uma base para seus recursos de cluster que abrigam o Aplicativo Azure Vote.

Conecte o repositório GitOps

Para implantar continuamente seu aplicativo, conecte o repositório de aplicativos ao cluster usando o GitOps. Seu repositório GitOps arc-cicd-demo-gitops contém os recursos básicos para colocar seu aplicativo em execução no cluster arc-cicd-cluster .

O repositório GitOps inicial contém apenas um manifesto que cria os namespaces dev e stage correspondentes aos ambientes de implantação.

A conexão GitOps que você criar irá, automaticamente:

• Sincronize os manifestos no diretório de manifesto.
• Atualize o estado do cluster.

O fluxo de trabalho CI/CD preenche o diretório de manifesto com manifestos extras para implantar o aplicativo.

1. Crie uma nova conexão GitOps com seu repositório arc-cicd-demo-gitops recém-bifurcado no 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. Verifique o estado da implantação no portal do Azure.

   • Se for bem-sucedido, você verá ambos os dev namespaces criados stage no cluster.

Instalar o conector GitOps

1. Adicione o repositório GitOps Connector aos repositórios Helm:

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

2. Instale o conector no cluster:

      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. Configure o Flux para enviar notificações para o conector 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
   

Para obter os detalhes sobre a instalação, consulte o repositório do GitOps Connector .

Criar segredos do GitHub

Criar segredos do repositório GitHub

Segredo	Value
AZURE_CREDENTIALS	Credenciais para o Azure no seguinte formato {"clientId":"GUID","clientSecret":"GUID","subscriptionId":"GUID","tenantId":"GUID"}
AZ_ACR_NAME	Nome do Azure ACR, por exemplo 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	Pedido de voto
AKS_RESOURCE_GROUP	Grupo de recursos AKS. Necessário para testes automatizados.
AKS_NAME	Nome AKS. Necessário para testes automatizados.
PAT	Token PAT do GitHub com permissão para PR para o repositório GitOps

Criar segredos de ambiente do GitHub

1. Crie az-vote-app-dev um ambiente com os seguintes segredos:

Segredo	Value
ENVIRONMENT_NAME	Programador
TARGET_NAMESPACE	dev

1. Crie az-vote-app-stage um ambiente com os seguintes segredos:

Segredo	Value
ENVIRONMENT_NAME	Fase
TARGET_NAMESPACE	stage

Agora você está pronto para implantar nos dev ambientes e stage .

Fluxo de trabalho de desenvolvimento de CI/CD

Para iniciar o fluxo de trabalho de desenvolvimento de CI/CD, altere o código-fonte. No repositório do aplicativo, atualize os valores no .azure-vote/src/azure-vote-front/config_file.cfg arquivo e envie as alterações para o repositório.

O fluxo de trabalho de desenvolvimento de CI/CD:

• Garante que a alteração do aplicativo passe por todas as verificações de qualidade automatizadas para implantação.
• Faz qualquer validação extra que não pôde ser concluída no pipeline de RP.
• Verifica se a imagem do Docker foi alterada e se a nova imagem foi enviada por push.
• Publica os artefatos (tags de imagem do Docker, modelos de manifesto, utils) que serão usados pelos seguintes estágios do CD.
• Implanta o aplicativo no ambiente de desenvolvimento.
  • Gera manifestos para o repositório GitOps.
  • Cria um PR para o repositório GitOps para aprovação.

1. Encontre o PR criado pelo pipeline para o repositório GitOps.

2. Verifique as alterações no repositório GitOps. Deverá ver:

   • Alterações no modelo de leme de alto nível.
   • Manifestos Kubernetes de baixo nível que mostram as alterações subjacentes para o estado desejado. O Flux implanta esses manifestos.

3. Se tudo estiver bem, aprove e conclua o PR.

4. Após alguns minutos, o Flux pega a alteração e inicia a implantação.

5. Monitore o status de confirmação do Git na guia Histórico de confirmação. Assim que for succeeded, o CD Stage fluxo de trabalho será iniciado.

6. Encaminhe a porta localmente usando kubectl e verifique se o aplicativo funciona corretamente usando:

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

7. Exiba o aplicativo Azure Vote em seu navegador em http://localhost:8080/.

8. Vote nos seus favoritos e prepare-se para fazer algumas alterações no aplicativo.

Fluxo de trabalho do CD Stage

O fluxo de trabalho do CD Stage é iniciado automaticamente assim que o Flux implanta com êxito o aplicativo no ambiente de desenvolvimento e notifica as ações do GitHub por meio do GitOps Connector.

O fluxo de trabalho do CD Stage:

• Executa testes de fumaça de aplicativos em ambiente de desenvolvimento
• Implanta o aplicativo no ambiente do Palco.
  • Gera manifestos para o repositório GitOps
  • Cria um PR para o repositório GitOps para aprovação

Depois que o PR de manifestos para o ambiente Stage é mesclado e o Flux aplica com êxito todas as alterações, o status de confirmação do Git é atualizado no repositório GitOps. A implantação está concluída.

Para obter uma visão geral detalhada de todas as etapas e técnicas implementadas nos fluxos de trabalho de CI/CD usados neste tutorial, consulte o diagrama de fluxo GitOps do GitHub.

Clean up resources (Limpar recursos)

Se você não vai continuar a usar este aplicativo, exclua todos os recursos com as seguintes etapas:

1. Exclua a conexão de configuração do Azure Arc GitOps:

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

2. Excluir conector 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
   

Próximos passos

Neste tutorial, você configurou um fluxo de trabalho completo de CI/CD que implementa o DevOps desde o desenvolvimento do aplicativo até a implantação. As alterações no aplicativo acionam automaticamente a validação e a implantação, limitadas por aprovações manuais.

Avance para nosso artigo conceitual para saber mais sobre GitOps e configurações com o Kubernetes habilitado para Azure Arc.

Fluxo de trabalho conceitual de CI/CD usando GitOps