GitOps na edge

O GitOps é uma prática de DevOps que usa o Git como a fonte única da verdade onde o estado de configuração desejado é armazenado. 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 é ainda mais auxiliado pelo padrão de operadores de uma perspectiva do Kubernetes ou do OpenShift, em que os operadores são extensões de software que utilizam recursos personalizados para gerenciar aplicações e seus componentes.

Seria errado não mencionar o Argo CD, uma ferramenta do GitOps que ajuda nos fluxos de trabalho do GitOps. O Argo CD é uma ferramenta declarativa de código aberto para a integração contínua e implementação contínua (CI/CD) de aplicações. Implementado como um controlador Kubernetes, o Argo CD monitora continuamente as definições e configurações das aplicações em execução, comparando o estado atual e ativo no 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: 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 a 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 solicitações de pull (PRs) ou solicitações de mesclagem (MRs) como mecanismo de alteração para todas as atualizações de infraestrutura. É aqui que as equipes podem colaborar por meio de avaliaçõ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.

Em um blog anterior, discutimos DevOps no domínio de edge computing; aqui, damos uma olhada em como o GitOps pode ser aplicado na edge computing. Aludimos às três edges da edge domputing:

• Edge empresarial
• Edge de rede
• Edge de dispositivo (ou edge distante)

Há também a nuvem ou o data center empresarial. Vamos dar uma olhada detalhada nessas áreas. Junto com os ambientes de edge, a Figura 4 também representa as três áreas do GitOps: infraestrutura, serviços e aplicações.

Data center em nuvem/empresarial

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.

Edge de rede

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:

Edge empresarial

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 do GitOps pode ser benéfico na implementação de aplicações e no uso do repositório Git como fonte única da verdade. As equipes de ITOps buscam a implementação, o gerenciamento e as operações autônomas de nós de edge, o que é facilitado com o uso de operadores Red Hat OpenShift.

Edge de dispositivo (ou edge distante)

O benefício do GitOps é óbvio na edge da rede e na edge da empresa. Os dispositivos de edge apresentam um desafio diferente, pois a capacidade de armazenamento e computação de alguns desses dispositivos não é grande o suficiente para hospedar serviços do 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.

Ao usar o GitOps, você resolve os problemas de infraestrutura e configuração de aplicações. O operador GitOps integrado no Red Hat OpenShift facilita a implementação de um pipeline baseado no Argo CD. Clientes de IBM Cloud Paks, incluindo IBM Cloud Pak for Network Automation, podem usar operadores Red Hat para instalar recursos e empregar o framework do GitOps para automatizar e controlar o processo de implementação.

O IBM Cloud Native Toolkit é um excelente ponto de partida. É uma coleção de ativos de código aberto que permite o desenvolvimento de aplicaçõese a implementação de operações.

Agradecimentos especiais a Hollis Chui e Kavitha Bade por revisarem o artigo.

• IBM Cloud Pak for Network Automation
• IBM Cloud Pak for Data
• IBM Cloud Native Toolkit

• O que é o GitOps?
• Introdução ao GitOps com OpenShift