Empresas que querem se tornar mais rápidas, que precisam realizar deploys frequentes com mais segurança e com menos sobrecarga, o GitOps é um método rápido e seguro para o time de desenvolvedores manter e atualizar aplicações complexas em execução no Kubernetes.
Como o Kubernetes e muitas outras tecnologias cloud native são quase inteiramente declarativas, as definições de infraestrutura podem ser mantidas com o código da aplicação no Git. Manter todo o seu sistema em Git significa que sua equipe de desenvolvimento usa workflows bastante familiares baseados em Git e Pull Requests para aplicar tanto as alterações da aplicação quanto infraestrutura ao Kubernetes.
Com todo o estado do cluster mantido sob controle de código-fonte, as ferramentas de Diff e os agentes de sincronização podem comparar o que está em produção com o que está no repositório de fonte e quando uma divergência é detectada entre os dois, um alerta pode ser enviado, criando um método eficiente de loop de feedback e controle para gerenciar seu cluster.
Em sua essência, GitOps é:
GitOps dá a você a liberdade de escolher as melhores ferramentas para diferentes partes dos pipelines CI/CD. É possível selecionar ferramentas do ecossistema de código aberto (open source) ou fechado e, dependendo de suas necessidades, até combiná-las.
Quaisquer que sejam as ferramentas escolhidas para seus pipelines de implantação e entrega, a aplicação das melhores práticas do GitOps deve ser um componente integral em seu processo de entrega contínua. Isso tornará a construção e adoção de uma cultura de entrega contínua em sua organização muito mais fácil.
Aplicar as melhores práticas do GitOps geram resultados de longo prazo e fornecem:
A precisão e a segurança do Git, apoiadas pela forte criptografia usada para rastrear e gerenciar as alterações, bem como a capacidade de identificar estas alterações para provar a autoria e origem, são as chaves para uma definição correta e segura do estado desejado de um cluster.
Se ocorrer uma violação de segurança, uma única fonte de verdade – single source of truth (SSOT) – imutável e auditável pode ser usada para recriar um novo sistema independente daquele comprometido, reduzindo o downtime e permitindo uma resposta muito melhor a incidentes.
Além disso, a responsabilidade dividida entre o empacotamento do software e a sua liberação para um ambiente de produção incorpora o princípio de segurança do menor privilégio, que reduz o impacto de um potencial comprometimento e fornece uma menor superfície de ataque.
A automação de deployment contínuo integrado com loop de feedback e controle acelera o tempo médio de deployment. As definições declarativas mantidas no git permitem que os desenvolvedores usem workflows mais familiares, reduzindo o tempo utilizado para subir um novo ambiente de desenvolvimento ou de teste para implantar novos recursos em um cluster.
As equipes podem entregar mais alterações por dia e isso se traduz em tempo de resposta mais rápido para novos recursos e funcionalidades para o cliente.
A quantidade de tempo de recuperação após o colapso de um cluster também é reduzida com as melhores práticas de GitOps. Com a capacidade integrada do git para revert/rollback and fork, você ganha rollbacks estáveis e reproduzíveis. Uma vez que todo o seu sistema está descrito no git, há somente uma fonte de verdade para se recuperar após uma falha de cluster, reduzindo o tempo médio para recuperação (MTTR) de horas para minutos.
Como o GitOps fornece um único modelo operacional para criar infraestrutura e aplicações, você tem workflows consistentes, de ponta a ponta, em toda a organização. Não só a integração contínua e os pipelines de deployment contínuo são orientados por pull requests, mas também as tarefas operacionais são totalmente reproduzíveis por meio do git.
Com a capacidade do git de gerenciar seu cluster Kubernetes, você obtém, automaticamente, uma trilha de auditoria conveniente para todas as alterações de cluster fora do Kubernetes, que podem ser usadas para atender a conformidade com SOC 2 e garantir estabilidade.
Como as alterações são rastreadas e registradas de maneira segura, a conformidade e a auditoria tornam-se triviais. O uso de ferramentas de software como Kubediff, Terradiff e Ansiblediff também permite comparar uma definição confiável do estado do cluster com o mesmo em execução real, garantindo que as alterações rastreadas e auditáveis correspondam à realidade.
Para aqueles que desejam implementar workflows GitOps em seus pipelines CI/CD, os pontos a seguir não podem faltar:
Kubernetes é uma das muitas ferramentas cloud native modernas que são declarativas e que podem ser tratadas como código. Declarativo significa que a configuração é garantida por um conjunto de fatos em vez de por conjunto de instruções.
Com as declarações da sua aplicação versionadas em git, você possui uma única fonte de verdade. Suas aplicações podem então ser facilmente implantadas e revertidas para o Kubernetes. E ainda mais importante e crítico para a história do GitOps é que, quando ocorre um desastre, seu cluster também pode ser reproduzido de forma previsível, confiável e rápida.
Com a declaração de seu sistema armazenada em um sistema de controle de versão e servindo como sua fonte de verdade canônica, você tem um lugar central de onde tudo é derivado e conduzido. Isso torna trivial rollbacks e você pode usar um “git revert” para voltar ao estado anterior. Com as excelentes garantias de segurança do git, os sinais de chave SSH se comprometem a aplicá-las sob a autoria e procedência do código.
Uma vez que se tenha o estado declarado mantido no git, a próxima etapa é conseguir aplicar automaticamente qualquer alteração de estado ao seu sistema. O que é significativo sobre isso é que você não precisa de credenciais específicas de cluster para fazer uma mudança em seu sistema. Com o GitOps, existe um ambiente segregado no qual a definição de estado se mantém fora. Isso permite que sua equipe separe o que eles realmente fazem de como irão fazer.
Com o estado de todo o seu sistema mantido sob controle de versão, agora você pode empregar agentes de software para informá-lo sempre que a realidade não corresponder às suas expectativas.
O uso de ferramentas diff e sync também garante que todo o seu sistema seja realmente self-healing, não só quando os nós ou pods falham – eles são gerenciados pelo Kubernetes – mas em um sentido mais amplo, como no caso de erros humanos. Nesse caso, os agentes de software atuam como loop de feedback e de controle para suas operações.
A maneira como o Kubernetes lida com implantações se adapta muito bem aos workflows GitOps. Por exemplo, quando um grupo de atualizações de configuração é feito por um operador humano, o orquestrador Kubernetes continuará aplicando essas alterações até que o estado do cluster seja convergido para a configuração atualizada feita por um humano. O mesmo se aplica a qualquer recurso do Kubernetes.
As implantações do Kubernetes possuem as seguintes propriedades que o tornam perfeito para workflows de implantação no estilo GitOps:
As implantações do Kubernetes também podem ser estendidas e automatizadas usando Kubernetes Custom Resource Definitions (CRDs) com o operator pattern. Esses agentes podem então ser usados para detectar e aplicar automaticamente as alterações de configuração de fora do sistema quando você precisar deles, essencialmente criando loops de feedback e controle.
Introduzir GitOps em sua organização significa:
Ter tudo em um só lugar significa que sua equipe de operações pode usar o mesmo workflow para fazer mudanças na infraestrutura criando issues e revisando pull requests. GitOps permite reverter qualquer mudança feita em seu cluster. Além disso, a capacidade de observabilidade integrada permite que suas equipes tenham mais autonomia ao realizar mais alterações e experimentar sem se preocupar em quebrar o build.
A maioria das organizações que iniciam sua jornada para a entrega contínua, começam automatizando um pipeline de CI/CD. Com esse pipeline recém-criado, a equipe de desenvolvimento ficará entusiasmada e começará a escrever e enviar códigos freneticamente para o git.
No exemplo a seguir, digamos que haja um único repositório de microsserviço que monta o seu código com seus arquivos de deployment YAML. Apenas relembrando, os arquivos YAML são os que definem ou declaram como o microsserviço é executado no cluster. Quando o desenvolvedor empurra o código para o git, uma ferramenta de integração contínua inicia testes unitários que eventualmente criam uma imagem de contêiner Docker que é enviada para container registry.
Com esse típico pipeline CI/CD baseado em push, as imagens Docker contêiner são implantadas no cluster real usando algum script bash personalizado ou através de outro método que se comunica diretamente com a API do Kubernetes.
Um pipeline CI/CD típico possui alguns problemas de segurança. Com essa abordagem, seu ferramental de CI envia e implanta imagens no cluster.
Para que o sistema de CI aplique as mudanças a um cluster, você precisa compartilhar suas credenciais de API com as ferramentas de CI e isso significa que ela se torna um alvo muito desejado. Se alguém invadi-la, certamente terá controle total sobre o cluster de produção, mesmo se ele for altamente seguro.
E o que acontece quando você precisa recriar seu cluster, no caso de um colapso total? Como você restaura o estado anterior da sua aplicação? Você teria que executar todos os seus jobs CI para reconstruir tudo e então reaplicar todos os workloads ao novo cluster. O pipeline de CI típico não tem seu estado facilmente registrado como quando você usa o GitOps.
Vamos ver como você pode melhorar um típico pipeline de CI/CD com GitOps.
O GitOps implementa um Kubernetes controller que lê e sincroniza implantações para seu cluster Kubernetes. O controller usa o operator pattern. Isso é significativo em dois níveis:
Com o operator pattern, um agente atua em nome do cluster. Ele observa eventos relacionados a alterações de recursos personalizados e, em seguida, aplica essas alterações com base em uma política de implantação. O agente é responsável por sincronizar o que está no git com o que está sendo executado no cluster, fornecendo uma maneira simples para sua equipe obter uma implantação contínua.
A imagem é extraída utilizando acesso read only ao repositório. A ferramenta de CI não recebe privilégios do cluster, portanto não introduz riscos de segurança significativos para o pipeline.
O GitOps separa o CI do CD e esse é um dos motivos pelos quais é um método mais seguro de implantação de aplicações no Kubernetes. A tabela abaixo mostra como GitOps separa privilégios de leitura / escrita entre o cluster, seu CI e ferramentas de CD e o repositório de contêiner, fornecendo à sua equipe um método seguro de criação de atualizações.
FERRAMENTAS CI
Testa, monta, escaneia, publica |
FERRAMENTA DE CD
Reconciliação entre git e o cluster |
Roda fora do cluster de produção | Roda dentro do cluster de produção |
Acesso de leitura ao repositório de código | Acesso de leitura/escrita ao repositório de configuração |
Acesso de leitura/escrita ao Repositório de Contêiner | Acesso de leitura ao repositório de imagens |
Acesso de leitura/escrita ao ambiente de integração contínua | Acesso de leitura/escrita ao cluster de produção |
Tabela 1: Separação de privilégios do GitOps
Alguns dos componentes essenciais do GitOps são o feedback e o controle. Mas o que isso significa exatamente? De modo a obter controle para que os desenvolvedores possam trabalhar de maneira mais rápida, é preciso capacidade de observabilidade embutida em seus workflows de implantação.
A capacidade de observabilidade integrada permite que os técnicos tomem decisões em tempo real baseadas em dados. Por exemplo, quando uma implantação está sendo executada, uma última verificação de integridade pode ser feita em seu cluster em execução antes de confirmar a atualização ou talvez uma atualização não tenha saído como planejado e pode ser facilmente revertida para um bom estado.
Com um loop de controle de feedback, você pode responder facilmente às seguintes perguntas:
Enquanto git é a fonte da verdade para o estado desejado do sistema, a Observabilidade fornece um benchmark para o estado real de produção do sistema em execução. GitOps aproveita ambos para gerenciar aplicações.
Com GitOps, divergência e convergência são alcançadas com um conjunto de ferramentas “diff” e “sync” (kubediff, terradiff e ansiblediff) que comparam o estado pretendido com o estado real. As ferramentas Diff também são usadas para alertar os desenvolvedores quando o deployment não está sincronizado.
Um ciclo de feedback com diffs e observabilidade integrada é parecido como a seguir, no qual a observabilidade fornece insights para desenvolvedores e operadores tomarem decisões importantes sobre implantações e o sistema:
Como serviços ou atualizações prestes a serem lançados podem ser observados em tempo real dentro do cluster em execução, é possível implantar com maior confiança e entregar recursos de melhor qualidade.
Observabilidade é o principal motivador do ciclo de entrega contínua para Kubernetes, pois descreve o estado de execução real do sistema em qualquer momento. O sistema em funcionamento é observado para compreendê-lo e controlá-lo.
Depois que novos recursos e correções são mesclados ao git, o pipeline de implantação é acionado e, quando a imagem está pronta para ser lançada, ela pode ser observada em tempo real no cluster em execução. Neste ponto, o desenvolvedor pode retornar para o início do pipeline com base neste feedback ou implantar e liberar a imagem para o cluster de produção.
O mecanismo central do GitOps está em seu conjunto de ferramentas CI/CD, com a peça crítica sendo a implantação contínua (CD) que oferece suporte à sincronização do git-cluster. Ele é projetado especificamente para sistemas controlados por versão e stacks de aplicações declarativas.
Cada desenvolvedor em sua equipe está familiarizado com o git e pode fazer pull requests. Agora também podem usar o git para acelerar e simplificar as implantações de aplicações no Kubernetes.
Aqui está um workflow típico de desenvolvedor para criar ou atualizar um novo recurso:
A Weave Kubernetes Plataform reduz a complexidade através de gerenciamento de configuração, automação e ferramental de operações. Com o gerenciamento de configuração GitOps, as equipes podem definir uma instalação padrão do Kubernetes e automatizar a implantação de novos nós seguindo um modelo predefinido. Ele também simplifica a instalação de cluster adicionais, uma vez que o Kubernetes já está pré-configurado e todas as aplicações executadas em cima dele também são predefinidas.
Com GitOps no centro do seu modelo operacional, as equipes podem instalar e gerenciar Kubernetes prontos para produção seja on-premise, em uma nuvem pública como AWS e até mesmo em nós OpenStack pré-criados. O GitOps pode ser usado para disparar um patch de cluster ou um minor version upgrade, ou adicionar e remover nós de cluster, sem ter que reconstruí-lo do zero.
Com toda a configuração do cluster armazenada no Git e gerenciada por meio do GitOps, você pode reproduzir um cluster inteiro de maneira repetível e previsível. Isso traz vantagens quando você está construindo ambientes de teste e pipelines, ou produzindo clusters para diferentes equipes com a mesma configuração base, ou melhorando sua capacidade de recuperação de desastres.
A equipe da Vertigo Tecnologia, parceira oficial no Brasil em serviços profissionais da Weaveworks, pode ajudá-lo a navegar pelo vasto cenário de tecnologias cloud native, tanto Open Source quanto pago.
Juntos, podemos criar uma arquitetura de referência cloud native que se adapte às suas necessidades de negócios. Você pode se beneficiar de um modelo de projeto já validado ou pode projetar, revisar e selecionar opções de tecnologia com nossa ajuda.
Tem dúvidas sobre o que você precisa para criar uma plataforma cloud native? Entre em contato conosco para obter uma demonstração da Weave Kubernetes Plataform.