Pular para o conteúdo principal
BlogFerramentas para desenvolvedoresArquitetura baseada em push vs. pull no GitOps

Arquitetura baseada em push vs. pull no GitOps

Arquitetura baseada em Push vs. Pull no GitOps.

Nos estágios iniciais do projeto ou da implementação do GitOps, pode ser assustador pensar nas várias ferramentas e práticas de que você pode precisar. Você quer ter certeza de que está projetando um fluxo de trabalho robusto e escalável para gerenciar implementações de infraestrutura e aplicativos. E não quer trazer nada que complique demais os processos ou dificulte a liberação das alterações de código pela sua equipe.

Uma maneira de restringir seu foco é procurar ferramentas e práticas que apoiem suas práticas de implementação. A principal consideração é se você utiliza uma abordagem baseada em push ou pull. Ambas têm seus prós e contras, e a que você usar terá impacto sobre as ferramentas e os processos que você incluir na sua estratégia de GitOps.

Automatização de fluxos de trabalho e infraestrutura

Primeiro, vamos analisar duas práticas centrais de DevOps: Infraestrutura como código (IaC) e automação com Integração Contínua e Entrega Contínua (CI/CD). 

A IaC é uma técnica para implementar e gerenciar a infraestrutura por meio de código, em vez de uma série de etapas manuais ou processos interativos. Essa abordagem não se limita apenas a primitivos de infraestrutura ou serviços gerenciados em nuvem - ela é aplicável a todos os aspectos gerenciáveis, como arquivos de configuração, instalações de software, políticas de rede e segurança e assim por diante. Comumente chamado de "X as Code", esse tipo de gerenciamento unificado fornece um estado desejado, modelado e documentado para sua implementação.

CI/CD é uma metodologia e um conjunto de práticas comuns que permitem aos desenvolvedores fornecer aplicativos codificados com qualidade e segurança de forma rápida e confiável. Adotar a CI/CD é adotar uma cultura em que as equipes de desenvolvimento podem manter o foco nos negócios e nos requisitos do usuário final implementando a automação nos estágios certos do ciclo de vida do desenvolvimento de software.

No desenvolvimento de software, a integração é o processo de confirmar as alterações no código em um repositório. A integração contínua (CI) é o processo de validação automática das alterações, criando, testando e empacotando o código do aplicativo atualizado de forma confiável e consistente. O acionamento de um fluxo de trabalho de CI em cada evento de envio proporciona um processo de desenvolvimento mais suave e rápido, uma vez que bugs, vulnerabilidades de segurança e conflitos podem ser descobertos antes que as alterações sejam implantadas em um ambiente.

Um fluxo de trabalho de Entrega Contínua (CD) assume o controle após a conclusão bem-sucedida do fluxo de trabalho de CI. Esse é o processo automatizado e consistente de entrega do código atualizado do aplicativo em um ambiente selecionado, que pode ser um fluxo de trabalho que facilita a implantação do aplicativo diretamente em servidores de preparação ou produção, ou o envio de uma nova versão para um registro de contêineres ou uma plataforma de distribuição móvel. 

Esses são os temas centrais da automação dos fluxos de trabalho dos desenvolvedores. Uma abordagem de GitOps se baseia nessas práticas centrais de DevOps e as coloca em operação. Ao aproveitar um repositório git como uma única fonte de verdade para arquivos de definição de IaC e utilizar pipelines de automação, você pode controlar efetivamente o estado desejado da sua infraestrutura. 

É aqui que voltamos às suas práticas de implantação: decidir se a base push ou pull é a mais adequada para seu aplicativo e sua estratégia de GitOps.

Comparação entre arquitetura baseada em push e pull

Baseada em push, ou sem agente, é a abordagem mais tradicional na qual as alterações são enviadas para o ambiente selecionado por um cliente externo de CI/CD, como o Jenkins ou o CircleCI. Isso pode ser preferível para ambientes que não sejam do Kubernetes ou ambientes com uma mistura de tipos de carga de trabalho que tornaria incômoda a execução de agentes e webhooks separados em cada componente.

Prós:

  • Mais simples de implementar em vários tipos de cargas de trabalho em um único ambiente.
  • Padronização da metodologia de implantação entre diferentes ambientes (ou seja, nativo da nuvem e no local).
  • Flexibilidade de ferramentas, pois a maioria das estruturas de CI/CD utiliza um modelo baseado em push. 

Contras:

  • O cliente de CI/CD não tem capacidade de observação para saber se as alterações foram implementadas com êxito ou se ocorreram problemas no lado do servidor como resultado.
  • Pode ser necessário instalar ferramentas adicionais (por exemplo, kubectl, Helm, Docker, Ansible, Terraform, SSH) para que o cliente de CI/CD implemente as alterações.
  • Exige que o cliente de CI/CD tenha acesso externo ao ambiente, o que aumenta o risco de problemas de segurança e conformidade.

A abordagem baseada em pull ou agente funciona na direção oposta, tornando o ambiente parte do pipeline de CD. Um agente ou operador observa o repositório git em busca de alterações e, em seguida, faz o pull e as aplica. Essa tarefa também é executada sempre que o agente detecta um desvio de configuração da fonte única de verdade. Essa abordagem funciona particularmente bem com ambientes nativos do Kubernetes.

Prós:

  • O agente/operador tem capacidade de observação do estado atual do ambiente e do status da implantação.
  • Melhor segurança e conformidade simplificada, pois o ambiente requer apenas permissão para visualizar a fonte.
  • Detecção rápida de desvios de configuração decorrentes de intervenção humana manual ou de outras fontes.

Contras:

  • Mais complexo para implementações que não sejam do Kubernetes.
  • Requer ferramentas projetadas para trabalhar com tipos específicos de ambiente.

Ao começar a planejar sua estratégia de GitOps, considere como diferentes estratégias de implantação darão suporte ao seu aplicativo. As abordagens baseadas em push e pull têm suas vantagens e são adequadas para diferentes cenários. Há muitas ferramentas e práticas a serem consideradas e, com alguma perspectiva, você saberá qual é a solução certa para sua equipe e sua pilha.

Procurando mais informações? Faça o download gratuito de nosso e-book Estratégia GitOps ou obtenha uma consulta gratuita com um especialista em computação em nuvem da Akamai.


Comentários

Deixe uma resposta

Seu endereço de e-mail não será publicado. Os campos obrigatórios estão marcados com *