Editar

CI/CD para aplicativos AKS com ações do GitHub e GitFlow

Azure Container Registry
Azure Kubernetes Service (AKS)
Azure Monitor
Azure Pipelines

O GitOps é um modelo operacional para aplicativos nativos da nuvem que armazena código de infraestrutura declarativa e de aplicativos no Git para ser usado como fonte de 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 em seu ambiente, que geralmente é um cluster Kubernetes. Para obter mais informações sobre GitOps para Kubernetes no Azure, visite GitOps para Serviço Kubernetes do Azure ou disciplinas CI/CD e GitOps com Kubernetes habilitados 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 Python e a estrutura 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 ações do GitHub para CI e CD.

Transfira um ficheiro do Visio desta 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 as Ações do GitHub para compilação e implantação. Os dados fluem através do cenário da seguinte maneira:

  1. O código do aplicativo é desenvolvido.
  2. O código do aplicativo está comprometido com um repositório git do GitHub.
  3. O GitHub Actions cria uma imagem de contêiner a partir do código do aplicativo e envia a imagem de contêiner para o Registro de Contêiner do Azure.
  4. Um trabalho de Ações do GitHub implanta ou envia por push o aplicativo, conforme descrito nos arquivos de manifesto, para o cluster do Serviço Kubernetes do Azure (AKS) usando kubectl ou a ação de cluster Implantar no 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 for CI e Argo CD for CD.

Transfira um ficheiro do Visio desta 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 compilação. Para implantação, ele usa o Argo CD como um operador GitOps para puxar/sincronizar o aplicativo. Os dados fluem através do cenário da seguinte maneira:

  1. O código do aplicativo é desenvolvido.
  2. O código do aplicativo está comprometido com um repositório GitHub.
  3. O GitHub Actions cria uma imagem de contêiner a partir do código do aplicativo e envia a imagem de contêiner 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 atual da imagem com base no número da versão da imagem de contêiner no Registro de Contêiner do Azure.
  5. O Argo CD sincroniza com o repositório Git ou extrai dele.
  6. O Argo CD implanta o aplicativo no cluster AKS.

Componentes

  • O GitHub Actions é uma solução de automação que pode ser integrada aos serviços do Azure para integração contínua (CI). Nesse cenário, o GitHub Actions orquestra a criação de novas imagens de contêiner com base em confirmações com o controle do código-fonte, envia 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 Kubernetes do Azure (AKS) é uma plataforma Kubernetes gerenciada que permite implantar e gerenciar aplicativos em contêineres sem experiência em orquestração de contêineres. Enquanto serviço alojado do Kubernetes, o Azure lida com tarefas críticas para si, como a monitorização do estado de funcionamento e a manutenção.
  • O Registro de Contêiner do Azure armazena e gerencia imagens de contêiner usadas pelo cluster AKS. As imagens são armazenadas com segurança e podem ser replicadas para outras regiões pela plataforma Azure para acelerar os tempos de implantação.
  • O GitHub é um sistema de controle de origem 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, as Ações do GitHub são usadas para executar a compilação e o envio por push da imagem do 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 o 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 gerenciamento de cluster.
  • O Azure Monitor ajuda-o a acompanhar o desempenho, a manter a segurança e a 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 CI/DC e um pipeline de teste para qualquer aplicativo.
  • Jenkins é um servidor de automação de código aberto que pode se integrar aos serviços do Azure para CI/CD.
  • O Flux pode ser utilizado como operador GitOps. Ele pode executar as mesmas tarefas que o Argo CD e funciona da mesma maneira 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. As Ações do GitHub são usadas 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. O GitHub Actions é usado para atualizar o arquivo de implantação de manifesto do Kubernetes necessário, também armazenado no repositório Git, enquanto o operador GitOps Argo CD pega os arquivos de manifesto do Kubernetes de lá e implanta o aplicativo no cluster 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 de novas implantações para ambientes de preparação ou produção. Tradicionalmente, as empresas tinham que criar e compilar manualmente aplicativos e atualizações, e manter uma grande base de código monolítica. Com uma abordagem moderna para o desenvolvimento de aplicativos que usa CI e GitOps para CD, você pode criar, testar e implantar serviços rapidamente. Essa abordagem moderna permite que você libere aplicativos e atualizações para seus clientes mais rapidamente e responda às demandas de negócios em constante mudança de maneira mais ágil.

Usando os serviços do Azure e do GitHub, como AKS, Container Registry, GitHub e GitHub Actions, as empresas podem usar as mais recentes técnicas e ferramentas 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.

Potenciais casos de utilização

Outros casos de uso relevantes incluem:

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

Opções de CI/CD

Este documento mostra o uso do 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 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 AKS são push-based e pull-based. A opção push utiliza ações do GitHub para implantação contínua e a opção pull utiliza GitOps para implantação contínua.

Opção 1: Arquitetura baseada em push com ações do GitHub para CI e CD

Nessa abordagem, o código começa com a parte CI do pipeline trabalhando para alterações que estão sendo enviadas por push como implantações para o cluster Kubernetes. As implantações são baseadas em um gatilho. Há 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 Kubernetes. O módulo baseado em push é o modelo mais comum usado atualmente pelas ferramentas CI/CD.

Razões para usar uma abordagem baseada em push:

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

  • Eficiência: uma abordagem padronizada para implantar seus aplicativos nativos e tradicionais na 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 o conjunto mais amplo de 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 reestruturação significativos seriam necessários para se adequar ao GitOps.

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

Essa abordagem gira em torno da aplicação de quaisquer alterações de dentro de um cluster do Kubernetes. O cluster Kubernetes inclui um operador que verifica um repositório git para o estado desejado do cluster, pegando e aplicando quaisquer alterações que precisem ser feitas. Neste modelo, nenhum cliente externo tem credenciais de nível de administrador para o cluster Kubernetes. O modelo pull-model não é novo, mas não tem sido amplamente utilizado pelas ferramentas CI/CD. Recentemente, com a introdução do GitOps, o modelo pull-model 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 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 traz o cluster Kubernetes de volta ao estado desejado automaticamente.

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

  • Controle de versão: Como o GitOps utiliza um repositório git como fonte da verdade, sua implantação contínua tem inerentemente recursos de versionamento, 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 separados, direitos de acesso separados e distribuir implantações em namespaces diferentes.

  • Nativo da nuvem: mais aplicativos estão sendo modernizados ou criados 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 orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Fiabilidade

A confiabilidade garante que seu aplicativo possa atender aos compromissos que você assume com seus clientes. Para obter mais informações, consulte 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 ser implantadas com o pipeline de CI/CD.

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

Nota

Este artigo não aborda diretamente a alta disponibilidade do pipeline de CI/CD. Para obter mais informações, visite Alta disponibilidade para ações do GitHub e CD declarativo do GitOps do 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 que um pod ou nó esteja indisponível.

Para obter orientações gerais sobre como projetar soluções resilientes, consulte Projetando aplicativos confiáveis do Azure.

Segurança

A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Visão geral do pilar de segurança.

Para separação de credenciais e permissões, esse cenário usa uma entidade de serviço dedicada do Microsoft Entra. As credenciais dessa entidade de serviço são armazenadas como um objeto de credencial seguro no GitHub, como Segredos de Ações do GitHub, para que não sejam diretamente expostas e visíveis nos scripts ou no pipeline de compilação.

Para obter orientações gerais sobre como proteger aplicativos em clusters AKS, consulte Conceitos de segurança para aplicativos e clusters no AKS.

Para a 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 Kubernetes. Para maior separação de preocupações, o operador GitOps pode ser executado em um cluster Kubernetes dedicado à instância GitOps separada do cluster Kubernetes de produção que executa o aplicativo de negócios.

Nota

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

Eficiência de desempenho

Eficiência de desempenho é a capacidade da sua carga de trabalho para dimensionar para satisfazer as exigências que os utilizadores lhe colocam de forma eficiente. Para obter mais informações, consulte Visão geral do pilar de eficiência de desempenho.

O AKS permite dimensionar o número de nós de cluster para atender às demandas de seus aplicativos. À medida que seu aplicativo cresce, você pode aumentar o número de nós do Kubernetes que executam seu serviço.

Com o GitHub Actions, o provedor de nuvem dimensiona automaticamente o número de corredores. Se forem usados corredores auto-hospedados, o anfitrião do corredor 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.

Implementar este cenário

Siga as etapas na implementação de referência AKS-baseline-automation para implantar o cenário. O repositório de implementação de referência guiou 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).

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

Outros contribuidores:

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

Próximos passos

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 as Instâncias de Contêiner do Azure também podem ser usados para executar aplicativos baseados em contêiner, sem a necessidade de provisionar nenhum componente 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: