Editar

CI/CD para aplicativos do AKS com GitHub Actions e GitFlow

Registro de Contêiner do Azure
AKS (Serviço de Kubernetes do Azure)
Azure Monitor
Azure Pipelines

O GitOps é um modelo operacional para aplicativos nativos da nuvem que armazena o código de aplicativos e infraestrutura declarativa no Git para ser usado como a fonte da verdade para entrega contínua automatizada. Com o GitOps, você descreve o estado desejado de todo o seu sistema em um repositório git, e um operador GitOps o implanta no seu ambiente, que geralmente é um cluster do Kubernetes. Para obter mais informações sobre GitOps para Kubernetes no Azure, visite GitOps para o Serviço Kubernetes do Azure ou disciplinas de CI/CD e GitOps com o Kubernetes habilitado para Azure Arc.

O cenário de exemplo neste artigo é aplicável a empresas que desejam modernizar o desenvolvimento de aplicativos de ponta a ponta usando contêineres, integração contínua (CI) para compilação e GitOps para implantação contínua (CD). Nesse cenário, um aplicativo Flask é usado como exemplo. Este aplicativo Web consiste em um front-end escrito usando framework Python e Flask.

Arquitetura

As opções a seguir exploram abordagens de CI/CD baseadas em push e pull.

Opção 1: CI/CD baseado em push

Diagram of the push-based architecture with GitHub Actions.

Arquitetura baseada em push com GitHub Actions para CI e CD.

Baixe um Arquivo Visio dessa arquitetura.

Fluxo de dados

Este cenário abrange um pipeline de DevOps baseado em push para um aplicativo Web de duas camadas, com um componente Web front-end e um back-end que usa Redis. Esse pipeline usa GitHub Actions para compilação e implantação. O fluxo de dados neste cenário ocorre da seguinte forma:

  1. O código do aplicativo é desenvolvido.
  2. O código do aplicativo é confirmado em um repositório git do GitHub.
  3. O GitHub Actions cria uma imagem de contêiner do código do aplicativo e envia a imagem de contêiner por push para o Registro de Contêiner do Azure.
  4. Um trabalho do GitHub Actions implanta ou envia por push o aplicativo, conforme descrito nos arquivos de manifesto, para o cluster do Serviço de Kubernetes do Azure (AKS) usando kubectl ou a ação Implantar no cluster do Kubernetes.

Opção 2: CI/CD baseado em pull (GitOps)

Diagram of the pull-based architecture with GitHub Actions and Argo CD.

Arquitetura baseada em pull com GitHub Actions para CI e Argo CD para CD.

Baixe um Arquivo Visio dessa arquitetura.

Fluxo de dados

Este cenário abrange um pipeline de DevOps baseado em pull para um aplicativo Web de duas camadas, com um componente Web front-end e um back-end que usa Redis. Esse pipeline usa o GitHub Actions para build. Para implantação, ele usa o Argo CD como um operador GitOps para efetuar pull/sincronizar o aplicativo. O fluxo de dados neste cenário ocorre da seguinte forma:

  1. O código do aplicativo é desenvolvido.
  2. O código do aplicativo é confirmado em um repositório GitHub.
  3. O GitHub Actions cria uma imagem de contêiner do código do aplicativo e envia a imagem de contêiner por push para o Registro de Contêiner do Azure.
  4. O GitHub Actions atualiza um arquivo de implantação de manifesto do Kubernetes com a versão da imagem atual baseada no número de versão da imagem de contêiner no Registro de Contêiner do Azure.
  5. O Argo CD sincroniza ou extrai do repositório Git.
  6. O Argo CD implanta o aplicativo no cluster do AKS.

Componentes

  • O GitHub Actions é uma solução de automação que pode se integrar aos serviços do Azure para integração contínua (CI). Neste cenário, o GitHub Actions orquestra a criação de novas imagens de contêiner com base nas confirmações no controle do código-fonte, envia por push essas imagens para o Registro de Contêiner do Azure e atualiza os arquivos de manifesto do Kubernetes no repositório do GitHub.
  • O Serviço de Kubernetes do Azure (AKS) é uma plataforma do Kubernetes gerenciado que permite implantar e gerenciar aplicativos conteinerizado sem conhecimento de orquestração de contêiner. Como um serviço Kubernetes hospedado, o Azure lida com as tarefas críticas para você, como o monitoramento da integridade e a manutenção.
  • O Registro de Contêiner do Azure armazena e gerencia imagens de contêiner que são usadas pelo cluster do AKS. As imagens são armazenadas com segurança e podem ser replicadas em outras regiões pela plataforma do Azure para acelerar os tempos de implantação.
  • O GitHub é um sistema de controle de código-fonte baseado na Web que é executado no Git e é usado por desenvolvedores para armazenar e fazer a versão do código de seu aplicativo. Nesse cenário, o GitHub é usado para armazenar o código-fonte em um repositório Git, e, em seguida, o GitHub Actions é utilizado para executar a compilação e o envio por push da imagem de contêiner para o Registro de Contêiner do Azure na abordagem baseada em push.
  • Argo CD é um operador GitOps de código aberto que se integra com GitHub e AKS. Argo CD suporta implantação contínua (CD). O Flux poderia ter sido usado para essa finalidade, mas o Argo CD mostra como uma equipe de aplicativos pode escolher uma ferramenta separada para suas preocupações específicas com o ciclo de vida do aplicativo, em comparação com o uso da mesma ferramenta que os operadores de cluster usam para o gerenciamento de cluster.
  • O Azure Monitor ajuda-o a rastrear o desempenho, manter a segurança e identificar tendências. As métricas obtidas pelo Azure Monitor podem ser usadas por outros recursos e ferramentas, como o Grafana.

Alternativas

  • O Azure Pipelines ajuda você a implementar um pipeline de CI/CD e de teste para qualquer aplicativo.
  • O Jenkins é um servidor de automação de código aberto que pode se integrar aos serviços do Azure para CI/CD.
  • Flux pode ser utilizado como operador do GitOps. Ele pode executar as mesmas tarefas que o Argo CD e funciona da mesma forma com o AKS.

Detalhes do cenário

Nesse cenário, a compilação e a implantação automatizadas do seu aplicativo usam várias tecnologias. O código é desenvolvido em VS Code e armazenado em um repositório GitHub. GitHub Actions é usado para criar o aplicativo como um contêiner e, em seguida, enviar a imagem do contêiner para um Registro de Contêiner do Azure. É utilizado para atualizar o arquivo de implantação de manifesto do Kubernetes necessário, também armazenado no repositório Git, enquanto o operador Argo CD do GitOps coleta os arquivos de manifesto do Kubernetes e implanta o aplicativo no cluster do AKS.

Outros exemplos incluem o fornecimento de um ambiente de desenvolvimento automatizado, a validação de novas confirmações de código e o envio por push de novas implantações em ambientes de preparo ou produção. Tradicionalmente, as empresas tinham que criar e compilar aplicativos e atualizações e manter uma base de código grande e monolítica. Com uma abordagem moderna para o desenvolvimento de aplicativos que usa CI (integração contínua) e CD (implantação contínua) do GitOps, você pode criar, testar e implantar serviços mais rapidamente. Essa abordagem moderna permite liberar aplicativos e atualizações para seus clientes mais rapidamente e responder às mudanças nas demandas dos negócios de forma mais ágil.

Usando serviços do Azure e do GitHub, como o AKS, o Registro de Contêiner e o GitHub Actions, as empresas podem usar o que há de mais recente em ferramentas e técnicas de desenvolvimento de aplicativos para simplificar o processo de implementação de alta disponibilidade. Além disso, usando tecnologias de código aberto, como Flux ou Argo CD para GitOps, as empresas simplificam a implantação e impõem o estado desejado dos aplicativos.

Possíveis casos de uso

Outros casos de uso relevantes incluem:

  • Modernize as práticas de desenvolvimento de aplicativos adotando uma abordagem de microsserviços baseada em contêiner.
  • Acelere o desenvolvimento de aplicativos e os ciclos de vida de implantação.
  • Automatize implantações de teste ou ambientes de aceitação para validação.
  • Garanta as configurações e o estado desejado do aplicativo.
  • Automatize o gerenciamento do ciclo de vida do cluster.

Opções de CI/CD

Este documento mostra o uso de GitOps para uma abordagem moderna para lidar com a implantação contínua em um pipeline de CI/CD. No entanto, cada organização é diferente. Ao implantar aplicativos em clusters do Kubernetes por meio de pipelines de entrega automatizados, é importante entender as várias maneiras pelas quais isso pode ser feito.

As duas opções de CI/CD mais comuns para implantar um aplicativo em um cluster do AKS são baseadas em push e pull. A opção push utiliza GitHub Actions para implantação contínua, e a opção pull utiliza o GitOps para implantação contínua.

Opção 1: Arquitetura baseada em push com GitHub Actions para CI e CD.

Nessa abordagem, o código começa com a parte de CI do pipeline que vai lidar com as alterações que estão sendo enviadas como implantações para o cluster do Kubernetes. As implantações são baseadas em um gatilho. Existem vários gatilhos que podem iniciar a implantação, por exemplo, confirmações no repositório ou um gatilho de outro pipeline de CI. Com essa abordagem, o sistema de pipeline tem acesso ao cluster do Kubernetes. O módulo baseado em push é o modelo mais comum usado hoje pelas ferramentas de CI/CD.

Razões para usar uma abordagem baseada em push:

  • Flexibilidade: A maioria dos operadores GitOps atualmente só é executada no Kubernetes. Se sua organização quiser implantar aplicativos em outro ambiente que não o Kubernetes, você precisará enviar o aplicativo para esse ambiente por meio de outras ferramentas de CI/CD, como GitHub Actions.

  • Eficiência: uma abordagem padronizada para implantar seus aplicativos nativos e tradicionais da nuvem é mais eficiente. Atualmente, o GitOps é mais adequado para aplicativos nativos da nuvem que são executados no Kubernetes.

  • Simplicidade: o CI/CD baseado em push é bem conhecido entre a maioria dos engenheiros em muitas organizações. Uma abordagem baseada em push pode ser mais simples do que uma combinação de abordagens de CI/CD baseadas em push e pull.

  • Estrutura: A estrutura de repositório atual usada para seu aplicativo pode não ser adequada para GitOps, o que significa que um planejamento e uma reestruturação significativos seriam necessários para se adequar ao GitOps.

Opção 2: Arquitetura baseada em pull com GitHub Actions para CI e operador Argo CD do GitOps para CD

Essa abordagem concentra-se na aplicação de quaisquer alterações a partir de um cluster do Kubernetes. O cluster do Kubernetes inclui um operador que verifica um repositório git em busca do estado desejado do cluster, aplicando quaisquer alterações que precisem ser feitas. Nesse modelo, nenhum cliente externo tem credenciais de nível de administrador para o cluster do Kubernetes. O modelo pull não é novo, mas não tem sido amplamente utilizado pelas ferramentas de CI/CD. Recentemente, com a introdução do GitOps, o modelo pull vem ganhando adoção. Muitas organizações têm utilizado o GitOps para facilitar a implantação contínua em seus pipelines de CD/CD.

Razões para usar uma abordagem baseada em pull:

  • Consistência: Com o GitOps, um operador compara o estado de seus clusters do Kubernetes com o estado desejado de sua configuração e aplicativos em um repositório git. Se houver algum desvio para a configuração ou aplicativos, o operador GitOps trará o cluster do Kubernetes de volta ao estado desejado automaticamente.

  • Segurança: Uma abordagem baseada em pull para CI/CD com GitOps permite que você transfira credenciais de segurança para seu cluster do Kubernetes, o que reduz a superfície de segurança e risco, evitando que as credenciais sejam armazenadas nas suas ferramentas de CI externas. Você também poderá diminuir as conexões de entrada permitidas e limitar o acesso de nível de administrador aos seus clusters do Kubernetes.

  • Controle de versão: Como o GitOps utiliza um repositório git como a fonte da verdade, sua implantação contínua tem recursos de controle de versão, reversão e auditoria.

  • Multilocação: Uma abordagem baseada em pull com GitOps é adequada para equipes distribuídas e/ou multilocação. Com o GitOps, você pode utilizar repositórios git e direitos de acesso separados e distribuir implantações em namespaces diferentes.

  • Nativo da nuvem: mais aplicativos estão sendo modernizados ou construídos para serem nativos da nuvem. Para qualquer organização que tenha a maioria de seus aplicativos em execução no Kubernetes, utilizar um operador GitOps para implantação contínua é mais simples e eficiente do que uma abordagem tradicional baseada em push para CI/CD.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios de orientação que podem ser usados para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.

Confiabilidade

A confiabilidade garante que seu aplicativo possa cumprir os compromissos que você assume com seus clientes. Para obter mais informações, confira Visão geral do pilar de confiabilidade.

Para monitorar o desempenho do aplicativo e relatar problemas, esse cenário utiliza o Azure Monitor. Ele permite monitorar e solucionar problemas de desempenho que podem exigir atualizações de código, que podem todas ser implantadas com o pipeline de CI/CD.

Como parte do cluster do AKS, um balanceador de carga distribui o tráfego do aplicativo para um ou mais contêineres ou pods que executam o aplicativo. Essa abordagem para a execução de aplicativos em contêineres no Kubernetes oferece uma infraestrutura altamente disponível para seus clientes.

Observação

Este artigo não aborda diretamente a alta disponibilidade do pipeline de CI/CD. Para obter mais informações, visite Alta disponibilidade para GitHub Actions e CD declarativa GitOps Argo CD para Kubernetes.

Os componentes de resiliência são incorporados ao Kubernetes. Esses componentes monitoram e reiniciam contêineres, ou pods, se houver um problema. Quando vários nós do Kubernetes são combinados, seu aplicativo pode tolerar a indisponibilidade de um pod ou nó.

Para obter diretrizes gerais sobre como criar soluções resilientes, confira Como projetar aplicativos confiáveis do Azure.

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para saber mais, confira Visão geral do pilar de segurança.

Para separar credenciais e permissões, este cenário usa uma entidade de serviço dedicada do Microsoft Entra. As credenciais para essa entidade de serviço são armazenadas como um objeto de credencial segura no GitHub, como Segredos do GitHub Actions, para não serem diretamente expostas e ficarem visíveis dentro de scripts ou no pipeline de compilação.

Para obter orientação geral sobre como proteger aplicativos em clusters do AKS, consulte Conceitos de segurança para aplicativos e clusters no AKS.

Para separação de preocupações, a orientação é separar a computação que executa o aplicativo de negócios dos agentes de CD, ou operador GitOps, executando o aplicativo de negócios e o operador GitOps em namespaces separados no cluster do Kubernetes. Para maior separação de preocupações, o operador GitOps pode ser executado em um cluster do Kubernetes dedicado à instância GitOps separada do cluster do Kubernetes de produção que executa o aplicativo de negócios.

Observação

Este artigo não aborda diretamente como proteger um pipeline de CI/CD.

Eficiência de desempenho

A eficiência do desempenho é a capacidade de dimensionar sua carga de trabalho para atender às demandas colocadas por usuários de maneira eficiente. Para saber mais, confira Visão geral do pilar de eficiência de desempenho.

O AKS permite que você dimensione o número de nós de cluster para atender às demandas dos aplicativos. À medida que seu aplicativo cresce, você pode escalar verticalmente o número de nós de Kubernetes que executa o serviço.

Com o GitHub Actions, o provedor de nuvem dimensiona automaticamente o número de executores. Se executores auto-hospedados forem usados, o anfitrião do executor será responsável por dimensioná-los conforme necessário.

Para outros tópicos de escalabilidade, consulte a lista de verificação de eficiência de desempenho.

Implantar este cenário

Siga as etapas na implementação de referência Automação de Linha de Base do AKS para implantar o cenário. O repositório de implementação de referência orientou instruções passo a passo para o cenário de CI/CD baseado em push e o cenário de CI/CD baseado em pull (GitOps).

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Principais autores:

Outros colaboradores:

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

Próximas etapas

Este cenário usou o Registro de Contêiner do Azure e o AKS para armazenar e executar um aplicativo baseado em contêiner. Os Aplicativos de Contêiner do Azure ou Instâncias de Contêiner do Azure também podem ser usadas para executar aplicativos baseados em contêiner, sem precisar provisionar componentes de orquestração. Para obter mais informações, consulte Visão geral das Instâncias de Contêiner do Azure e Visão geral dos Aplicativos de Contêiner do Azure.

Documentação do produto:

Módulos do Microsoft Learn: