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 Azure Kubernetes Services (AKS).
Os logotipos Flux, Argo CD, OPA Gatekeeper, Kubernetes e git são marcas comerciais de suas respetivas empresas. O uso destas marcas não implica qualquer endosso.
Arquitetura
Dois operadores de GitOps que você pode usar com o AKS são o Flux e o Argo CD. Ambos são projetos graduados Cloud Native Computing Foundation (CNCF) e são amplamente utilizados. Os cenários a seguir mostram maneiras de usá-los.
Cenário 1: GitOps com Flux e AKS
Transfira um ficheiro do Visio desta arquitetura.
Fluxo de dados para o cenário 1
Flux é uma extensão de cluster nativo para AKS. As extensões de cluster fornecem uma plataforma para instalar e gerenciar soluções em um cluster AKS. Você pode usar o portal do Azure, a CLI do Azure ou scripts de infraestrutura como código (IaC), como scripts Terraform ou Bicep, para habilitar o Flux como uma extensão do AKS. Você também pode usar a Política do Azure para aplicar configurações do Flux v2 em escala em clusters AKS. Para obter mais informações, consulte Implantar aplicativos consistentemente em escala usando as configurações do Flux v2 e a Política do Azure.
O Flux pode implantar manifestos do Kubernetes, gráficos Helm e arquivos Kustomization no AKS. O Flux é um processo baseado em sondagem, para que possa detetar, extrair e reconciliar alterações de configuração sem expor pontos de extremidade de cluster aos seus agentes de compilação.
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 é:
- O desenvolvedor confirma alterações de configuração no repositório GitHub.
- O Flux deteta desvios de configuração no repositório Git e extrai as alterações de configuração.
- O Flux 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 Flux Bucket define uma fonte para produzir um artefato para objetos a partir de soluções de armazenamento como Amazon S3 e buckets do Google Cloud Storage. Você também pode usar uma solução que tenha uma API compatível com o S3. Dois exemplos são Minio e Alibaba Cloud OSS, mas há outros.
- Você também pode configurar o Flux em um contêiner de Armazenamento de Blob do Azure como uma origem para produzir artefatos. Para obter mais informações, consulte Configurações do GitOps Flux v2 com AKS e Kubernetes habilitados para Azure Arc.
Cenário 2: Usar GitOps com Flux, GitHub e AKS para implementar CI/CD
Transfira um ficheiro do Visio desta arquitetura.
Fluxo de dados para o cenário 2
Este cenário é um pipeline de DevOps baseado em pull para um aplicativo Web típico. O pipeline usa ações do GitHub para compilação. Para implantação, ele usa o Flux como o operador GitOps para puxar e sincronizar o aplicativo. Os dados fluem através do cenário da seguinte maneira:
- O código do aplicativo é desenvolvido usando um IDE, como o Visual Studio Code.
- O código do aplicativo está comprometido com um repositório GitHub.
- 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.
- O GitHub Actions atualiza um arquivo de implantação de manifesto do Kubernetes com a versão de imagem atual baseada no número da versão da imagem de contêiner no Registro de Contêiner do Azure.
- O operador Flux deteta desvios de configuração no repositório Git e extrai as alterações de configuração.
- O Flux usa arquivos de manifesto para implantar o aplicativo no cluster AKS.
Cenário 3: GitOps com Argo CD, repositório GitHub e AKS
Transfira um ficheiro do Visio desta arquitetura.
Fluxo de dados para o cenário 3
Nesse cenário, o administrador do Kubernetes pode alterar objetos de configuração do Kubernetes, como segredos e ConfigMaps, e confirmar as alterações diretamente no repositório GitHub.
O fluxo de dados para este cenário é:
- O administrador do Kubernetes faz alterações de configuração em arquivos YAML e confirma as alterações no repositório GitHub.
- O Argo CD extrai as alterações do repositório Git.
- O Argo CD reconcilia as alterações de configuração no cluster AKS.
O Argo CD não precisa sincronizar automaticamente o estado de destino desejado com o cluster AKS. Ele é implementado como um controlador Kubernetes que monitora continuamente os aplicativos em execução. Ele compara o estado atual e ativo do cluster AKS com o estado de destino desejado especificado no repositório Git. O Argo CD relata e visualiza as diferenças, enquanto fornece recursos para sincronizar automática ou manualmente o estado ao vivo de volta ao estado de destino desejado.
Argo CD fornece uma interface de 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. Tanto a interface do usuário quanto 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ê crie 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 da configuração.
Cenário 4: Usar GitOps com Argo CD, GitHub Actions e AKS para implementar CI/CD
Transfira um ficheiro do Visio desta arquitetura.
Fluxo de dados para o cenário 4
Este cenário é um pipeline de DevOps baseado em pull para um aplicativo Web típico. O pipeline usa ações do GitHub para compilação. Para implantação, ele usa Argo CD como o operador GitOps para puxar e sincronizar o aplicativo. Os dados fluem através do cenário da seguinte maneira:
- O código do aplicativo é desenvolvido usando um IDE, como o Visual Studio Code.
- O código do aplicativo está comprometido com um repositório GitHub.
- 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.
- O GitHub Actions atualiza um arquivo de implantação de manifesto do Kubernetes com a versão de imagem atual baseada no número da versão da imagem de contêiner no Registro de Contêiner do Azure.
- O Argo CD extrai do repositório Git.
- O Argo CD implanta o aplicativo no cluster 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 da configuração.
Detalhes do cenário
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 integração contínua/implantação contínua (CI/CD) à automação da infraestrutura.
- Você pode aplicá-lo a qualquer sistema de software.
O GitOps é frequentemente 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 AKS.
De acordo com os princípios do GitOps, o estado desejado de um sistema gerenciado pelo GitOps deve ser:
- Declarativo: Um sistema que o GitOps gerencia deve ter seu estado desejado expresso declarativamente. A declaração é normalmente armazenada em um repositório Git.
- Versionado e imutável: O estado desejado é armazenado de uma forma que impõe a imutabilidade e o controle de versão, e mantém um histórico de versões completo.
- Puxado automaticamente: os agentes de software extraem automaticamente as declarações de estado desejadas da origem.
- 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 de componentes de infraestrutura, como máquinas virtuais (VMs), redes e firewalls. Este código é controlado por 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 torna possível revisar e auditar alterações de código que afetam o cluster. Reforça a segurança ao apoiar o princípio do menor privilégio.
Os agentes GitOps reconciliam continuamente o estado do sistema com o estado desejado armazenado no repositório de código. Alguns agentes GitOps podem reverter operações executadas fora do cluster, como a criação manual de objetos Kubernetes. Os controladores de admissão, por exemplo, impõem políticas em objetos durante operações de criação, atualização e exclusão. Você pode usá-los 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 feedback sobre as alterações de políticas 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 sucessos de implantação e falhas de reconciliação.
GitOps como a única fonte da verdade
O GitOps fornece consistência e padronização do estado do cluster e pode ajudar a aumentar a segurança. Você também pode usar o GitOps para garantir um 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 desastres (DR) ou em um farm de clusters.
Se quiser impor que apenas o GitOps pode alterar o estado do cluster, você pode restringir o acesso direto ao cluster. Há várias maneiras de fazer isso, incluindo 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 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:
- ID da carga de trabalho do Microsoft Entra.
- Azure Key Vault Provider for Secrets Store CSI Driver.
- Ferramentas de parceiros, tais como:
- Ferramentas de código aberto, tais como:
- KEDA.
- DNS externo.
- Gestor de certificados.
Você pode habilitar o Flux como uma extensão que é aplicada quando você cria um cluster AKS. O Flux pode então inicializar a configuração de linha de base no cluster. A arquitetura de linha de base para um cluster AKS sugere o uso de 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. Jenkins X é outra ferramenta GitOps que fornece instruções para integrar ao Azure. Você pode usar ferramentas de entrega progressiva, como o Flagger , para a mudança gradual de cargas de trabalho de produção que são implantadas por meio do GitOps.
Potenciais casos de utilização
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 alteração.
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 aumenta a produtividade do desenvolvedor.
Considerações
Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que você pode usar 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.
Um dos principais pilares da fiabilidade é a resiliência. O objetivo da resiliência é fazer com que a aplicação volte para um estado totalmente funcional após a ocorrência de 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 do 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 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.
Com a abordagem GitOps, desenvolvedores ou administradores individuais não acessam diretamente os clusters do Kubernetes para aplicar alterações ou atualizações. Em vez disso, os usuários enviam as 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 prática recomendada de segurança de menor privilégio, não dando às equipes de DevOps permissões de gravação para a API do Kubernetes. Em cenários de diagnóstico ou solução de problemas, você pode conceder permissões de cluster por um tempo limitado 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 AKS:
- Proteção de ramificação: proteja as ramificações que representam o estado dos clusters do Kubernetes contra alterações enviadas diretamente para elas. Use RPs para fazer alterações e peça a pelo menos uma outra pessoa que revise cada RP. Além disso, use RPs para fazer verificações automáticas.
- Revisão de RP: Exigir que os RPs tenham pelo menos um revisor, para fazer cumprir o princípio dos quatro olhos. Você também pode usar o recurso de proprietários de código do GitHub para definir indivíduos ou equipes responsáveis pela revisão de arquivos específicos em um repositório.
- Histórico imutável: permita apenas novas confirmações em cima das alterações existentes. O histórico imutável é especialmente importante para fins de auditoria.
- Outras medidas de segurança: exija 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 custos
A otimização de custos consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Visão geral do pilar de otimização de custos.
- No nível gratuito, o AKS oferece gerenciamento gratuito de clusters. Os custos são limitados aos recursos de computação, armazenamento e rede que o AKS usa 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 Team. Para obter mais informações, consulte a página de preços do GitHub.
- O Azure DevOps oferece uma camada gratuita que você pode usar para alguns cenários.
- Utilize a calculadora de preços do Azure para prever os custos.
Excelência operacional
A excelência operacional abrange os processos operacionais que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, consulte Visão geral do pilar de excelência operacional.
O GitOps pode aumentar a produtividade do DevOps. Um dos recursos mais úteis é a capacidade de reverter rapidamente as alterações que estão se comportando inesperadamente, apenas executando operações Git. O gráfico de confirmação ainda contém todos os compromissos, por isso pode ajudar na análise post-mortem.
As equipes de GitOps geralmente gerenciam vários ambientes para o mesmo aplicativo. É típico ter vários estágios de um aplicativo que são implantados em diferentes clusters ou namespaces do Kubernetes. O repositório Git, que é a única fonte de verdade, mostra quais versões de aplicativos estão atualmente implantadas em um cluster.
Implantar um cenário
A lista a seguir fornece referências para informações sobre a implantação dos cinco cenários:
- Cenário 1: Para obter orientação 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 do cluster AKS, consulte a implementação de referência para a linha de base do AKS.
- Cenário 2: Para obter orientação sobre como usar o GitOps com o Flux v2 no AKS para implantar aplicativos e implementar CI/CD, consulte: Tutorial: Implementar CI/CD com GitOps (Flux v2).
- Cenários 3 e 4: Para obter orientação passo a passo sobre como implantar uma carga de trabalho de exemplo com Argo CD e AKS, consulte o cenário de CI/CD baseado em pull no AKS Baseline Automation.
Contribuidores
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.
Autor principal:
- Francis Simy Nazareth - Brasil | Arquiteto Principal de Soluções Cloud
Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.
Próximos passos
- Documentação do Argo CD
- Documentação do Flux CD
- GitOps com Jenkins X
- O que é o controlo de acesso baseado em funções do Azure (Azure RBAC)?
Recursos relacionados
- Arquitetura de linha de base para um cluster do Serviço Kubernetes do Azure (AKS)
- Linha de base AKS para clusters multirregionais
- DevSecOps no Serviço Kubernetes do Azure (AKS)
- DevSecOps para infraestrutura como código (IaC)
- Infraestrutura corporativa como código usando Bicep e Azure Container Registry
- Automatize a reconfiguração da infraestrutura usando o Azure