O GitOps é a próxima grande novidade no DevOps?
Muitas empresas agora veem o DevOps como parte de sua estratégia de transformação digital, uma vez que ele incentiva uma cultura de responsabilidade compartilhada, transparência e feedback mais rápido. No entanto, à medida que a lacuna entre as equipes de desenvolvimento e operações diminui, os processos também diminuem.
O mesmo acontece com o Git, o sistema de controle de versão mais usado no mundo hoje em dia. À medida que as empresas adotam metodologias de DevOps, as ferramentas fazem o mesmo, o que criou uma evolução para o GitOps, um conjunto de práticas que permitem aos desenvolvedores realizar mais tarefas relacionadas às operações de TI.
O que é GitOps?
Em sua essência, o GitOps é uma infraestrutura e um conjunto de procedimentos operacionais com base em código que dependem do Git como um sistema de controle de origem. É uma evolução da Infraestrutura como Código (IaC) e uma prática recomendada de DevOps que aproveita o Git como a única fonte de informações e o mecanismo de controle para criar, atualizar e excluir a arquitetura do sistema. Simplificando: é a prática de usar pull requests do Git para verificar e implementar automaticamente modificações na infraestrutura do sistema.
Além do Git como um mecanismo-chave de DevOps, o GitOps também é usado para descrever ferramentas que aumentam a funcionalidade padrão do Git. Essas ferramentas foram usadas principalmente com modelos operacionais para infraestrutura e aplicativos baseados em Kubernetes. Há desenvolvimento e discussão contínuos dentro da comunidade de DevOps para trazer ferramentas GitOps para outras plataformas não Kubernetes, como o Terraform.
O GitOps garante que a infraestrutura de nuvem de um sistema seja imediatamente reproduzível com base no estado de um repositório do Git. As pull requests modificam o estado do repositório do Git. Depois da aprovação e do merge, as pull requests vão fazer a reconfiguração e a sincronização automáticas da infraestrutura ativa com o estado do repositório. Esse fluxo de trabalho de pull request de sincronização em tempo real é a essência central do GitOps.
Material relacionado
Folha de consulta do Git
VER SOLUÇÃO
Aprenda a usar o Git com o Bitbucket Cloud
A história do GitOps
O Git é uma ferramenta essencial para o desenvolvimento de software que permite fluxos de trabalho de pull request e revisão de código. As pull requests promovem a visibilidade das alterações recebidas em uma base de código e incentivam a comunicação, a discussão e a revisão das alterações.
As pull requests são uma funções decisiva no desenvolvimento colaborativo de software e mudaram a maneira como as equipes e as empresas criam software. Elas trazem transparência e mensurabilidade a um processo antes opaco. As pull requests do Git ajudaram a trazer a evolução dos processos de DevOps para o desenvolvimento de software. Os administradores de sistema, que normalmente hesitavam em mudar, agora estão adotando novas práticas de desenvolvimento de software, como a metodologia ágil e o DevOps.
A administração de sistemas como um ofício tem uma história desleixada. Antes, os administradores de sistema gerenciavam o hardware manualmente pela conexão e pelo provisionamento com máquinas em um rack de servidor físico ou por meio de uma API de provisionamento de nuvem. Além do processo de provisionamento manual, grandes quantidades de trabalho de configuração manual eram uma rotina regular. Os administradores mantinham coleções personalizadas de scripts e configurações imperativos, juntavam essas coleções e as colocavam em vários lugares. Esses scripts podiam quebrar a qualquer momento ou se perder. A colaboração foi desafiadora, pois as cadeias de ferramentas personalizadas não eram documentadas ou compartilhadas regularmente.
O movimento DevOps surgiu desse pântano primordial de administração de sistemas. O DevOps pegou emprestadas as melhores ideias da engenharia de software e as aplicou à administração de sistemas, onde as ferramentas combinadas passaram a ser código controlado por versão.
A IaC é uma das maiores revelações do DevOps. Antes, os administradores de sistema preferiam scripts imperativos personalizados para configurar sistemas. O software imperativo segue uma sequência de etapas para alcançar um estado desejado, como:
O software imperativo geralmente é propenso a erros e é fácil de quebrar alterando a sequência de eventos. O desenvolvimento de software moderno tem se afastado de padrões imperativos e ido em direção a padrões de software declarativos.
O software declarativo segue uma declaração de um estado esperado em vez de uma sequência de comandos. Veja uma comparação de instruções de DevOps imperativas versus declarativas.
Enquanto as instruções imperativas poderiam ser:
- Instale um sistema operacional nesta máquina
- Instale estas dependências
- Baixe o código desta URL
- Mova o código para este diretório
- Faça essas etapas 3 vezes para 3 outras máquinas
A versão declarativa disso seria simplesmente: 4 máquinas têm software dessa URL instalado neste diretório.
A IaC incentiva e promove ferramentas declarativas de administração de sistemas em vez de soluções imperativas personalizadas. Assim surgiram tecnologias como contêineres do Docker, Ansible, Terraform e Kubernetes, que utilizam arquivos de configuração declarativos estáticos. A legibilidade humana e o estado reprodutível consistente são os resultados benéficos. Esses arquivos de configuração foram naturalmente adicionados ao Git para rastreamento e revisão. Ainda não é bem o GitOps, mas está perto.
Muitos dos problemas tradicionais de administração do sistema foram resolvidos neste ponto da história do DevOps. Os arquivos e ferramentas de configuração agora são armazenados em um local central, documentados e acessíveis por muitos membros da equipe. Commits e pull requests foram usados para rastrear modificações na configuração e promover a discussão e a revisão da colaboração. O único problema remanescente com esse estágio é que a configuração ainda parece desconectada do sistema ativo. Depois que uma pull request de configuração passa pela aprovação e pelo merge ao repositório, o sistema ativo é atualizado manualmente para corresponder ao estado do repositório estático. Esse é o problema exato que o GitOps resolve.
A ideia do GitOps foi criada e compartilhada pela Weaveworks, uma empresa de gerenciamento corporativo do Kubernetes e, desde então, proliferou em toda a comunidade de DevOps. GitOps é uma extensão da IaC e da configuração declarativa discutidas acima. O GitOps adiciona alguma mágica ao fluxo de trabalho de pull request que sincroniza o estado do sistema ativo com o do repositório de configuração estática.
Os benefícios do GitOps
O GitOps compartilha muitos dos mesmos benefícios que um fluxo de trabalho de desenvolvimento de software de branch de características ágil. O primeiro grande benefício é a facilidade de adoção devido ao uso de ferramentas comuns. O Git é o padrão de fato dos sistemas de controle de versão e é uma ferramenta de desenvolvimento de software comum para a maioria dos desenvolvedores e equipes de software. Assim fica mais fácil para os desenvolvedores familiarizados com o Git serem contribuidores multifuncionais e participarem do GitOps.
O uso de um sistema de controle de versão permite que a equipe rastreie todas as modificações na configuração de um sistema. Assim, a equipe tem uma "fonte de informações" e uma trilha de auditoria valiosa para revisar caso algo quebre ou apresente comportamento inesperado. As equipes podem revisar o histórico do GitOps e ver quando uma regressão foi introduzida. Além disso, essa trilha de auditoria pode ser usada como referência para auditoria de conformidade ou segurança. O histórico do GitOps pode ser usado como prova quando coisas como certificados de criptografia são modificadas ou atualizadas.
O GitOps traz transparência e clareza às necessidades de infraestrutura de uma empresa em torno de um repositório central. Conter todas as configurações de sistemas em um repositório central ajuda a escalar a contribuição dos membros da equipe. As pull requests feitas por meio de serviços Git hospedados, como o Bitbucket, têm ferramentas avançadas para revisão de código e comentários de discussão. Esses recursos criam loops de comunicação passivos que permitem que toda a equipe de engenharia observe e monitore as alterações na infraestrutura.
O GitOps pode aumentar muito a produtividade de uma equipe de DevOps. Assim eles podem logo experimentar novas configurações de infraestrutura. Se as novas alterações não se comportarem conforme o esperado, uma equipe vai poder usar o histórico do Git para reverter as alterações para um bom estado conhecido. O poder desse recurso é incrível, pois permite a funcionalidade familiar de “desfazer” em uma infraestrutura complicada.
Como o GitOps funciona
Os procedimentos do GitOps são executados por um sistema de orquestração subjacente. O GitOps em si é um padrão de práticas recomendadas independente. Hoje em dia, muitas soluções populares do GitOps usam principalmente o Kubernetes como sistema de orquestração. Alguns conjuntos de ferramentas de GitOps alternativos que são compatíveis com a manipulação direta do Terraform estão chegando ao mercado.
Para obter uma instalação completa do GitOps, é necessária uma plataforma de pipeline. Jenkins, Bitbucket Pipelines ou CircleCI são algumas ferramentas de pipeline populares que são complementares ao GitOps. Os pipelines automatizam e preenchem a lacuna entre as pull requests do Git e o sistema de orquestração. Depois que os hooks do pipeline são estabelecidos e acionados a partir de pull requests, os comandos são executados na parte de orquestração.
Um novo padrão ou componente que é introduzido especificamente com o GitOps é o “operador” de GitOps, que é um mecanismo que fica entre o pipeline e o sistema de orquestração. Uma pull request inicia o pipeline que aciona o operador. O operador examina o estado do repositório e o início da orquestração e os sincroniza. O operador é o componente mágico do GitOps.
Exemplos de GitOps
Imagine que uma equipe identifique um gargalo de desempenho ou um pico no tráfego e perceba que o balanceador de carga não está funcionando conforme o esperado. Eles examinam o repositório do GitOps que contém a configuração da infraestrutura e encontram um arquivo específico que configura e implementa o balanceador de carga. Eles podem analisar esse arquivo no seu site de hospedagem do Git on-line. Após algumas revisões e discussões, eles identificam que alguns dos valores de configuração do balanceador de carga não são ideais e precisam ser ajustados.
Um membro da equipe abre uma nova pull request que otimiza os valores do balanceador de carga. A pull request é revisada e aprovada por um segundo membro da equipe e passa por merge ao repositório. O merge inicia um pipeline do GitOps, que aciona o operador do GitOps. O operador vê que a configuração do balanceador de carga foi alterada. Ele confirma com a ferramenta de orquestração de sistemas que ela não corresponde à que está ativa no cluster de equipes.
O operador sinaliza que o sistema de orquestração deve atualizar a configuração do balanceador de carga. O orquestrador lida com o resto e implementa automaticamente o balanceador de carga com a nova configuração. Em seguida, a equipe monitora o sistema ativo recém-atualizado para vê-lo retornar a um estado íntegro. Esse é um cenário ideal do GitOps. Vamos expandi-lo ainda mais para demonstrar o utilitário GitOps.
Imagine que, em vez de ajustar levemente os valores do balanceador de carga para serem mais ideais, a equipe tome uma decisão agressiva de implementar um tipo de balanceador de carga totalmente novo. Eles acham que o balanceador de carga atual tem falhas fundamentais e querem tentar uma opção alternativa. O fluxo de trabalho é o mesmo que o do ajuste de valor. A equipe cria uma pull request que introduz uma configuração de balanceador de carga totalmente nova e exclui a configuração antiga. Ela é aprovada e implementada por meio do pipeline.
Infelizmente, a equipe descobre que esse novo tipo de balanceador de carga é incompatível com alguns outros serviços em seu cluster. O novo balanceador de carga causa falhas de tráfego críticas e interrompe as operações do usuário. Felizmente, como a equipe tem um pipeline completo do GitOps, ela pode desfazer essas alterações no balanceador de carga com rapidez. A equipe vai fazer outra pull request que reverte o repositório para o antigo balanceador de carga funcional conhecido. Essa ação vai ser observada pelo pipeline do GitOps e implementada automaticamente. Assim, a infraestrutura e a pontuação de confiabilidade da equipe vão apresentar uma melhora rápida.
Resumo
O GitOps é um padrão de fluxo de trabalho incrivelmente poderoso para gerenciar a infraestrutura de nuvem moderna. Embora o foco principal esteja no gerenciamento de clusters do Kubernetes, a comunidade de DevOps está aplicando e publicando soluções de GitOps em outros sistemas que não sejam de Kubernetes. O GitOps pode trazer muitos benefícios para equipes de engenharia, incluindo melhor comunicação, visibilidade, estabilidade e confiabilidade do sistema. Um dos principais requisitos para uma experiência com o GitOps é uma plataforma Git hospedada moderna como o Bitbucket.
Compartilhar este artigo
Próximo tópico
Leitura recomendada
Marque esses recursos para aprender sobre os tipos de equipes de DevOps ou para obter atualizações contínuas sobre DevOps na Atlassian.
Blog do Bitbucket
Caminho de aprendizagem de DevOps
