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 estage
. - 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:
Inicie o Cloud Shell.
Selecione o botão Copiar em um bloco de código (ou bloco de comando) para copiar o código ou comando.
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.
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.
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
.Verifique o estado da implantação no portal do Azure.
- Se for bem-sucedido, você verá ambos os
dev
namespaces criadosstage
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
.
- Se for bem-sucedido, você verá ambos os
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:
- 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.
- Escolha + Nova conexão de serviço e selecione o tipo de conexão de serviço que você precisa.
- 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.
- Selecione Conceder permissão de acesso a todos os pipelines.
- Esta opção autoriza arquivos de pipeline YAML para conexões de serviço.
- 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:
- 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.
- Escolha + Nova conexão de serviço e selecione o
Generic
tipo. - 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.
- URL do servidor
- Selecione Conceder permissão de acesso a todos os pipelines.
- Esta opção autoriza arquivos de pipeline YAML para conexões de serviço.
- Escolha OK para criar a conexão.
Instalar o conector GitOps
Adicione o repositório GitOps Connector aos repositórios Helm:
helm repo add gitops-connector https://azure.github.io/gitops-connector/
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 terBuild: Read & execute
eCode: Full
permissões.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
- Clone o grupo de variáveis az-vote-app-dev .
- Altere o nome para az-vote-app-stage.
- 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.
- Vá para
Project settings
a página principal do projeto Azure DevOps. - Selecione
Repos/Repositories
. - Selecione
Security
. - Para o
<Project Name> Build Service (<Organization Name>)
e para oProject Collection Build Service (<Organization Name>)
(digite no campo de pesquisa, se ele não aparecer), permitaContribute
,Contribute to pull requests
eCreate branch
. - Aceda a
Pipelines/Settings
- 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.
- Verifique se a variável que está sendo acessada está AZURE_SUBSCRIPTION.
- Autorize o uso.
- 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:
- Verifique se o nome corresponde ao gatilho de ramificação em
.pipelines/az-vote-cd-pipeline.yaml
- Deverá ser
arc-cicd-demo-src CI
.
- Deverá ser
- 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.
Encontre o PR criado pelo pipeline para o repositório GitOps.
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.
Se tudo estiver bem, aprove e conclua o PR.
Após alguns minutos, o Flux pega a alteração e inicia a implantação.
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.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 em
http://localhost:8080/
.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.
- Em seu projeto de DevOps do Azure, vá para o ambiente que precisa ser protegido.
- Navegue até Aprovações e Verificações do recurso.
- Selecione Criar.
- Forneça os aprovadores e uma mensagem opcional.
- 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.
No repositório arc-cicd-demo-src, edite
azure-vote/src/azure-vote-front/config_file.cfg
o arquivo.Como "Cats vs Dogs" não está recebendo votos suficientes, altere-o para "Tabs vs Spaces" para aumentar a contagem de votos.
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.
- Aprove a implantação no
dev
ambiente. - 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.
- 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.
- Se tudo estiver bem, aprove e conclua o PR.
- Aguarde pela conclusão da implementação.
- 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.
- Encaminhe a porta localmente usando
- 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.
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
Verifique o estado da implantação no portal do Azure.
- Se for bem-sucedido, você verá ambos os
dev
namespaces criadosstage
no cluster.
- Se for bem-sucedido, você verá ambos os
Instalar o conector GitOps
Adicione o repositório GitOps Connector aos repositórios Helm:
helm repo add gitops-connector https://azure.github.io/gitops-connector/
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>
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
- Crie
az-vote-app-dev
um ambiente com os seguintes segredos:
Segredo | Value |
---|---|
ENVIRONMENT_NAME | Programador |
TARGET_NAMESPACE | dev |
- 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.
Encontre o PR criado pelo pipeline para o repositório GitOps.
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.
Se tudo estiver bem, aprove e conclua o PR.
Após alguns minutos, o Flux pega a alteração e inicia a implantação.
Monitore o status de confirmação do Git na guia Histórico de confirmação. Assim que for
succeeded
, oCD Stage
fluxo de trabalho será iniciado.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 em
http://localhost:8080/
.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:
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
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.