Nota do tradutor.: Após uma publicação recente , sobre os métodos pull e push em GitOps, notamos um interesse crescente por esse modelo de forma geral; no entanto, há muito poucas publicações em russo sobre o assunto (não há nenhuma no Habr). Portanto, estamos felizes em apresentar a tradução de outro artigo — embora já quase um ano velho! — da empresa Weaveworks, cujo fundador criou o termo "GitOps". O texto explica a essência da abordagem e as principais diferenças em relação ao que já existe.
Um ano atrás, publicamos . Naquela ocasião, contamos como a equipe da Weaveworks lançou um SaaS inteiramente baseado em Kubernetes e desenvolveu um conjunto de melhores práticas prescritivas para implantação, gerenciamento e monitoramento em ambientes cloud native.
O artigo se tornou popular. Outras pessoas começaram a falar sobre GitOps, passaram a publicar novas ferramentas para , , , , etc. Em nosso site, surgiram publicações e casos de uso do GitOps. Mas algumas pessoas ainda tinham dúvidas. Como o modelo se diferencia do tradicional e da entrega contínua ()? É absolutamente necessário usar Kubernetes?
Logo percebemos que era necessário uma nova descrição, oferecendo:
- Uma grande quantidade de exemplos e histórias;
- Uma definição concreta de GitOps;
- Uma comparação com a entrega contínua tradicional.
Neste artigo, tentamos abordar todos esses temas. Você encontrará uma introdução atualizada ao GitOps e uma perspectiva dele do ponto de vista de desenvolvedores e CI/CD. Focamos principalmente em Kubernetes, embora o modelo possa ser generalizado.
Conheça: GitOps
Imagine Alice. She runs Family Insurance, offering health, auto, real estate, and travel insurance policies to people who are too busy to delve into the intricacies of contracts themselves. Her business started as a side project while Alice worked at a bank as a data scientist. One day she realized that she could use advanced computer algorithms for more effective data analysis and the creation of insurance packages. Investors funded the project, and now her company generates over $20 million a year and is rapidly growing. Currently, 180 people work there in various positions, including a tech team responsible for the development, maintenance of the website, database, and customer base analysis. The team of 60 is led by Bob, the company's CTO.
Bob's team deploys production systems in the cloud. Their main applications run on GKE, taking advantage of Kubernetes on Google Cloud. Additionally, they use various data and analytics tools in their work.
Family Insurance wasn't initially planning to use containers, but they became enthusiastic about Docker. Soon, the company's specialists discovered that GKE allows them to effortlessly deploy clusters to test new features. Jenkins was added for CI and Quay for organizing the container registry, and scripts were written for Jenkins to push new containers and configurations to GKE.
Depois de algum tempo, Alice e Bob ficaram desapontados com o desempenho da abordagem escolhida e seu impacto nos negócios. A implementação de containers não melhorou o desempenho tanto quanto a equipe esperava. Às vezes, as implementações falhavam, e não estava claro se isso se devia a alterações no código. Também se tornou difícil rastrear as mudanças nas configurações. Frequentemente, era necessário criar um novo cluster e mover os aplicativos para ele, uma vez que essa era a maneira mais fácil de limpar a bagunça na qual o sistema se transformou. Alice temia que a situação piorasse à medida que o aplicativo se desenvolvesse (além disso, um novo projeto baseado em aprendizado de máquina estava surgindo). Bob automatizou grande parte do trabalho e não entendia por que o pipeline ainda era instável, escalava mal e, de tempos em tempos, exigia intervenção manual.
Então, eles ouviram falar do GitOps. Essa solução se mostrou exatamente o que precisavam para avançar com confiança.
Alice e Bob já ouviam há anos sobre workflows baseados em Git, DevOps e infraestrutura como código. A singularidade do GitOps é que ele traz uma série de melhores práticas — rigorosas e normativas — para a implementação dessas ideias no contexto do Kubernetes. Esse assunto , inclusive no .
A Family Insurance decide implementar GitOps. Agora, a empresa possui um modelo de operação automatizado, compatível com Kubernetes e que combina a velocidade com um estabilidade, uma vez que eles:
- descobriram que a produtividade da equipe dobrou e ninguém enlouquece com isso;
- pararam de gerenciar scripts. Em vez disso, agora podem se concentrar em novas funcionalidades e aprimorar as práticas de engenharia — por exemplo, implementar deploys de canário e melhorar os testes;
- aperfeiçoaram o processo de deployment — agora ele raramente falha;
- conseguiram restaurar implementações após falhas parciais sem intervenção manual;
- adquiriram bmaiorlargura de confiança nos sistemas de entrega. Alice e Bob descobriram que podiam dividir a equipe em grupos que cuidavam de microsserviços e trabalhavam em paralelo;
- podem fazer de 30 a 50 alterações no projeto todos os dias com os esforços de cada grupo e experimentar novas técnicas.
- facilmente atraem novos desenvolvedores para o projeto, que têm a possibilidade de implementar atualizações na produção por meio de pull requests em poucas horas;
- passam facilmente pela auditoria dentro do SOC2 (em conformidade com os requisitos dos prestadores de serviços para a gestão segura de dados; leia mais, por exemplo, — nota do tradutor.).
O que aconteceu?
GitOps — são duas coisas:
- Um modelo de operação para Kubernetes e cloud native. Ele fornece um conjunto de melhores práticas para a implantação, gestão e monitoramento de clusters e aplicativos empacotados em contêineres. Uma definição elegante em forma de de :
- O caminho para criar um ambiente orientado a desenvolvedores para gestão de aplicativos. Aplicamos o fluxo de trabalho do Git tanto para operações quanto para desenvolvimento. Note que não se trata apenas de Git push, mas de organizar todo o conjunto de ferramentas de CI/CD e UI/UX.
Algumas palavras sobre o Git
Se você não está familiarizado com sistemas de controle de versão e fluxos de trabalho baseados em Git, recomendamos fortemente que se informe sobre eles. A princípio, trabalhar com branches e pull requests pode parecer mágica negra, mas os benefícios valem o esforço. Aqui para começar.
Como funciona o Kubernetes
Na nossa história, Alice e Bob recorreram ao GitOps após trabalharem um tempo com Kubernetes. De fato, o GitOps está intimamente relacionado ao Kubernetes — é um modelo de operação para infraestrutura e aplicativos baseados em Kubernetes.
O que o Kubernetes oferece aos usuários?
Aqui estão algumas das principais funcionalidades:
- No modelo Kubernetes, tudo pode ser descrito de forma declarativa.
- O servidor API do Kubernetes aceita essa declaração como entrada e, em seguida, tenta constantemente levar o cluster ao estado descrito na declaração.
- As declarações são suficientes para descrever e gerenciar uma ampla variedade de cargas de trabalho — "aplicativos".
- Como resultado, as alterações no aplicativo e no cluster ocorrem devido a:
- alterações nas imagens dos contêineres;
- alterações na especificação declarativa;
- erros no ambiente — por exemplo, falhas em contêineres.
As magníficas capacidades de convergência do Kubernetes
Quando um administrador faz alterações na configuração, o orquestrador do Kubernetes as aplicará ao cluster até que seu estado se aproxime da nova configuração. Este modelo funciona para qualquer recurso do Kubernetes e pode ser expandido com Custom Resource Definitions (CRDs). Portanto, os deployments do Kubernetes têm as seguintes propriedades incríveis:
- Automação: as atualizações do Kubernetes fornecem um mecanismo para automatizar o processo de aplicação de alterações de forma correta e pontual.
- Convergência: o Kubernetes continuará tentando atualizações até alcançar o sucesso.
- Idempotência: reaplicações da convergência levam ao mesmo resultado.
- Determinismo: dado recursos suficientes, o estado do cluster atualizado depende apenas do estado desejado.
Como funciona o GitOps
Aprendemos o suficiente sobre o Kubernetes para explicar os princípios do GitOps.
Vamos voltar para as equipes de Family Insurance que lidam com microsserviços. O que elas costumam fazer? Confira a lista abaixo (se algum dos itens parecer estranho ou desconhecido — por favor, aguarde antes de criticar e fique conosco). Esses são apenas exemplos de fluxos de trabalho baseados em Jenkins. Existem muitos outros processos com outras ferramentas.
O principal é que vemos que cada atualização resulta em alterações nos arquivos de configuração e nos repositórios Git. Essas alterações no Git fazem com que o ‘operador GitOps’ atualize o cluster:
1. Fluxo de trabalho: “Build do Jenkins — branch master».
Lista de tarefas:
- O Jenkins envia imagens etiquetadas para o Quay;
- O Jenkins envia configuração e charts do Helm para o bucket do repositório master;
- Uma função em nuvem copia a configuração e os charts do bucket do repositório master para o repositório Git master;
- O operador GitOps atualiza o cluster.
2. Build do Jenkins — branch release ou hotfix:
- O Jenkins envia imagens não etiquetadas para o Quay;
- O Jenkins envia configuração e charts do Helm para o bucket do repositório staging;
- Uma função em nuvem copia a configuração e os charts do bucket do repositório staging para o repositório Git staging;
- O operador GitOps atualiza o cluster.
3. Build do Jenkins — branch develop ou feature:
- O Jenkins envia imagens não etiquetadas para o Quay;
- O Jenkins envia configuração e charts do Helm para o bucket do repositório develop;
- Uma função em nuvem copia a configuração e os charts do bucket do repositório develop para o repositório Git develop;
- O operador GitOps atualiza o cluster.
4. Adicionando um novo cliente:
- O gerente ou administrador (LCM/ops) chama o Gradle para o primeiro deploy e configuração dos balanceadores de carga (NLB);
- O LCM/ops comita nova configuração para preparar o deployment para atualizações;
- O operador GitOps atualiza o cluster.
Breve descrição do GitOps
- Descreva o estado desejado de todo o sistema, utilizando especificações declarativas para cada ambiente (na nossa história, a equipe do Bob define toda a configuração do sistema no Git).
- O repositório Git é a única fonte de verdade em relação ao estado desejado de todo o sistema.
- Todas as mudanças no estado desejado são feitas por meio de commits no Git.
- Todos os parâmetros desejados do cluster também são observáveis no próprio cluster. Assim, podemos determinar se os estados desejados e observáveis convergem, converge) ou divergem, diverge) dos estados desejado e observado.
- Se os estados desejado e observado diferem, então:
- Há um mecanismo de convergência que, mais cedo ou mais tarde, sincroniza automaticamente os estados alvo e observado. Dentro do cluster, isso é tratado pelo Kubernetes.
- O processo é iniciado imediatamente com a notificação "change committed".
- Após um intervalo de tempo configurável, pode ser enviada uma notificação "diff", caso os estados estejam diferentes.
- Assim, todos os commits no Git provocam atualizações verificáveis e idempotentes no cluster.
- Um rollback é uma convergência para um estado desejado anterior.
- A convergência é final. Sua ocorrência é sinalizada por:
- Ausência de notificações "diff" durante um determinado intervalo de tempo.
- Notificação "converged" (por exemplo, webhook, evento de gravação no Git).
O que é divergência?
Repetindo mais uma vez: todas as propriedades desejadas do cluster devem ser observáveis no próprio cluster..
Alguns exemplos de divergência:
- Mudança em um arquivo de configuração devido a um merge de branches no Git.
- Mudança em um arquivo de configuração devido a um commit no Git, feito por um cliente GUI.
- Múltiplas alterações no estado desejado devido a um PR no Git, seguido pela construção de uma imagem de container e alterações na configuração.
- Mudança no estado do cluster devido a um erro, conflito de recursos causando "comportamento indesejado", ou simplesmente um desvio acidental do estado original.
O que representa um mecanismo de convergência?
Alguns exemplos:
- Para containers e clusters, o mecanismo de convergência é fornecido pelo Kubernetes.
- O mesmo mecanismo pode ser usado para gerenciar aplicações e construções baseadas em Kubernetes (por exemplo, Istio e Kubeflow).
- O mecanismo para gerir a interação operacional entre Kubernetes, repositórios de imagens e Git fornece , que é parte de .
- Para máquinas básicas, o mecanismo de convergência deve ser declarativo e autônomo. Pela nossa experiência, podemos dizer que está mais próximo dessa definição, embora ainda exija controle humano. Nesse sentido, o GitOps expande as tradições do Infrastructure as Code.
O GitOps combina o Git com um excelente mecanismo de convergência do Kubernetes, oferecendo um modelo para operação.
O GitOps nos permite afirmar: sistemas que podem ser descritos e monitorados são os únicos passíveis de automação e controle.
O GitOps é destinado a toda a pilha cloud native (por exemplo, Terraform, etc.)
O GitOps não se limita ao Kubernetes. Queremos que todo o sistema seja gerido de forma declarativa e utilize a convergência. Por todo o sistema, entendemos o conjunto de ambientes que operam com Kubernetes — por exemplo, 'dev cluster 1', 'produção', etc. Cada ambiente inclui máquinas, clusters, aplicativos e interfaces para serviços externos que fornecem dados, monitoramento, etc.
Observe como o Terraform é importante para o problema de bootstrapping. O Kubernetes precisa estar implantado em algum lugar, e o uso do Terraform significa que podemos aplicar os mesmos fluxos de trabalho do GitOps para criar a camada de controle subjacente ao Kubernetes e aos aplicativos. É uma boa prática útil.
Há uma grande ênfase na aplicação dos conceitos de GitOps às camadas sobre o Kubernetes. Até o momento, existem soluções do tipo GitOps para Istio, Helm, Ksonnet, OpenFaaS e Kubeflow, bem como, por exemplo, para Pulumi, que criam uma camada para o desenvolvimento de aplicativos cloud native.
Kubernetes CI/CD: comparação do GitOps com outras abordagens
Como mencionado, o GitOps é duas coisas:
- Um modelo de operação para Kubernetes e cloud native, descrito acima.
- Um caminho para organizar um ambiente orientado a desenvolvedores para gerenciar aplicativos.
Para muitos, o GitOps é, acima de tudo, um fluxo de trabalho baseado em Git pushes. Nós também gostamos disso. Mas isso não é tudo: agora vamos olhar os pipelines CI/CD.
O GitOps fornece implantação contínua (CD) para Kubernetes
O GitOps oferece um mecanismo de implantação contínua que elimina a necessidade de 'sistemas de gerenciamento de implantações' separados. Todo o trabalho é realizado pelo Kubernetes.
- A atualização do aplicativo requer uma atualização no Git. Esta é uma atualização transacional para o estado desejado. O "desdobramento" é então realizado dentro do cluster pelo próprio Kubernetes com base na descrição atualizada.
- Devido à especificidade do funcionamento do Kubernetes, essas atualizações são convergentes. Isso garante um mecanismo para desdobramentos contínuos, onde todas as atualizações são atômicas.
- Nota: oferece um operador GitOps, que integra Git e Kubernetes e permite a execução de CD por meio da conciliação do estado desejado e atual do cluster.
Sem kubectl e scripts
Deve-se evitar o uso do kubectl para atualizar o cluster, especialmente scripts para agrupar comandos kubectl. Em vez disso, através do pipeline GitOps, o usuário pode atualizar seu cluster Kubernetes via Git.
As vantagens incluem:
- Corretude. Um grupo de atualizações pode ser aplicado, convergido e, finalmente, validado, nos aproximando do objetivo de desdobramento atômico. Em contrapartida, o uso de scripts não oferece garantias de convergência (mais sobre isso abaixo).
- Segurança. Kelsey Hightower: "Restringa o acesso ao cluster Kubernetes às ferramentas de automação e administradores, cuja responsabilidade é depurar ou manter sua operação". Veja também sobre segurança e conformidade técnica, bem como por meio do roubo de credenciais em um script Jenkins descuidado.
- Experiência do usuário. O kubectl expõe a mecânica do modelo de objeto do Kubernetes, que é bastante complexa. Idealmente, os usuários devem interagir com o sistema em um nível mais alto de abstração. Aqui, vou referenciar Kelsey novamente e recomendar a leitura .
A diferença entre CI e CD
GitOps melhora os modelos existentes de CI/CD.
Um servidor CI moderno é uma ferramenta de orquestração. Em particular, é uma ferramenta para orquestrar pipelines CI. Eles incluem build, test, merge to trunk, etc. Os servidores CI automatizam o gerenciamento de pipelines complexos de múltiplas etapas. A tentação comum é criar um script para um conjunto de atualizações do Kubernetes e executá-lo como um elemento do pipeline para empurrar as mudanças para o cluster. De fato, muitos especialistas fazem isso. No entanto, não é otimizado, e aqui está o porquê.
O CI deve ser usado para implementar atualizações no trunk, e o cluster Kubernetes deve se atualizar com base nessas atualizações para gerenciar o CD "internamente". Nós chamamos isso de , ao contrário do modelo push do CI. O CD é parte da orquestração em tempo de execução..
Por que os servidores CI não devem realizar CD por meio de atualizações diretas no Kubernetes?
Não use o servidor CI para orquestrar atualizações diretas no Kubernetes em forma de um conjunto de tarefas CI. Este é um anti-padrão sobre o qual nós em nosso blog.
Vamos voltar a Alice e Bob.
Quais problemas eles enfrentaram? O servidor CI de Bob aplica as mudanças ao cluster, mas se ele falhar durante o processo, Bob não saberá em que estado está (ou deveria estar) o cluster e como corrigi-lo. O mesmo se aplica no caso de sucesso.
Vamos supor que a equipe de Bob criou uma nova imagem e em seguida patchou seus deployments para implantar a imagem (tudo isso a partir do pipeline CI).
Se a imagem for criada corretamente, mas o pipeline falhar, a equipe terá que descobrir:
- A atualização foi implantada?
- Estamos executando uma nova build? Isso levará a efeitos colaterais indesejados — com a possibilidade de ter duas builds da mesma imagem inalterada?
- Devemos esperar pela próxima atualização antes de executar a build?
- O que exatamente deu errado? Quais passos precisam ser repetidos (e quais deles podem ser repetidos com segurança)?
A organização de um fluxo de trabalho baseado em Git não garante que a equipe de Bob não encontrará esses problemas. Eles ainda podem cometer erros com o push do commit, de tags ou de qualquer outro parâmetro; no entanto, essa abordagem ainda está muito mais próxima do explícito tudo ou nada.
Resumindo, aqui está o motivo pelo qual os servidores CI não devem lidar com CD:
- Os scripts de atualização não são sempre determinísticos; é fácil cometer erros com eles.
- Os servidores CI não se convergem para um modelo declarativo de cluster.
- É difícil garantir idempotência. Os usuários precisam entender a semântica profunda do sistema.
- É mais difícil realizar a recuperação após uma falha parcial.
Nota sobre o Helm: se você deseja usar o Helm, recomendamos combiná-lo com um operador GitOps, como o . Isso ajudará a garantir a convergência. O Helm por si só não é nem determinístico nem atômico.
GitOps como a melhor maneira de realizar Continuous Delivery para Kubernetes
A equipe de Alice e Bob implementa GitOps e descobre que é muito mais fácil trabalhar com produtos de software, mantendo um alto desempenho e estabilidade. Vamos finalizar este artigo com ilustrações que mostram como é a nova abordagem deles. Tenha em mente que estamos falando principalmente sobre aplicativos e serviços, mas GitOps pode ser usado para gerenciar toda a plataforma.
Modelo de operação para Kubernetes
Veja o próximo diagrama. Ele representa Git e o repositório de imagens de containers como recursos comuns para dois ciclos de vida orquestrados:
- O pipeline de integração contínua, que lê e grava arquivos no Git e pode atualizar o repositório de imagens de containers.
- O pipeline Runtime GitOps, que combina implantação com gerenciamento e monitoramento. Ele lê e grava arquivos no Git e pode carregar imagens de containers.
Quais são as principais conclusões?
- Separação de problemas: Observe que ambos os pipelines podem trocar dados apenas atualizando o Git ou o repositório de imagens. Em outras palavras, há um firewall entre o CI e o ambiente de runtime. Chamamos isso de "firewall de imutabilidade" (immutability firewall), uma vez que todas as atualizações dos repositórios criam novas versões. Para mais informações sobre este assunto, consulte os slides 72-87 .
- Qualquer servidor CI e Git pode ser utilizado: GitOps funciona com qualquer componente. Você pode continuar usando seus servidores CI e Git favoritos, repositórios de imagens e conjuntos de testes. Quase todas as outras ferramentas para Continuous Delivery no mercado exigem seu próprio servidor CI/Git ou repositório de imagens. Isso pode se tornar um fator limitante no desenvolvimento de cloud native. No caso do GitOps, você pode usar as ferramentas com as quais já está acostumado.
- Eventos como ferramenta de integração: Assim que os dados no Git são atualizados, o Weave Flux (ou operador Weave Cloud) informa ao runtime. Sempre que o Kubernetes aceita um conjunto de mudanças, o Git é atualizado. Isso proporciona um modelo simples de integração para organizar fluxos de trabalho para GitOps, como mostrado abaixo.
Conclusão
GitOps fornece garantias sólidas de atualização necessárias para qualquer ferramenta moderna de CI/CD:
- automação;
- convergência;
- idempotência;
- determinismo.
Isso é importante, pois oferece um modelo de operação para desenvolvedores na área de cloud native.
- Ferramentas tradicionais para gerenciamento e monitoramento de sistemas estão ligadas a equipes de operações que atuam dentro de runbooks. (conjunto de procedimentos e operações de rotina — nota do tradutor), vinculado a uma implantação específica.
- No gerenciamento de sistemas cloud native, as ferramentas de observação são a melhor maneira de avaliar os resultados das implantações, permitindo que a equipe de desenvolvedores reaja rapidamente.
Imagine múltiplos clusters distribuídos por várias nuvens e uma variedade de serviços com suas próprias equipes e planos de implantação. GitOps oferece um modelo de gerenciamento invariável a grande escala para gerenciar toda essa diversidade.
P.S. do tradutor
Confira também em nosso blog:
- «»;
- «»;
- «».
Apenas usuários registrados podem participar da pesquisa. , por favor.
Você sabia sobre GitOps antes dessas duas traduções no Habr?
Sim, sabia
Apenas superficialmente
Não
35 usuários votaram. 10 usuários se abstiveram.
Fonte: habr.com
