Nas fases iniciais da conceção ou implementação do GitOps, pode ser assustador pensar nas várias ferramentas e práticas de que poderá necessitar. Quer ter a certeza de que está a conceber um fluxo de trabalho robusto e escalável para gerir infra-estruturas e implementações de aplicações. E não quer introduzir nada que complique demasiado os processos ou dificulte à sua equipa o lançamento de alterações ao código.
Uma forma de restringir o seu foco é procurar ferramentas e práticas que apoiem as 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 nas ferramentas e processos que você incluir na sua estratégia GitOps.
Automatização de fluxos de trabalho e infra-estruturas
Primeiro, vamos rever 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 de implantação e gestão de infra-estruturas através de código, em vez de uma série de passos manuais ou de um processo interativo. Esta abordagem não se limita apenas às primitivas da infraestrutura ou aos serviços geridos em nuvem - é aplicável a todos os aspectos geríveis, como ficheiros de configuração, instalações de software, políticas de rede e de segurança, etc. Comumente chamado de "X as Code", esse tipo de gerenciamento unificado fornece um estado desejado modelado e documentado para sua implantação.
A CI/CD é uma metodologia e um conjunto de práticas comuns que permitem aos programadores fornecer rapidamente e de forma fiável aplicações de qualidade e codificadas de forma segura. Adotar a CI/CD é adotar uma cultura em que as equipas de desenvolvimento podem manter-se concentradas nos requisitos da empresa e do utilizador final, implementando a automatização nas fases certas do ciclo de vida do desenvolvimento de software.
No desenvolvimento de software, a integração é o processo de submeter as alterações ao código num repositório. A Integração Contínua (IC) é o processo de validação automática das alterações, através da criação, teste e empacotamento do código da aplicação atualizado de uma forma fiável e consistente. O acionamento de um fluxo de trabalho de IC em cada evento de envio proporciona um processo de desenvolvimento mais suave e rápido, uma vez que os erros, as vulnerabilidades de segurança e os conflitos podem ser descobertos antes de as alterações serem implementadas num ambiente.
Um fluxo de trabalho de Entrega Contínua (CD) assume o controlo após a conclusão bem sucedida do fluxo de trabalho de CI. Pode ser um fluxo de trabalho que facilita a implantação da aplicação diretamente em servidores de teste ou de produção, ou o envio de uma nova versão para um registo de contentores ou uma plataforma de distribuição móvel.
Estes são temas centrais em torno da automatização dos fluxos de trabalho dos programadores. Uma abordagem GitOps baseia-se nessas práticas centrais de DevOps e as coloca em operação. Aproveitando um repositório git como uma única fonte de verdade para arquivos de definição de IaC, e utilizando pipelines de automação, você pode efetivamente controlar o estado desejado de sua infraestrutura.
É aqui que voltamos às suas práticas de implantação: decidir se push ou pull-based é o melhor ajuste para sua aplicação e estratégia GitOps.
Comparação da arquitetura baseada em Push vs. Pull
Baseado em push, ou sem agente, é a abordagem mais tradicional na qual as alterações são enviadas para o ambiente selecionado por um cliente CI/CD externo, como Jenkins ou 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 tornariam 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 num único ambiente.
- Normalização da metodologia de implementação entre diferentes ambientes (ou seja, nativos da nuvem e no local).
- Flexibilidade de ferramentas, uma vez que a maioria das estruturas de CI/CD utiliza um modelo baseado em push.
Contras:
- O cliente CI/CD não tem capacidade de observação para saber se as alterações foram implementadas com êxito ou se ocorreram problemas do lado do servidor como resultado.
- Poderá ser necessário instalar ferramentas adicionais (ou seja, kubectl, Helm, Docker, Ansible, Terraform, SSH) para que o cliente 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 a possibilidade de observar o estado atual do ambiente e o estado de implantação.
- Melhor segurança e conformidade simplificada porque o ambiente apenas requer permissão para visualizar a fonte.
- Deteção rápida de desvios de configuração resultantes de intervenção humana manual ou de outras fontes.
Contras:
- Mais complexo para implementações não Kubernetes.
- Requer ferramentas concebidas para trabalhar com tipos de ambiente específicos.
Ao começar a planear a sua estratégia GitOps, considere como diferentes estratégias de implementação irão apoiar a sua aplicação. 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 considerar e, com alguma perspetiva, saberá qual é a solução certa para a sua equipa e para a sua pilha.
Procurando mais informações? Faça o download do nosso e-book gratuito Estratégia GitOps ou obtenha uma consulta gratuita com um especialista em computação em nuvem da Akamai.
Comentários