Fluxo de trabalho CI/CD usando 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 mais facilmente, rastreando o estado desejado dos ambientes Kubernetes declarativamente com o Git. Usando ferramentas comuns do Git 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ção de aplicativos usando o Azure Arc, Azure Repos e Azure Pipelines. Ele também fornece um exemplo de uma única alteração de aplicativo para ambientes Kubernetes controlados por GitOps.

Arquitetura

Este diagrama mostra o fluxo de trabalho de CI/CD para um aplicativo implantado em um ou mais ambientes Kubernetes.

Repositório de código de 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 vivem neste repositório de forma genérica, como Helm ou Kustomize. Os valores específicos do ambiente não são armazenados no repositório.

As alterações nesse repositório invocam um pipeline de RP ou CI que inicia o processo de implantação.

Registo de contentor

O registro de contêiner contém todas as imagens de primeira e de terceiros usadas nos ambientes Kubernetes. As imagens de aplicativos primários são marcadas com tags legíveis por humanos e o Git commit é usado para criar a imagem. Imagens de terceiros podem ser armazenadas em cache para ajudar com 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 Como consumir e manter conteúdo público com as Tarefas do Registro de Contêiner do Azure.

Gasoduto de relações públicas

As solicitações pull de desenvolvedores feitas para o repositório de aplicativos são limitadas 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, expandindo as verificações de teste e implantação. O pipeline pode ser executado para cada commit to main, ou pode ser executado em uma cadência regular com um grupo de commits.

Nesta etapa, testes de aplicativo que são muito consumidos para o pipeline de RP podem ser executados, incluindo:

• Enviando imagens para o registro de contêiner
• Construção, revestimento e teste de imagens
• Geração de modelos de arquivos YAML brutos

No final da construção da CI, os artefatos são gerados. Esses artefatos podem ser usados pela etapa do CD para consumir na preparação para a implantação.

Extensão do cluster de fluxo

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 e, 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 GitOps com o Flux v2.

Pipeline de CD

O pipeline de CD é acionado automaticamente por compilações de CI bem-sucedidas. Nesse ambiente de pipeline, valores específicos do ambiente são substituídos nos modelos publicados anteriormente e uma nova solicitação pull é gerada no repositório GitOps com esses valores. Essa solicitação pull contém as alterações propostas para o estado desejado de um ou mais clusters do Kubernetes. Os administradores de cluster analisam a solicitação pull e aprovam a mesclagem no repositório GitOps. O pipeline aguarda a mesclagem da solicitação pull, após o que o Flux sincroniza e aplica as alterações 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. As alterações no estado desejado dos clusters são apresentadas como solicitações pull, que são então revisadas e, finalmente, mescladas após a aprovação das alterações. Essas solicitações pull 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.

Conector GitOps

O GitOps Connector cria uma conexão entre o agente Flux e o pipeline GitOps Repository/CD. Enquanto as alterações são aplicadas ao cluster, o Flux notifica o conector GitOps de cada alteração de fase e verificação de integridade realizada. Este componente serve como um adaptador. Ele entende como se comunicar com um repositório Git e atualiza o status de confirmação do Git para que o progresso da sincronização seja visível no repositório GitOps. Quando a implantação for concluída (seja bem-sucedida ou falha), o conector notificará o pipeline de CD para continuar para que o pipeline possa executar atividades pós-implantação, como testes de integração.

Clusters do Kubernetes

Pelo menos um cluster Kubernetes habilitado para Azure Arc ou Azure Kubernetes Service (AKS) 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.

Alice quer ter certeza de que o aplicativo tem a capacidade de ser executado em vários ambientes, mas 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 chamada alice Application Repo e abre uma solicitação pull para revisão na main ramificaçã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 de RP e aprovação da equipe, a alteração é mesclada.

3. O pipeline de CI então inicia e 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 execução bem-sucedida do pipeline de CI 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 uma solicitação pull na ramificação de produção do GitOps Repo com as alterações desejadas no estado do cluster.

5. A equipe de Alice analisa e aprova seu pedido de retirada.

   • 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.
   • O Flux reporta o status da implantação de volta ao repositório GitOps por meio do GitOps Connector.

7. O pipeline de CD executa testes automatizados para verificar se a nova implantação foi concluída com êxito e funciona conforme o esperado.

   Nota

   Para ambientes adicionais destinados à implantação, o pipeline de CD itera criando uma solicitação pull 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. Quando todos os ambientes tiverem recebido implantações bem-sucedidas, o pipeline será concluído.

Próximos passos

• Percorra nosso tutorial para implementar CI/CD com GitOps.
• Saiba mais sobre como criar conexões entre seu cluster e um repositório Git com configurações do Flux.