Share via

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

  • Artigo

Neste tutorial, você vai configurar uma solução de CI/CD usando o GitOps com o Flux v2 e clusters do Kubernetes habilitados para Azure Arc ou do Serviço de Kubernetes do Azure. Com o aplicativo de amostra Azure Vote, você pode:

  • Criar um cluster do Kubernetes ou Serviço de Kubernetes do Azure habilitado para Azure Arc.
  • Conecte seu aplicativo e os repositórios GitOps ao Azure Repos ou ao GitHub.
  • Implementar o fluxo de CI/CD com o Azure Pipelines ou o GitHub.
  • Conectar o seu Registro de Contêiner do Azure ao Azure DevOps e Kubernetes.
  • Criar grupos de variáveis de ambiente ou segredos.
  • Implantar os ambientes dev e stage.
  • Testar os ambientes de aplicativo.

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

Azure Cloud Shell

O Azure hospeda o Azure Cloud Shell, um ambiente de shell interativo que pode ser usado por meio do navegador. É possível usar o bash ou o PowerShell com o Cloud Shell para trabalhar com os serviços do Azure. É possível usar os comandos pré-instalados do Cloud Shell para executar o código neste artigo, sem precisar instalar nada no seu ambiente local.

Para iniciar o Azure Cloud Shell:

Opção Exemplo/Link
Selecione Experimentar no canto superior direito de um bloco de código ou de comando. Selecionar Experimentar não copia automaticamente o código nem o comando para o Cloud Shell. Captura de tela que mostra um exemplo de Experimente para o Azure Cloud Shell.
Acesse https://shell.azure.com ou selecione o botão Iniciar o Cloud Shell para abri-lo no navegador. Botão para iniciar o Azure Cloud Shell.
Selecione o botão Cloud Shell na barra de menus no canto superior direito do portal do Azure. Captura de tela que mostra o botão Cloud Shell no 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 o comando.

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

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

Pré-requisitos

Conectar Registro de Contêiner do Azure ao Kubernetes

Habilitar o cluster do Kubernetes para efetuar pull de imagens do seu Registro de Contêiner do Azure. Se for privado, a autenticação será necessária.

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

Integrar um Registro de Contêiner do Azure existente a clusters do AKS 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 não-AKS e locais ao seu Registro de Contêiner do Azure, crie um segredo de pull de imagem. O Kubernetes usa segredos de pull de imagem para armazenar as informações necessárias para autenticar o registro.

Crie um segredo de pull de imagem com o comando kubectl a seguir. Repita para os namespaces dev 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 a definição de um imagePullSecret para cada Pod, considere adicionar o imagePullSecret à conta de serviço nos namespaces dev e stage. Para saber mais, confira o tutorial do Kubernetes.

Dependendo do orquestrador de CI/CD que preferir, você pode continuar com as 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, Pipelines e a CLI do Azure.

Conclua primeiro as seguintes etapas:

Importar os repositórios de aplicativos e do GitOps no Azure Repos

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

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

  • Repositório do GitOps arc-cicd-demo-gitops

Saiba mais sobre a importação de repositórios Git.

Observação

Importar e usar dois repositórios separados para repositórios de aplicativos e do GitOps pode aumentar a segurança e a simplicidade. As permissões e a visibilidade dos repositórios de aplicativos e do GitOps podem ser ajustadas individualmente. Por exemplo, o administrador de 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 de cada ambiente – um conjunto de valores de teste que fornecem cobertura para os parâmetros pode ser suficiente.

Conectar o repositório do GitOps

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

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

A conexão do GitOps que você criar fará o seguinte automaticamente:

  • Sincronizará os manifestos no diretório de manifesto.
  • Atualizará o estado do cluster.

O fluxo de trabalho de CI/CD preenche o diretório de manifestos com manifestos adicionais a serem implantados no aplicativo.

  1. Crie uma conexão do GitOps com seu repositório arc-cicd-demo-gitops importado recentemente 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

    Dica

    Para um cluster do 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 ela for bem-sucedida, você verá os namespaces dev e stage criados no cluster.
    • Também é possível confirmar que na página do portal do Azure do cluster, uma configuração cluster-config é criada na guia fGitOps.

Importar os pipelines de CI/CD

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

O repositório do aplicativo contém uma pasta .pipeline com pipelines que são usados para PRs, CI e CD. Importe e renomeie os três pipelines fornecidos no repositório de amostra:

Nome do arquivo de pipeline Descrição
.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 Registro de Contêiner do Azure ao Azure DevOps

Durante o processo de CI, você implanta seus contêineres de aplicativos 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 menus superior.
  2. Escolha + Nova conexão de serviço e selecione o tipo de conexão de serviço de que você precisa.
  3. Preencha os parâmetros para a conexão de serviço. Neste tutorial:
    • Nomeie a conexão de serviço como arc-demo-acr.
    • Selecione myResourceGroup como o grupo de recursos.
  4. Selecione Conceder permissão de acesso a todos os pipelines.
    • Essa opção autoriza arquivos de pipeline do YAML para conexões de serviço.
  5. Escolha OK para criar a conexão.

Configurar a conexão de serviço de PR

O pipeline de CD manipula PRs no repositório GitOps. Para isso, uma conexão de serviço é necessária. Para configurar essa conexã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 menus superior.
  2. Escolha + Nova conexão de serviço e selecione Generictipo.
  3. Preencha os parâmetros para a conexão de serviço. Neste tutorial:
    • URL do Servidorhttps://dev.azure.com/<Your organization>/<Your project>/_apis/git/repositories/arc-cicd-demo-gitops
    • Mantenha “Nome do usuário” e “Senha” em branco.
    • Nomeie a conexão de serviço azdo-pr-connection.
  4. Selecione Conceder permissão de acesso a todos os pipelines.
    • Essa opção autoriza arquivos de pipeline do YAML para conexões de serviço.
  5. Escolha OK para criar a conexão.

Instalar conector do GitOps

  1. Adicione o repositório de conector do GitOps a repositórios do Helm:

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

  2. Instalar 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>

    Observação

    Azure Repos PAT token deve ter Build: Read & execute e de Code: Full.

  3. Configurar o Flux para enviar notificações ao conector do 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 mais detalhes sobre a instalação, consulte o repositório de Conector do GitOps.

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 Valor
AZURE_SUBSCRIPTION (sua Conexão de Serviço do Azure, que deve ser a arc-demo-acr estabelecida antes no tutorial)
AZ_ACR_NAME Nome do ACR do Azure, por exemplo, arc-demo-acr
ENVIRONMENT_NAME Desenvolvimento
MANIFESTS_BRANCH master
MANIFESTS_REPO arc-cicd-demo-gitops
ORGANIZATION_NAME Nome da organização do Azure DevOps
PROJECT_NAME Nome do projeto do GitOps no Azure DevOps
REPO_URL URL completa do repositório do GitOps
SRC_FOLDER azure-vote
TARGET_CLUSTER arc-cicd-cluster
TARGET_NAMESPACE dev
VOTE_APP_TITLE Aplicativo de votação
AKS_RESOURCE_GROUP Grupo de recursos do AKS. Necessário para testes automatizados.
AKS_NAME Nome do AKS. Necessário para testes automatizados.

Preparar grupos de variáveis de ambiente

  1. Clone o grupo de variáveis az-vote-app-dev.
  2. Altere o nome para az-vote-app-stage.
  3. Garanta os seguintes valores para as variáveis correspondentes:
Variável Valor
ENVIRONMENT_NAME Estágio
TARGET_NAMESPACE stage

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

Criar ambientes

No projeto do Azure DevOps, crie os ambientes Dev e Stage. Para saber mais, confira Criar e interagir com um ambiente.

Conceder mais permissões para o serviço de compilação

O pipeline de CD usa o token de segurança do build em execução para se autenticar no repositório do GitOps. Mais permissões são necessárias para que o pipeline crie uma ramificação, efetue push das alterações e crie solicitações de pull.

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

Para obter mais informações, consulte:

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.

Pipeline de CI

Durante a execução inicial do pipeline de CI, você poderá 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 é AZURE_SUBSCRIPTION.
  2. Autorize o uso.
  3. Executar novamente o pipeline.

O pipeline de CI:

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

Pipeline de CD

Durante a execução inicial do pipeline de CD, é necessário conceder ao pipeline acesso ao repositório de GitOps. Selecione Exibir quando for solicitada para o pipeline a permissão a fim de acessar um recurso. Em seguida, selecione Permitir para conceder a permissão para usar o repositório de GitOps em execuções atuais e futuras do pipeline.

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

Dica

Se o pipeline de CD não for disparado de forma automática:

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

Depois da geração das alterações do modelo e do manifesto no repositório de GitOps, o pipeline de CD cria uma confirmação, envia-a por push e cria uma PR para aprovação.

  1. Encontre a PR criada pelo pipeline para o repositório do GitOps.

  2. Verifique as alterações no repositório do GitOps. Você deverá ver:

    • Alterações de modelo Helm de alto nível.
    • Manifestos do Kubernetes de nível baixo que mostram as alterações subjacentes ao estado desejado. O Flux implanta esses manifestos.

  3. Se tudo estiver correto, aprove e conclua a PR.

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

  5. Monitore o status do Git Commit na guia “Histórico de commit”. Quando ele for succeeded, o pipeline de CD iniciará o teste automatizado.

  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 em 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ó poderá fazer alterações no código ou nos modelos, como também poderá colocar o cluster involuntariamente em um estado inválido.

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

  1. No seu projeto do Azure DevOps, vá para o ambiente que precisa ser protegido.
  2. Navegue para 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, confira o tutorial Definir aprovação e verificações.

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

Alterar um aplicativo

Com esse conjunto de linhas 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 o arquivo azure-vote/src/azure-vote-front/config_file.cfg.

  2. Como "Gatos vs Cachorros" não está recebendo votos suficientes, altere para "Guias vs Espaços" para aumentar a contagem de votos.

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

Pipeline de validação de PR

O pipeline de PR é a primeira linha de defesa contra uma alteração com falha. As verificações de qualidade do código do aplicativo usuais incluem análise estática e lint. De uma perspectiva do GitOps, você também precisa garantir a mesma qualidade para que a infraestrutura resultante seja implantada.

Os gráficos Dockerfile e Helm do aplicativo podem usar o lint de forma semelhante ao aplicativo.

Os erros encontrados durante o lint variam de arquivos YAML formatados incorretamente a sugestões de melhores práticas, como definir limites de CPU e memória para o aplicativo.

Observação

Para obter a melhor cobertura de lint do Helm em um aplicativo real, você precisará substituir valores razoavelmente semelhantes aos usados em um ambiente real.

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

  • Acompanhar as estatísticas úteis sobre os tipos de erro.
  • Localizar o primeiro commit em que eles foram detectados.
  • Fazer o rastreamento de pilha dos links de estilo para as seções de código que causaram o erro.

Após a execução do pipeline, a qualidade do código do aplicativo e do modelo que o implanta terá sido garantida. Agora você pode aprovar e concluir a PR. A CI será executada novamente, regenerando os modelos e manifestos antes de disparar o pipeline de CD.

Dica

Em um ambiente real, não se esqueça de definir as políticas de branch para garantir que a PR transmita suas verificações de qualidade. Para saber mais, confira Definir políticas de branch.

Aprovações do processo de CD

Uma execução bem-sucedida do pipeline de CI dispara 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 para o ambiente dev.
  2. Depois da geração das alterações do modelo e do manifesto no repositório de GitOps, o pipeline de CD cria uma confirmação, envia-a por push e cria uma PR para aprovação.
  3. Verifique as alterações no repositório do GitOps. Você deverá ver:
    • Alterações de modelo Helm de alto nível.
    • Manifestos do Kubernetes de nível baixo que mostram as alterações subjacentes ao estado desejado.
  4. Se tudo estiver correto, aprove e conclua a PR.
  5. Aguarde até que a implantação seja concluída.
  6. Como um smoke test básico, navegue até a página do aplicativo e verifique se o aplicativo de votação agora exibe Guias vs Espaços.
    • 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 no navegador em http://localhost:8080/ e 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 ambiente stage.

A implantação foi 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, confira o Diagrama do fluxo de GitOps do Azure DevOps.

Implementar CI/CD com o GitHub

Este tutorial presume familiaridade com o GitHub, o GitHub Actions.

Bifurcação de aplicativos e repositórios de GitOps

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

Conectar o repositório do GitOps

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

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

A conexão do GitOps que você criar fará o seguinte automaticamente:

  • Sincronizará os manifestos no diretório de manifesto.
  • Atualizará o estado do cluster.

O fluxo de trabalho de CI/CD preenche o diretório de manifestos com manifestos adicionais a serem implantados no aplicativo.

  1. Crie uma conexão do GitOps com seu repositório arc-cicd-demo-gitops bifurcado recentemente 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 ela for bem-sucedida, você verá os namespaces dev e stage criados no cluster.

Instalar conector do GitOps

  1. Adicione o repositório de conector do GitOps a repositórios do Helm:

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

  2. Instalar 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. Configurar o Flux para enviar notificações ao conector do 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 mais detalhes sobre a instalação, consulte o repositório de Conector do GitOps.

Criar segredos do GitHub

Criar segredos de repositório do GitHub

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

Criar segredos de ambiente do GitHub

  1. Criar ambiente az-vote-app-dev com os segredos a seguir:
Segredo Valor
ENVIRONMENT_NAME Desenvolvimento
TARGET_NAMESPACE dev
  1. Criar ambiente az-vote-app-stage com os segredos a seguir:
Segredo Valor
ENVIRONMENT_NAME Estágio
TARGET_NAMESPACE stage

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

Fluxo de trabalho de desenvolvimento de CI/CD

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

O fluxo de trabalho de desenvolvimento de CI/CD:

  • Garante que a alteração do aplicativo seja aprovada por todas as verificações de qualidade automatizadas para a implantação.
  • Faz qualquer validação adicional que não pôde ser concluída no pipeline de PR.
  • Verifica se a imagem do Docker foi alterada e a nova imagem foi enviada por push.
  • Publica os artefatos (marcas de imagem do Docker, modelos de manifesto, utilitários) que serão usadas pelas seguintes fases de CD.
  • Implanta o aplicativo no ambiente de desenvolvimento.
    • Gera manifestos no repositório de GitOps.
    • Cria uma PR relativa ao repositório de GitOps para aprovação.

  1. Encontre a PR criada pelo pipeline para o repositório do GitOps.

  2. Verifique as alterações no repositório do GitOps. Você deverá ver:

    • Alterações de modelo Helm de alto nível.
    • Manifestos do Kubernetes de nível baixo que mostram as alterações subjacentes ao estado desejado. O Flux implanta esses manifestos.

  3. Se tudo estiver correto, aprove e conclua a PR.

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

  5. Monitore o status do Git Commit na guia “Histórico de commit”. Quando ele for succeeded, o fluxo de trabalho CD Stage 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 em seus favoritos e prepare-se para fazer algumas alterações no aplicativo.

Fluxo de trabalho da fase de CD

O fluxo de trabalho da fase de CD é iniciado automaticamente após o Flux implantar com êxito o aplicativo no ambiente de desenvolvimento e notificar as ações do GitHub por meio do Conector do GitOps.

O fluxo de trabalho da fase de CD:

  • Executa testes de verificação de build do aplicativo em relação ao ambiente de desenvolvimento
  • Implanta o aplicativo na fase de desenvolvimento.
    • Gera manifestos para o repositório GitOps
    • Cria uma PR para o repositório GitOps para aprovação

Após a mesclagem da PR dos manifestos com o ambiente de preparo e aplicação de todas as alterações pelo fluxo, o status do Git Commit é atualizado no repositório de GitOps. A implantação foi 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, confira o Diagrama do fluxo de GitOps do GitHub.

Limpar recursos

Se você não quiser continuar usando esse aplicativo, exclua qualquer recurso seguindo estas etapas:

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

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

  2. Excluir Conector do 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óximas etapas

Neste tutorial, você configurou um fluxo de trabalho completo de CI/CD que implementa o DevOps do desenvolvimento de aplicativos por meio da implantação. As alterações no aplicativo disparam automaticamente a validação e a implantação, restringidas por aprovações manuais.

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

Conceito: processo de CD com o GitOpsExemplo de implementação: explore o fluxo de CI/CD com o GitOps