Fluxo de trabalho de CI/CD usando GitOps - Kubernetes habilitado para Azure Arc

Importante

O fluxo de trabalho descrito neste documento usa GitOps com Flux v1. O GitOps com Flux v2 agora está disponível para clusters Kubernetes habilitados para Azure Arc e Serviço Kubernetes do Azure (AKS); saiba mais sobre o fluxo de trabalho de CI/CD usando GitOps com Flux v2. Recomendamos migrar para o Flux v2 o mais rápido possível.

O suporte para recursos de configuração de cluster baseados no Flux v1 criados antes de 1º de janeiro de 2024 terminará em 24 de maio de 2025. A partir de 1º de janeiro de 2024, você não poderá criar novos recursos de configuração de cluster baseados no Flux v1.

As implantações modernas do Kubernetes abrigam vários aplicativos, clusters e ambientes. Com o GitOps, você pode gerenciar essas configurações complexas mais facilmente, rastreando o estado desejado dos ambientes Kubernetes declarativamente com o Git. Usando ferramentas comuns do Git para rastrear o estado do cluster, você pode aumentar a responsabilidade, facilitar a investigação de falhas e habilitar a automação para gerenciar ambientes.

Esta visão geral conceitual explica o GitOps como uma realidade no ciclo de vida completo de alteração de aplicativos usando o Azure Arc, Azure Repos e Azure Pipelines. Vá para um exemplo de uma única alteração de aplicativo para ambientes Kubernetes controlados por GitOps.

Arquitetura

Considere um aplicativo implantado em um ou mais ambientes Kubernetes.

Repositório de aplicativos

O repositório de aplicativos contém o código do aplicativo no qual os desenvolvedores trabalham durante o loop interno. Os modelos de implantação do aplicativo vivem neste repositório em um formato genérico, como Helm ou Kustomize. Os valores específicos do ambiente não são armazenados. As alterações nesse repositório invocam um pipeline de RP ou CI que inicia o processo de implantação.

Container Registry

O registro de contêiner contém todas as imagens de primeira e de terceiros usadas nos ambientes Kubernetes. Marque imagens de aplicativos primários com tags legíveis por humanos e o Git commit usado para criar a imagem. Armazene em cache imagens de terceiros para segurança, velocidade e resiliência. Defina um plano para testes oportunos e integração de atualizações de segurança. Para obter mais informações, consulte o guia ACR Consumir e manter conteúdo público para obter um exemplo.

Gasoduto PR

PRs para o repositório de aplicativos são fechados em uma execução bem-sucedida do pipeline de RP. Esse pipeline executa as portas de qualidade básicas, como linting e testes de unidade no código do aplicativo. O pipeline testa o aplicativo e os modelos Dockerfiles e Helm usados para implantação em um ambiente Kubernetes. As imagens do Docker devem ser criadas e testadas, mas não enviadas por push. Mantenha a duração do pipeline relativamente curta para permitir uma iteração rápida.

Gasoduto CI

O pipeline de CI do aplicativo executa todas as etapas do pipeline de RP e expande as verificações de teste e implantação. O pipeline pode ser executado para cada commit, ou em uma cadência regular com um grupo de commits. Nesta etapa, execute testes de aplicativos muito longos para um pipeline de RP. Envie imagens do Docker para o Registro de contêiner após a criação em preparação para a implantação. O modelo substituído pode ser alinhado com um conjunto de valores de teste. As imagens usadas no tempo de execução do serviço devem ser alinhadas, construídas e testadas neste ponto. Na compilação de CI especificamente, os artefatos são publicados para que a etapa do CD seja consumida em preparação para a implantação.

Flux

O Flux é um serviço que é executado em cada cluster e é responsável por manter o estado desejado. O serviço frequentemente sonda o repositório GitOps em busca de alterações em seu cluster e as aplica.

CD Pipeline

O pipeline de CD é acionado automaticamente por compilações de CI bem-sucedidas. Ele usa os modelos publicados anteriormente, substitui os valores de ambiente e abre um PR para o repositório GitOps para solicitar uma alteração no estado desejado de um ou mais clusters do Kubernetes. Os administradores de cluster analisam o PR de alteração de estado e aprovam a mesclagem para o repositório GitOps. O gasoduto, então, aguarda a conclusão do PR, o que permite que o Flux pegue a mudança de estado.

Repositório GitOps

O repositório GitOps representa o estado desejado atual de todos os ambientes em clusters. Qualquer alteração nesse repositório é coletada pelo serviço Flux em cada cluster e implantada. Os RPs são criados com alterações no estado desejado, revisados e mesclados. Esses PRs contêm alterações nos modelos de implantação e nos manifestos renderizados do Kubernetes resultantes. Os manifestos renderizados de baixo nível permitem uma inspeção mais cuidadosa das alterações normalmente não vistas no nível do modelo.

Clusters do Kubernetes

Pelo menos um cluster Kubernetes habilitado para Azure Arc atende aos diferentes ambientes necessários para o aplicativo. Por exemplo, um único cluster pode servir a um ambiente de desenvolvimento e QA por meio de namespaces diferentes. Um segundo cluster pode fornecer separação mais fácil de ambientes e controle mais refinado.

Exemplo de fluxo de trabalho

Como desenvolvedora de aplicativos, Alice:

• Grava o código do aplicativo.
• Determina como executar o aplicativo em um contêiner do Docker.
• Define os modelos que executam o contêiner e os serviços dependentes em um cluster do Kubernetes.

Embora Alice saiba que o aplicativo precisa da capacidade de ser executado em vários ambientes, ela não sabe as configurações específicas para cada ambiente.

Suponha que Alice queira fazer uma alteração de aplicativo que altere a imagem do Docker usada no modelo de implantação de aplicativo.

1. Alice altera o modelo de implantação, envia-o por push para uma ramificação remota no repositório do aplicativo e abre uma RP para revisão.
2. Alice pede à sua equipa que reveja a mudança.
   • O pipeline de RP executa a validação.
   • Após uma execução bem-sucedida do pipeline, a equipe assina e a alteração é mesclada.
3. O pipeline de CI valida a alteração de Alice e é concluído com êxito.
   • A alteração é segura para implantação no cluster e os artefatos são salvos na execução do pipeline de CI.
4. A alteração de Alice mescla e aciona o pipeline de CD.
   • O pipeline de CD pega os artefatos armazenados pela execução do pipeline de CI de Alice.
   • O pipeline de CD substitui os modelos por valores específicos do ambiente e prepara quaisquer alterações em relação ao estado do cluster existente no repositório GitOps.
   • O pipeline de CD cria um PR para o repositório GitOps com as alterações desejadas no estado do cluster.
5. A equipa de Alice analisa e aprova o seu PR.
   • A alteração é mesclada na ramificação de destino correspondente ao ambiente.
6. Em poucos minutos, o Flux percebe uma mudança no repositório GitOps e puxa a mudança de Alice.
   • Devido à alteração da imagem do Docker, o pod do aplicativo requer uma atualização.
   • O Flux aplica a alteração ao cluster.
7. Alice testa o ponto de extremidade do aplicativo para verificar se a implantação foi concluída com êxito.

   Nota

   Para mais ambientes direcionados para implantação, o pipeline de CD itera criando um PR para o próximo ambiente e repete as etapas 4 a 7. O processo muitos precisam de aprovação extra para implantações ou ambientes mais arriscados, como uma alteração relacionada à segurança ou um ambiente de produção.

8. Depois que todos os ambientes tiverem recebido implantações bem-sucedidas, o pipeline será concluído.

Próximos passos

Saiba mais sobre como criar conexões entre seu cluster e um repositório Git como um recurso de configuração com o Kubernetes habilitado para Azure Arc