Fluxo de trabalho de CI/CD usando o GitOps (Flux v2)
As implantações modernas do Kubernetes contêm vários aplicativos, clusters e ambientes. Com o GitOps, você pode gerenciar essas configurações complexas com mais facilidade, acompanhando o estado desejado dos ambientes do Kubernetes declarativamente com o Git. Ao usar ferramentas Git comuns para declarar o estado do cluster, você pode aumentar a responsabilidade, facilitar a investigação de falhas e habilitar a automação para gerenciar ambientes.
Este artigo descreve como o GitOps se encaixa no ciclo de vida completo de alterações do aplicativo usando o Azure Arc, Azure Repos e Azure Pipelines. Ele também fornece um exemplo de uma única alteração de aplicativo para ambientes do Kubernetes controlados por GitOps.
Arquitetura
Este diagrama mostra o fluxo de trabalho de CI/CD para um aplicativo implantado em um ou mais ambientes do Kubernetes.
Repositório de código do aplicativo
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 residem nesse repositório em um formato genérico, como Helm ou Kustomize. Os valores específicos do ambiente não são armazenados no repositório.
As alterações neste repositório invocam um pipeline de PR ou CI que inicia o processo de implantação.
Registro de contêiner
O registro de contêiner contém todas as imagens próprias e de terceiros usadas nos ambientes do Kubernetes. As imagens próprias de aplicativo são marcadas com marcações legíveis e o commit do Git usado para criar a imagem. Imagens de terceiros podem ser armazenadas em cache para ajudar na segurança, velocidade e resiliência. Defina um plano para teste e integração oportunos de atualizações de segurança.
Para obter mais informações, consulte Como consumir e manter conteúdo público com Tarefas do Registro de Contêiner do Azure.
Pipeline de PR
As pull requests de desenvolvedores feitas no repositório de aplicativos são fechadas em uma execução bem-sucedida do pipeline de PR. Esse pipeline executa as portas de qualidade básica, como lint e testes de unidade no código do aplicativo. O pipeline testa o aplicativo e executa o lint dos modelos Dockerfiles e Helm usados para implantação em um ambiente do 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 a iteração rápida.
Pipeline de CI
O pipeline de CI de aplicativo executa todas as etapas de pipeline de PR, expandindo as verificações de teste e implantação. O pipeline pode ser executado para cada commit para o principal ou pode ser executado em uma cadência regular com um grupo de commits.
Nesta fase, os testes de aplicativo que consomem muito para o pipeline de PR podem ser executados, incluindo:
- Enviando imagens por push ao registro de contêiner
- Criando, fazendo lint e teste de imagem
- Geração de modelo de arquivos YAML brutos
Ao final da compilação de CI, os artefatos são gerados. Esses artefatos podem ser usados pela etapa de CD a ser consumida na preparação para a implantação.
Extensão de cluster do Flux
O Flux é um agente executado em cada cluster como uma extensão de cluster. Esta extensão de cluster Flux é responsável por manter o estado desejado. O agente sonda o repositório GitOps em um intervalo definido pelo usuário, em seguida, reconcilia o estado do cluster com o estado declarado no repositório Git.
Para obter mais informações, consulte Tutorial: Implantar aplicativos usando o GitOps com o Flux v2.
Pipeline de CD
O pipeline de CD é disparado automaticamente por compilações de CI bem-sucedidas. Nesse ambiente de pipeline, os valores específicos do ambiente são substituídos nos modelos publicados anteriormente e uma nova solicitação de pull é gerada no repositório do GitOps com esses valores. Essa solicitação de pull contém as alterações propostas para o estado desejado de um ou mais clusters de Kubernetes. Os administradores de cluster examinam a solicitação de pull e aprovam a mesclagem para o repositório do GitOps. O pipeline aguarda a mesclagem da solicitação de pull, e após ela, o Flux sincroniza e aplica as alterações de estado.
Repositório do GitOps
O repositório do GitOps representa o estado atual desejado de todos os ambientes em clusters. Qualquer alteração nesse repositório é coletada pelo serviço do Flux em cada cluster e implantada. As alterações no estado desejado dos clusters são apresentadas como solicitações de pull, que são revisadas e, por fim, mescladas após a aprovação das alterações. Essas solicitações de pull contêm alterações nos modelos de implantação e nos manifestos de Kubernetes renderizados resultantes. Os manifestos renderizados de nível baixo permitem uma inspeção mais cuidadosa das alterações normalmente não vistas no nível de modelo.
Conector do GitOps
O conector do GitOps cria uma conexão entre o agente do Flux e o pipeline do repositório/CD do GitOps. Enquanto as alterações são aplicadas ao cluster, o Flux notifica o conector do GitOps sobre cada alteração de fase e verificação de integridade realizadas. Esse componente serve como um adaptador. Ele entende como se comunicar com um repositório Git e atualize o status de commit do Git para que o progresso da sincronização fique visível no repositório GitOps. Quando a implantação é concluída (tendo êxito ou falhando), o conector notifica o pipeline de CD para continuar, assim o pipeline pode executar atividades posteriores à implantação, como testes de integração.
Clusters do Kubernetes
Pelo menos um cluster do AKS (Serviço de Kubernetes do Azure) ou do 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 garantia de qualidade através de namespaces diferentes. Um segundo cluster pode fornecer uma separação mais fácil de ambientes e um controle mais refinado.
Fluxo de trabalho de exemplo
Como desenvolvedora de aplicativos, a 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 de Kubernetes.
Alice quer se certificar de que o aplicativo tem a capacidade de executar vários ambientes, mas não sabe as configurações específicas de cada ambiente.
Suponha que Alice queira fazer uma alteração no aplicativo que altere a imagem do Docker usada no modelo de implantação de aplicativo.
Ela altera o modelo de implantação, efetua push para um branch remoto chamado
aliceno Repositório de Aplicativos e abra uma solicitação de pull para análise em relação ao branchmain.Alice solicita que sua equipe revise a alteração.
- O pipeline de PR executa a validação.
- A alteração é mesclada após a execução bem-sucedida do pipeline de RP e a aprovação da equipe.
Em seguida, o pipeline de CI inicia, valida a alteração de Alice e conclui com êxito.
- É seguro implantar a alteração no cluster e os artefatos são salvos na execução do pipeline de CI.
A execução com êxito do pipeline de CI dispara o pipeline de CD.
- O pipeline de CD pega os artefatos armazenados pela execução do pipeline de CI da Alice.
- O pipeline de CD substitui os modelos por valores específicos do ambiente e prepara as alterações em relação ao estado do cluster existente no repositório do GitOps.
- O pipeline de CD cria uma solicitação de pull em relação à ramificação de produção do repositório do GitOps com as alterações desejadas ao estado do cluster.
A equipe da Alice revisa e aprova sua solicitação de pull.
- A alteração é mesclada no branch de destino correspondente ao ambiente.
Em minutos, o Flux observa uma alteração no repositório de GitOps e efetua pull da alteração da Alice.
- Devido à alteração da imagem do Docker, o pod do aplicativo requer uma atualização.
- O flux aplica a alteração para o cluster.
- O Flux relata o status da implantação para o repositório de GitOps por meio do Conector do GitOps.
O pipeline de CD executa testes automatizados para verificar se a nova implantação foi concluída com êxito e funciona conforme o esperado.
Observação
Para obter ambientes destinados à implantação adicionais, o pipeline de CD itera criando uma solicitação de pull para o próximo ambiente e repete as etapas de 4 a 7. O processo pode precisar de aprovação extra para implantações ou ambientes mais arriscados, como uma alteração relacionada à segurança ou um ambiente de produção.
O pipeline é concluído após todos os ambientes receberem implantações bem-sucedidas.