O que é GitOps

O foco está na automação de operações, impulsionada a partir de repositórios Git. Embora esteja no título, o Git não é o único repositório que pode ser usado. São as interfaces fornecidas pelo Git que automatizam as operações. O GitOps acaba usando informações extraídas dos metadados de compilação para determinar quais pacotes compilar acionado por uma alteração de código específica:

Em sua essência, o modelo GitOps usa o padrão do controlador. Isso é reforçado ainda mais pelo padrão de operador, na perspectiva do Kubernetes ou do OpenShift, em que os operadores são extensões de software que usam recursos personalizados para gerenciar aplicações e seus componentes.

Não podemos deixar de mencionar o Argo CD, uma ferramenta de GitOps que auxilia nos fluxos de trabalho de GitOps. O Argo CD é uma ferramenta declarativa de código aberto para a integração contínua e a implementação contínua (CI/CD) de aplicações. Implementado como um controlador do Kubernetes, o Argo CD monitora continuamente as definições e configurações das aplicações em execução, comparando o estado atual e ativo do cluster com o estado desejado definido em um repositório Git.

Mas o GitOps não é um único produto, plug-in ou plataforma. Os fluxos de trabalho do GitOps ajudam as equipes a gerenciar a infraestrutura de TI por meio de processos que elas já utilizam no desenvolvimento de aplicações. Para pegar emprestado de um blog do GitLab, o GitOps requer três componentes principais: GitOps = IaC + PRs ou MRs + CI/CD

• IaC: a infraestrutura como código (IaC) é a prática de manter toda a configuração de infraestrutura armazenada como código. O GitOps usa um repositório Git como fonte única da verdade para as definições de infraestrutura. O Git rastreia todas as mudanças de gerenciamento de código.
  
  
• PRs ou MRs: o GitOps usa pull requests (PRs) ou merge requests (MRs) como mecanismo de mudança para todas as atualizações de infraestrutura. É aqui que as equipes podem colaborar por meio de revisões e comentários e onde ocorrem as aprovações formais.
  
  
• CI/CD: o GitOps automatiza as atualizações da infraestrutura usando um fluxo de trabalho do Git com integração contínua (CI) e entrega contínua (CD). Quando um novo código é mesclado, o pipeline de CI/CD promulga a mudança no ambiente. Qualquer desvio de configuração, como alterações manuais ou erros, é substituído pela automação do GitOps para que o ambiente convirja para o estado desejado definido no Git, fornecendo, assim, operações contínuas (CO):

Os operadores do Red Hat OpenShift simplificam a instalação e a orquestração automatizada de cargas de trabalho complexas. Eles ajudam a codificar a lógica operacional humana para gerenciar serviços executados como aplicações nativas do Kubernetes, facilitando as operações do dia 2. O operador é um software executado em um pod no cluster, interagindo com o servidor de API do Kubernetes. Um operador OpenShift é essencialmente um controlador personalizado e pode ser, na prática, um controlador específico da aplicação.

O Red Hat OpenShift facilita o uso do GitOps para desenvolvedores que desejam usar o GitOps, ao fornecer os operadores necessários. Uma vez implementados, podem ser visualizados na seção Operadores instalados no console do OpenShift. O operador Red Hat OpenShift GitOps é o operador upstream para o ArgoCD, e o operador Red Hat OpenShift Pipelines, que também é implementado, é o operador upstream para o Tekton. Veja a Figura 3:

Os operadores e APIs relacionados podem, então, ser usados para iniciar um ou mais pipelines do GitOps que podem ser implementados em diferentes ambientes, fornecendo o resultado de configuração desejado do Git. Os ambientes podem ser os de desenvolvimento, teste e produção usuais, mas também podem abranger ambientes geográficos, como a nuvem, a rede de telecomunicações ou nós de edge computing.

Os recursos de implementação são classificados em três áreas: infraestrutura, serviços e aplicações. Essas áreas facilitam a separação e o gerenciamento da implementação dos recursos relacionados:

• Infraestrutura é onde os namespaces e as unidades de armazenamento necessários são definidos.
• Serviços é onde os vários operadores necessários para configurar as instâncias são descritos.
• Aplicações é onde a aplicações a serem implementadas são enumeradas.

A edge computing está observando a proliferação de clusters OpenShift ou Kubernetes na maioria dos centros de TI. Ela tem o potencial de atingir uma escala maciça de centenas a milhares de implementações por cliente. O resultado é que os departamentos de TI corporativos devem gerenciar múltiplos clusters de tempo de execução de contêineres independentes ou cooperativos em execução em locais e/ou nuvens públicas.

Garantir que os clusters tenham o mesmo estado desejado (implementar uma mudança e reverter uma mudança em várias nuvens) é um grande benefício que o GitOps oferece às empresas baseadas em edge e IoT.

O paradigma do GitOps é aplicável na edge, pois um dos principais desafios que os provedores de serviços de comunicação (CSPs) enfrentam é a orquestração, a automação e o gerenciamento de suas redes. Embora o 5G seja um benefício para os consumidores, as redes definidas por software (SDNs), o fatiamento da rede com diferentes larguras de banda e a implementação mais rápida criaram desafios para os provedores de telecomunicações.

Um pipeline de implementação automatizado é uma maneira de os CSPs levarem serviços aos clientes mais rapidamente. Ter um repositório central e uma abordagem declarativa para o provisionamento da infraestrutura de contêineres significa um tempo mais rápido de lançamento no mercado para novas funcionalidades e solicitações de mudanças. Esse paradigma ajudará no provisionamento de VNFs (funções de rede virtual) e CNFs (funções de rede nativa da nuvem) na edge da rede. A conteinerização de componentes de rede torna possível gerenciar essas funções. Por último, como toda a atividade de configuração é registrada e armazenada no Git, a capacidade de rastrear alterações é crítica para fins de conformidade e auditoria. Há alguns blogs relacionados do WeaveWorks nas referências:

O GitOps permite que as organizações implementem em vários destinos simultaneamente. Ele permite a implantação de implementações granulares. Isso seria extremamente útil ao implementar aplicações em centenas e dezenas de milhares de nós de edge, que vêm em diferentes formas e formatos e usam protocolos de comunicação variados, especialmente se os nós de edge forem pequenos clusters de edge usando um Intel NUC ou NVIDIA Jetson.

O framework GitOps pode ser útil para implementar as aplicações e usar o repositório Git como fonte única da verdade.As equipes de ITOps buscam a implementação autônoma de aplicações, o gerenciamento e as operações dos nós de borda, o que é facilitado pelo uso dos operadores do Red Hat OpenShift.

O benefício do GitOps é evidente na borda de rede e na borda corporativa. Os dispositivos de borda extrema apresentam um desafio diferente porque a capacidade de armazenamento e processamento de alguns desses dispositivos não é grande o suficiente para hospedar serviços de GitOps e executar aplicações.

O lançamento de distribuições Kubernetes leves, como K3s e K0s, destina-se a casos de uso de IoT e edge. A capacidade de implementar uma distribuição leve do Kubernetes em um dispositivo de edge nos permite executar uma ferramenta do GitOps como o Argo CD. O(s) dispositivo(s) poderá(ão), então, adotar o modelo de sondagem de um repositório Git para o estado desejado e sincronizá-lo com o estado de produção do cluster.