GitOps: outra palavra da moda ou um avanço na automação?

A maioria de nós, percebendo outro termo novo na blogosfera ou conferência de TI, mais cedo ou mais tarde faz uma pergunta semelhante: “O que é isso? Apenas mais uma palavra da moda, uma “palavra da moda” ou algo realmente digno de atenção, estudo e promessa de novos horizontes?” A mesma coisa aconteceu comigo com o termo GitOps algum tempo atrás. Munido de muitos artigos existentes, bem como do conhecimento de colegas da empresa GitLab, tentei descobrir que tipo de animal é esse e como seria seu uso na prática.

Aliás, sobre a novidade do termo GitOps Nossa recente pesquisa também diz: mais da metade dos entrevistados ainda não começaram a trabalhar com seus princípios.

Portanto, o problema da gestão da infra-estrutura não é novo. Muitos provedores de nuvem estão disponíveis ao público em geral há vários anos e, ao que parece, deveriam ter tornado o trabalho das equipes responsáveis ​​pela infraestrutura simples e direto. No entanto, quando comparados com o processo de desenvolvimento de aplicações (onde a automação está a atingir níveis cada vez mais novos), os projetos de infraestruturas ainda envolvem muitas vezes muitas tarefas manuais e requerem conhecimento e experiência especializados, especialmente tendo em conta os requisitos atuais de tolerância a falhas, flexibilidade, escalabilidade e elasticidade.

Os serviços em nuvem cumpriram estes requisitos com muito sucesso e foram eles que deram um impulso significativo ao desenvolvimento da abordagem IaC. Isto é incompreensível. Afinal, eles possibilitaram configurar um data center totalmente virtual: não há servidores físicos, racks ou componentes de rede; toda a infraestrutura pode ser descrita por meio de scripts e arquivos de configuração.

Então, qual é exatamente a diferença? GitOps de IaC? Foi com essa pergunta que comecei minha investigação. Depois de conversar com colegas, consegui fazer a seguinte comparação:

GitOps

IaC

Todo o código é armazenado em um repositório git

O versionamento de código é opcional

Descrição do Código Declarativo/Idempotência

Ambas as descrições declarativas e imperativas são aceitáveis

As alterações entram em vigor usando os mecanismos Merge Request/Pull Request

Acordo, aprovação e colaboração são opcionais

O processo de implementação da atualização é automatizado

O processo de implementação da atualização não é padronizado (automático, manual, cópia de arquivos, uso da linha de comando, etc.)

Em outras palavras GitOps nasceu precisamente através da aplicação dos princípios IaC. Em primeiro lugar, a infra-estrutura e as configurações poderiam agora ser armazenadas da mesma forma que as aplicações. O código é fácil de armazenar, compartilhar, comparar e usar recursos de controle de versão. Versões, ramificações, história. E tudo isso em um local de acesso público a toda a equipe. Portanto, o uso de sistemas de controle de versão tornou-se um desenvolvimento completamente natural. Em particular, o git é o mais popular.

Por outro lado, tornou-se possível automatizar os processos de gestão de infraestruturas. Agora isso pode ser feito de forma mais rápida, confiável e barata. Além disso, os princípios do CI/CD já eram conhecidos e populares entre os desenvolvedores de software. Foi necessário apenas transferir e aplicar conhecimentos e habilidades já conhecidos para uma nova área. Estas práticas, no entanto, foram além da definição padrão de Infraestrutura como código, daí o conceito GitOps.

Curiosidade GitOps, claro, também pelo fato de não ser um produto, plugin ou plataforma associada a nenhum fornecedor. É mais um paradigma e um conjunto de princípios, semelhante a outro termo que conhecemos: DevOps.

A empresa GitLab desenvolvemos duas definições deste novo termo: teórica e prática. Vamos começar com o teórico:

GitOps é uma metodologia que utiliza os melhores princípios de DevOps usados ​​para desenvolvimento de aplicações, como controle de versão, colaboração, orquestração, CI/CD, e os aplica aos desafios de automatização do gerenciamento de infraestrutura.

Todos os processos GitOps Eu trabalho usando ferramentas existentes. Todo o código da infraestrutura é armazenado no já conhecido repositório git, as alterações passam pelo mesmo processo de aprovação que qualquer outro código de programa e o processo de implementação é automatizado, o que nos permite minimizar erros humanos, aumentar a confiabilidade e a reprodutibilidade.

Do ponto de vista prático, descrevemos GitOps da seguinte maneira:

Já discutimos a infraestrutura como código como um dos principais componentes desta fórmula. Vamos apresentar o resto dos participantes.

Solicitação de mesclagem (nome alternativo Pull Request). Em termos de processo, MR é uma solicitação para aplicar alterações de código e depois mesclar ramificações. Mas em termos das ferramentas que usamos, esta é mais uma oportunidade de obter uma visão completa de todas as mudanças que estão sendo feitas: não apenas a diferença de código coletada de um certo número de commits, mas também o contexto, os resultados dos testes e o resultado final esperado. Se estamos falando de código de infraestrutura, então estamos interessados ​​em saber exatamente como a infraestrutura mudará, quantos novos recursos serão adicionados ou removidos, alterados. De preferência em algum formato mais conveniente e fácil de ler. Para os provedores de nuvem, é uma boa ideia saber qual será o impacto financeiro desta mudança.

Mas a RM também é um meio de colaboração, interação e comunicação. O lugar onde o sistema de freios e contrapesos entra em ação. Desde simples comentários até aprovações e aprovações formais.

Pois bem, o último componente: CI/CD, como já sabemos, permite automatizar o processo de realização de alterações e testes de infraestrutura (desde a simples verificação de sintaxe até análises estáticas de código mais complexas). E também na posterior detecção de desvios: diferenças entre o estado real e o desejado do sistema. Por exemplo, como resultado de alterações manuais não autorizadas ou falha do sistema.

Sim, o termo GitOps não nos apresenta nada de completamente novo, não reinventa a roda, mas simplesmente aplica a experiência já acumulada numa nova área. Mas é aqui que reside a sua força.

E se de repente você ficar interessado em como tudo isso parece na prática, então convido você a dar uma olhada em nosso master class, no qual conto passo a passo como usar o GitLab:

• Implemente os princípios básicos do GitOps

• Crie e faça alterações na infraestrutura em nuvem (usando o exemplo do Yandex Cloud)

• Automatize a detecção de desvios do sistema a partir de um estado desejado usando monitoramento ativo

https://bit.ly/34tRpwZ

Fonte: habr.com