Editar

Compartilhar via

GitOps para Serviço de Kubernetes do Azure

AKS (Serviço de Kubernetes do Azure)
GitHub

O GitOps é um conjunto de princípios para operar e gerenciar um sistema de software. Este artigo descreve técnicas para usar os princípios do GitOps para operar e gerenciar um cluster do AKS (Serviços de Kubernetes do Azure).

O Flux, Argo CD, OPA Gatekeeper, Kubernetese logotipos do git são marcas comerciais de suas respectivas empresas. Nenhum endosso está implícito pelo uso dessas marcas.

Arquitetura

Dois operadores GitOps que você pode usar com o AKS são Flux e Argo CD. Ambos são projetos de CNCF (Cloud Native Computing Foundation). Os cenários a seguir mostram maneiras de usá-los.

Cenário 1: GitOps com Flux e AKS

Diagrama de GitOps com Flux v2, GitHub e AKS.

Baixe um Arquivo Visio dessa arquitetura.

Fluxo de dados para o cenário 1

O Flux é uma extensão de cluster nativa para o AKS. As extensões de cluster fornecem uma plataforma para instalar e gerenciar soluções em um cluster do AKS. Você pode usar o portal do Azure, a CLI do Azure ou scripts iac (infraestrutura como código), como scripts Terraform ou Bicep, para habilitar o Flux como uma extensão para o AKS. Você também pode usar o Azure Policy para aplicar as configurações do Flux v2 em escala em clusters do AKS. Para obter mais informações, consulte Implantar aplicativos consistentemente em escala usando configurações do Flux v2 e Azure Policy.

O Flux pode implantar manifestos do Kubernetes, gráficos do Helm e arquivos Kustomization no AKS. O Flux é um processo baseado em pesquisa, portanto, ele pode detectar, efetuar pull e reconciliar alterações de configuração sem expor pontos de extremidade de cluster aos agentes de build.

Nesse cenário, os administradores do Kubernetes podem alterar objetos de configuração do Kubernetes, como segredos e ConfigMaps, e confirmar as alterações diretamente em um repositório GitHub.

O fluxo de dados para este cenário é:

  1. O desenvolvedor confirma alterações de configuração no repositório GitHub.
  2. O Flux detecta o descompasso de configuração no repositório Git e efetua pull das alterações de configuração.
  3. Reconcilia o estado no cluster do Kubernetes.

Alternativas para o cenário 1

  • Você pode usar o Flux com outros repositórios Git, como Azure DevOps, GitLab e BitBucket.
  • Em vez de repositórios Git, a API do Bucket do Flux define uma origem para produzir um artefato para objetos de soluções de armazenamento como buckets do Amazon S3 e do Google Cloud Storage. Você também pode usar uma solução que tenha uma API compatível com S3. Dois exemplos são Minio e Alibaba Cloud OSS, mas há outros.
  • Você também pode configurar o Flux em um contêiner do Armazenamento de Blobs do Azure como uma fonte para produzir artefatos. Para obter mais informações, consulte Configurações do GitOps Flux v2 com o AKS e o Kubernetes habilitado para Azure Arc.

Cenário 2: usar o GitOps com Flux, GitHub e AKS para implementar CI/CD

Diagrama de implementação de CI/CD usando GitOps com Flux, GitHub e AKS.

Baixe um Arquivo Visio dessa arquitetura.

Fluxo de dados para o cenário 2

Esse cenário é um pipeline de DevOps baseado em pull para um aplicativo Web típico. O pipeline usa o GitHub Actions para build. Para implantação, ele usa o Flux como o operador GitOps para efetuar pull e sincronizar o aplicativo. O fluxo de dados neste cenário ocorre da seguinte forma:

  1. O código do aplicativo é desenvolvido usando um IDE, como o Visual Studio Code.
  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 operador Flux detecta o descompasso de configuração no repositório Git e efetua pull das alterações de configuração.
  6. O Flux usa arquivos de manifesto para implantar o aplicativo no cluster do AKS.

Cenário 3: GitOps com CD do Argo, repositório GitHub e AKS

Diagrama de GitOps com Argo CD, GitHub e AKS.

Baixe um Arquivo Visio dessa arquitetura.

Fluxo de dados para o cenário 3

Nesse cenário, os administradores do Kubernetes podem alterar objetos de configuração do Kubernetes, como segredos e ConfigMaps, e confirmar as alterações diretamente para o repositório GitHub.

O fluxo de dados para este cenário é:

  1. O administrador do Kubernetes faz alterações de configuração em arquivos YAML e confirma as alterações no repositório GitHub.
  2. O Argo CD extrai as alterações do repositório Git.
  3. O Argo CD reconcilia as alterações de configuração com o cluster do AKS.

O Argo CD não precisa sincronizar automaticamente o estado de destino desejado com o cluster do AKS. Ele é implementado como um controlador do Kubernetes que monitora continuamente a execução de aplicativos. Ele compara o estado atual e dinâmico do cluster do AKS com o estado de destino desejado especificado no repositório Git. O Argo CD relata e visualiza as diferenças, ao mesmo tempo em que fornece instalações para sincronizar automaticamente ou manualmente o estado dinâmico de volta ao estado de destino desejado.

O Argo CD fornece uma interface do usuário baseada em navegador. Você pode usá-lo para adicionar configurações de aplicativo, observar o estado de sincronização em relação ao cluster e iniciar a sincronização com o cluster. Você também pode usar a linha de comando do Argo CD para fazer essas coisas. A interface do usuário e a interface de linha de comando fornecem recursos para exibir o histórico de alterações de configuração e reverter para uma versão anterior.

Por padrão, a interface do usuário do Argo CD e o servidor de API não são expostos. Para acessá-los, recomendamos que você criar um controlador de entrada que tenha um endereço IP interno. Ou você pode usar um balanceador de carga interno para expô-los.

Alternativas para o cenário 3

Qualquer repositório compatível com o Git, incluindo o Azure DevOps, pode servir como o repositório de origem de configuração.

Cenário 4: usar o GitOps com Flux, GitHub Actions e AKS para implementar CI/CD

Diagrama de implementação de CI/CD usando GitOps com Argo CD, GitHub e AKS.

Baixe um Arquivo Visio dessa arquitetura.

Fluxo de dados para o cenário 4

Esse cenário é um pipeline de DevOps baseado em pull para um aplicativo Web típico. O pipeline usa o GitHub Actions para build. Para implantação, ele usa o Argo CD como o operador GitOps para efetuar pull e sincronizar o aplicativo. O fluxo de dados neste cenário ocorre da seguinte forma:

  1. O código do aplicativo é desenvolvido usando um IDE, como o Visual Studio Code.
  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 extrai do repositório Git.
  6. O Argo CD implanta o aplicativo no cluster do AKS.

Alternativas para o cenário 4

Qualquer repositório compatível com o Git, incluindo o Azure DevOps, pode servir como o repositório de origem de configuração.

Detalhes do cenário

O GitOps é um conjunto de princípios para operar e gerenciar um sistema de software.

  • Ele usa o controle do código-fonte como a única fonte de verdade para o sistema.
  • Ele aplica práticas de desenvolvimento como controle de versão, colaboração, conformidade e CI/CD (integração contínua/implantação contínua) à automação de infraestrutura.
  • Você pode aplicá-lo a qualquer sistema de software.

O GitOps geralmente é usado para gerenciamento de cluster do Kubernetes e entrega de aplicativos. Este artigo descreve algumas opções comuns para usar o GitOps junto com um cluster do AKS.

De acordo com princípios do GitOps, o estado desejado de um sistema gerenciado pelo GitOps deve ser:

  1. Declarativo: um sistema gerenciado pelo GitOps deve ter seu estado desejado expresso declarativamente. Normalmente, a declaração é armazenada em um repositório Git.
  2. Versão e imutável: o estado desejado é armazenado de uma maneira que impõe imutabilidade e controle de versão e mantém um histórico de versão completo.
  3. Pulled automaticamente: agentes de software retiram automaticamente as declarações de estado desejadas da origem.
  4. Reconciliado continuamente: os agentes de software observam continuamente o estado real do sistema e tentam aplicar o estado desejado.

No GitOps, a infraestrutura como código (IaC) usa código para declarar o estado desejado dos componentes de infraestrutura, como VMs (máquinas virtuais), redes e firewalls. Esse código tem controle de versão e é auditável.

O Kubernetes descreve tudo, desde o estado do cluster até implantações de aplicativos declarativamente com manifestos. O GitOps para Kubernetes coloca o estado desejado da infraestrutura de cluster sob controle de versão. Um componente no cluster, normalmente chamado de operador, sincroniza continuamente o estado declarativo. Essa abordagem possibilita examinar e auditar alterações de código que afetam o cluster. Ele aprimora a segurança apoiando o princípio de privilégios mínimos.

Os agentes do GitOps reconciliam continuamente o estado do sistema com o estado desejado armazenado em seu repositório de código. Alguns agentes do GitOps podem reverter operações executadas fora do cluster, como a criação manual de objetos kubernetes. Controladores de admissão, por exemplo, impor políticas em objetos durante operações de criação, atualização e exclusão. Você pode usá-las para garantir que as implantações sejam alteradas somente se o código de implantação no repositório de origem for alterado.

Você pode combinar ferramentas de gerenciamento e imposição de políticas com o GitOps para impor políticas e fornecer comentários sobre as alterações de política propostas. Você pode configurar notificações para várias equipes para fornecer a elas o status atualizado do GitOps. Por exemplo, você pode enviar notificações de êxitos de implantação e falhas de reconciliação.

GitOps como a única fonte de verdade

O GitOps fornece consistência e padronização do estado do cluster e pode ajudar a aprimorar a segurança. Você também pode usar o GitOps para garantir o estado consistente em vários clusters. Por exemplo, o GitOps pode aplicar a mesma configuração em clusters primários e de recuperação de desastre (DR) ou em um farm de clusters.

Se você quiser impor que somente o GitOps possa alterar o estado do cluster, você poderá restringir o acesso direto ao cluster. Há várias maneiras de fazer isso, incluindo o RBAC (controle de acesso baseado em função) do Azure, controladores de admissão e outras ferramentas.

Usar o GitOps para inicializar a configuração inicial

É possível ter a necessidade de implantar clusters do AKS como parte da configuração de linha de base. Um exemplo é que você precisa implantar um conjunto de serviços compartilhados ou uma configuração antes de implantar cargas de trabalho. Esses serviços compartilhados podem configurar complementos do AKS, como:

Você pode habilitar o Flux como uma extensão aplicada ao criar um cluster do AKS. O Flux pode inicializar a configuração de linha de base para o cluster. A arquitetura de linha de base para um cluster do AKS sugere o uso do GitOps para inicialização. Se você usar a extensão Flux, poderá inicializar clusters logo após a implantação.

Outras ferramentas e complementos do GitOps

Você pode estender os cenários descritos para outras ferramentas do GitOps. O Jenkins X é outra ferramenta do GitOps que fornece instruções para integrar ao Azure. Você pode usar ferramentas de entrega progressivas, como do Flagger para mudança gradual de cargas de trabalho de produção implantadas por meio do GitOps.

Possíveis casos de uso

Essa solução beneficia qualquer organização que queira as vantagens de implantar aplicativos e infraestrutura como código, com uma trilha de auditoria de cada mudança.

O GitOps protege o desenvolvedor das complexidades do gerenciamento de um ambiente de contêiner. Os desenvolvedores podem continuar a trabalhar com ferramentas familiares, como o Git, para gerenciar atualizações e novos recursos. Dessa forma, o GitOps aprimora a produtividade do desenvolvedor.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework​, um conjunto de princípios orientadores que você pode usar 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 os seus clientes. Para obter mais informações, confira Visão geral do pilar de confiabilidade.

Um dos principais pilares de confiabilidade é a resiliência. A meta da resiliência é retornar o aplicativo a um estado totalmente funcional após uma falha. Se um cluster ficar indisponível, o GitOps poderá criar um novo rapidamente. Ele usa o repositório Git como a única fonte de verdade para a configuração do Kubernetes e a lógica do aplicativo. Ele pode criar e aplicar a configuração de cluster e a implantação do aplicativo como uma unidade de escala e pode estabelecer o padrão de carimbo de implantação.

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.

Com a abordagem do GitOps, desenvolvedores ou administradores individuais não acessam diretamente os clusters do Kubernetes para aplicar mudanças ou atualizações. Em vez disso, os usuários enviam alterações por push para um repositório Git e o operador GitOps (Flux ou Argo CD) lê as alterações e as aplica ao cluster. Essa abordagem segue a melhor prática de segurança de privilégios mínimos, sem conceder permissões de gravação para a API do Kubernetes às equipes de DevOps. Em cenários de diagnóstico ou solução de problemas, você pode conceder permissões de cluster por um tempo limitado e caso a caso.

Além da tarefa de configurar permissões de repositório, considere implementar as seguintes medidas de segurança em repositórios Git que sincronizam com clusters do AKS:

  • Proteção de ramificação: proteja as ramificações que representam o estado dos clusters do Kubernetes contra mudanças feitas diretamente neles. Use PRs para fazer alterações e faça com que pelo menos uma outra pessoa examine cada PR. Use também PRs para fazer verificações automáticas.
  • Revisão de PR: exige que PRs tenham pelo menos um revisor para impor o princípio de quatro olhos. Você também pode usar o recurso proprietários de código do GitHub para definir indivíduos ou equipes responsáveis por revisar arquivos específicos em um repositório.
  • Histórico imutável: permite somente novas confirmações sobre as mudanças existentes. O histórico imutável é especialmente importante para fins de auditoria.
  • Outras medidas de segurança: exigir que os usuários do GitHub ativem a autenticação de dois fatores. Além disso, permita apenas confirmações assinadas para evitar alterações.

Otimização de custo

A otimização de custos é a análise de maneiras de reduzir as despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, confira Visão geral do pilar de otimização de custo.

  • Na camada gratuita, o AKS oferece gerenciamento gratuito de cluster. Os custos são limitados aos recursos de computação, armazenamento e rede usados pelo AKS para hospedar nós.
  • O GitHub oferece um serviço gratuito, mas para usar recursos avançados relacionados à segurança, como proprietários de código ou revisores necessários, você precisa do plano Equipe. Para obter mais informações, confira a página de preços do GitHub.
  • O Azure DevOps oferece uma camada gratuita que você pode usar para alguns cenários.
  • Use a Calculadora de Preços do Azure para estimar os custos.

Excelência operacional

A excelência operacional abrange os processos de operações que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, confira Visão geral do pilar de excelência operacional.

O GitOps pode aumentar produtividade do DevOps. Um dos recursos mais úteis é a capacidade de reverter rapidamente as mudanças que se comportam inesperadamente, apenas executando operações Git. O grafo de confirmação contém ainda todas as confirmações, portanto, pode ajudar com a análise pós-mortem.

As equipes do GitOps geralmente gerenciam vários ambientes para o mesmo aplicativo. É comum ter vários estágios de um aplicativo implantado em diferentes clusters ou namespaces do Kubernetes. O repositório Git, que é a única fonte de verdade, mostra as versões de aplicativos implantadas no momento em um cluster.

Selecionar um cenário

A lista a seguir fornece referências para obter informações sobre como implantar os cinco cenários:

  • Cenário 1: Para obter diretrizes sobre como usar o GitOps com o Flux v2 para implantar aplicativos no AKS, consulte Tutorial: Implantar aplicativos usando o GitOps com o Flux v2. Para obter um exemplo de como usar a extensão Flux para inicializar a implantação de cluster do AKS, consulte a implementação de referência para ode linha de base do AKS.
  • Cenário 2: Para obter diretrizes sobre como usar o GitOps com o Flux v2 no AKS para implantar aplicativos e implementar CI/CD, consulte: Tutorial: Implementar CI/CD com o GitOps (Flux v2).
  • Cenários 3 e 4: Para obter diretrizes passo a passo sobre como implantar uma carga de trabalho de exemplo com o Argo CD e o AKS, consulte o cenário de CI/CD baseado em pull em Automação de Linha de Base do AKS.

Colaboradores

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

Autor principal:

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

Próximas etapas