Observação. trad.: Após uma publicação recente sobre os métodos pull e push no GitOps, vimos interesse neste modelo em geral, mas havia muito poucas publicações em russo sobre esse tópico (simplesmente não há nenhuma no Habré). Portanto, temos o prazer de chamar sua atenção para a tradução de outro artigo - ainda que há quase um ano! - da Weaveworks, cujo chefe cunhou o termo “GitOps”. O texto explica a essência da abordagem e as principais diferenças em relação às existentes.
Há um ano publicamos . Naquela época, compartilhamos como a equipe da Weaveworks lançou um SaaS inteiramente baseado em Kubernetes e desenvolveu um conjunto de práticas recomendadas prescritivas para implantação, gerenciamento e monitoramento em um ambiente nativo de nuvem.
O artigo acabou se tornando popular. Outras pessoas começaram a falar sobre GitOps e a publicar novas ferramentas para , , , , e assim por diante. Apareceu em nosso site publicações e casos de uso de GitOps. Mas algumas pessoas ainda têm dúvidas. Como o modelo difere do tradicional? e entrega contínua ()? É necessário usar Kubernetes?
Logo percebemos que era necessária uma nova descrição, oferecendo:
- Um grande número de exemplos e histórias;
- Definição específica de GitOps;
- Comparação com entrega contínua tradicional.
Neste artigo tentamos cobrir todos esses tópicos. Ele fornece uma introdução atualizada ao GitOps e uma perspectiva de desenvolvedor e CI/CD. Focamos principalmente no Kubernetes, embora o modelo possa ser generalizado.
Conheça o GitOps
Imagina Alice. Ela administra a Family Insurance, que oferece seguros de saúde, automóveis, residências e viagens para pessoas que estão ocupadas demais para descobrir por si mesmas os meandros dos contratos. Seu negócio começou como um projeto paralelo quando Alice trabalhava em um banco como cientista de dados. Um dia ela percebeu que poderia usar algoritmos de computador avançados para analisar dados e formular pacotes de seguros com mais eficiência. Os investidores financiaram o projeto e agora a sua empresa fatura mais de 20 milhões de dólares por ano e está a crescer rapidamente. Atualmente, emprega 180 pessoas em diversos cargos. Isso inclui uma equipe de tecnologia que desenvolve, mantém o site, banco de dados e analisa a base de clientes. A equipe de 60 pessoas é liderada por Bob, diretor técnico da empresa.
A equipe de Bob implanta sistemas de produção na nuvem. Seus principais aplicativos são executados no GKE, aproveitando o Kubernetes no Google Cloud. Além disso, eles usam diversas ferramentas de dados e análises em seu trabalho.
A Family Insurance não pretendia usar contêineres, mas se deixou levar pelo entusiasmo do Docker. A empresa logo descobriu que o GKE facilitou e facilitou a implantação de clusters para testar novos recursos. Jenkins para CI e Quay foram adicionados para organizar o registro de contêineres, scripts foram escritos para Jenkins que enviavam novos contêineres e configurações para o GKE.
Já passou algum tempo. Alice e Bob ficaram desapontados com o desempenho da abordagem escolhida e seu impacto nos negócios. A introdução de contêineres não melhorou a produtividade tanto quanto a equipe esperava. Às vezes, as implantações falhavam e não estava claro se a culpa era das alterações no código. Também foi difícil rastrear alterações de configuração. Muitas vezes era necessário criar um novo cluster e mover aplicações para ele, pois essa era a maneira mais fácil de eliminar a bagunça que o sistema havia se tornado. Alice temia que a situação piorasse à medida que o aplicativo fosse desenvolvido (além disso, um novo projeto baseado em aprendizado de máquina estava sendo preparado). Bob automatizou a maior parte do trabalho e não entendeu por que o pipeline ainda estava instável, não era bem dimensionado e exigia intervenção manual periodicamente?
Então eles aprenderam sobre GitOps. Essa decisão acabou sendo exatamente o que eles precisavam para seguir em frente com confiança.
Alice e Bob ouvem falar sobre Git, DevOps e infraestrutura como fluxos de trabalho de código há anos. O que há de único no GitOps é que ele traz um conjunto de melhores práticas – tanto definitivas quanto normativas – para implementar essas ideias no contexto do Kubernetes. Este tema incluindo .
Family Insurance decide implementar GitOps. A empresa passou a contar com um modelo de operação automatizado compatível com Kubernetes e que combina velocidade com estabilidadeporque eles:
- constatou que a produtividade da equipe dobrou sem que ninguém enlouquecesse;
- parou de servir scripts. Em vez disso, agora eles podem se concentrar em novos recursos e melhorar os métodos de engenharia – por exemplo, introduzindo implementações canário e melhorando os testes;
- melhoramos o processo de implantação para que ele raramente falhe;
- tive a oportunidade de restaurar implantações após falhas parciais sem intervenção manual;
- comprado usadoоMaior confiança nos sistemas de entrega. Alice e Bob descobriram que poderiam dividir a equipe em equipes de microsserviços trabalhando em paralelo;
- pode fazer de 30 a 50 alterações no projeto todos os dias através dos esforços de cada grupo e experimentar novas técnicas;
- é fácil atrair novos desenvolvedores para o projeto, que têm a oportunidade de lançar atualizações para produção usando solicitações pull em poucas horas;
- passar facilmente na auditoria no âmbito do SOC2 (para conformidade dos provedores de serviços com os requisitos de gerenciamento seguro de dados; leia mais, por exemplo, - Aproximadamente. trad.).
O que aconteceu?
GitOps é duas coisas:
- Modelo operacional para Kubernetes e nativo em nuvem. Ele fornece um conjunto de práticas recomendadas para implantação, gerenciamento e monitoramento de clusters e aplicativos em contêineres. Definição elegante no formulário de :
- O caminho para criar um ambiente de gerenciamento de aplicativos centrado no desenvolvedor. Aplicamos o fluxo de trabalho Git tanto para operações quanto para desenvolvimento. Observe que não se trata apenas de Git push, mas de organizar todo o conjunto de ferramentas CI/CD e UI/UX.
Algumas palavras sobre Git
Se você não estiver familiarizado com sistemas de controle de versão e fluxo de trabalho baseado em Git, é altamente recomendável aprender sobre eles. Trabalhar com ramificações e solicitações pull pode parecer magia negra no início, mas os benefícios valem o esforço. Aqui para começar.
Como funciona o Kubernetes
Em nossa história, Alice e Bob recorreram ao GitOps depois de trabalhar com Kubernetes por um tempo. Na verdade, o GitOps está intimamente relacionado ao Kubernetes – é um modelo operacional para infraestrutura e aplicações baseado em Kubernetes.
O que o Kubernetes oferece aos usuários?
Aqui estão alguns recursos principais:
- No modelo Kubernetes, tudo pode ser descrito de forma declarativa.
- O servidor API Kubernetes toma esta declaração como entrada e tenta continuamente trazer o cluster para o 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, ocorrem alterações no aplicativo e no cluster devido a:
- alterações nas imagens dos contêineres;
- alterações na especificação declarativa;
- erros no ambiente - por exemplo, travamentos de contêineres.
Grandes capacidades de convergência do Kubernetes
Quando um administrador faz alterações na configuração, o orquestrador Kubernetes as aplica ao cluster, desde que seu estado seja não chegará perto da nova configuração. Este modelo funciona para qualquer recurso do Kubernetes e é extensível com definições de recursos personalizados (CRDs). Portanto, as implantações do Kubernetes têm as seguintes propriedades maravilhosas:
- Automação: as atualizações do Kubernetes fornecem um mecanismo para automatizar o processo de aplicação de alterações de maneira elegante e oportuna.
- Convergência: o Kubernetes continuará tentando atualizações até obter sucesso.
- Idempotência: Aplicações repetidas de convergência levam ao mesmo resultado.
- Determinismo: quando os recursos são suficientes, o estado do cluster atualizado depende apenas do estado desejado.
Como funciona o GitOps
Aprendemos o suficiente sobre Kubernetes para explicar como funciona o GitOps.
Voltemos às equipes de microsserviços do Family Insurance. O que eles geralmente têm que fazer? Veja a lista abaixo (se algum item dela parecer estranho ou desconhecido, por favor, não critique e fique conosco). Estes são apenas exemplos de fluxos de trabalho baseados em Jenkins. Existem muitos outros processos ao trabalhar com outras ferramentas.
O principal é que vemos que cada atualização termina com alterações nos arquivos de configuração e repositórios Git. Essas alterações no Git fazem com que o "operador GitOps" atualize o cluster:
1. Processo de trabalho: "Construção Jenkins - branch master".
Lista de tarefas:
- Jenkins envia imagens marcadas para Quay;
- Jenkins envia gráficos de configuração e Helm para o bucket de armazenamento mestre;
- A função de nuvem copia a configuração e os gráficos do bucket de armazenamento mestre para o repositório Git mestre;
- O operador GitOps atualiza o cluster.
2. Compilação do Jenkins - lançamento ou ramificação de hotfix:
- Jenkins envia imagens não marcadas para Quay;
- Jenkins envia gráficos de configuração e Helm para o bucket de armazenamento temporário;
- A função de nuvem copia a configuração e os gráficos do bucket de armazenamento temporário para o repositório Git temporário;
- O operador GitOps atualiza o cluster.
3. Compilação Jenkins - desenvolvimento ou ramificação de recursos:
- Jenkins envia imagens não marcadas para Quay;
- Jenkins envia gráficos de configuração e Helm para o intervalo de armazenamento de desenvolvimento;
- A função de nuvem copia a configuração e os gráficos do bucket de armazenamento de desenvolvimento para o repositório Git de desenvolvimento;
- O operador GitOps atualiza o cluster.
4. Adicionando um novo cliente:
- O gerente ou administrador (LCM/ops) chama Gradle para implantar e configurar inicialmente balanceadores de carga de rede (NLBs);
- LCM/ops confirma uma nova configuração para preparar a implantação para atualizações;
- O operador GitOps atualiza o cluster.
Breve descrição do GitOps
- Descreva o estado desejado de todo o sistema usando especificações declarativas para cada ambiente (em nossa história, a equipe de Bob define toda a configuração do sistema no Git).
- O repositório Git é a única fonte de verdade sobre o estado desejado de todo o sistema.
- Todas as alterações no estado desejado são feitas por meio de commits no Git.
- Todos os parâmetros de cluster desejados também são observáveis no próprio cluster. Desta forma, podemos determinar se eles coincidem (convergem, Convergem) ou diferir (divergir, divergir) estados desejados e observados.
- Se os estados desejado e observado forem diferentes, então:
- Existe um mecanismo de convergência que, mais cedo ou mais tarde, sincroniza automaticamente o alvo e os estados observados. Dentro do cluster, o Kubernetes faz isso.
- O processo começa imediatamente com um alerta de “alteração confirmada”.
- Após algum período de tempo configurável, um alerta “diff” pode ser enviado se os estados forem diferentes.
- Dessa forma, todos os commits no Git causam atualizações verificáveis e idempotentes no cluster.
- Rollback é a convergência para um estado previamente desejado.
- A convergência é definitiva. Sua ocorrência é indicada por:
- Nenhum alerta de diferença por um determinado período de tempo.
- Alerta "convergente" (por exemplo, webhook, evento de writeback do Git).
O que é divergência?
Vamos repetir de novo: todas as propriedades desejadas do cluster devem ser observáveis no próprio cluster.
Alguns exemplos de divergência:
- Alteração no arquivo de configuração devido à fusão de ramificações no Git.
- Uma alteração no arquivo de configuração devido a um commit do Git feito pelo cliente GUI.
- Várias alterações no estado desejado devido ao PR no Git seguidas pela construção da imagem do contêiner e alterações de configuração.
- Uma alteração no estado do cluster devido a um erro, conflito de recursos resultando em "mau comportamento" ou simplesmente desvio aleatório do estado original.
Qual é o mecanismo de convergência?
Alguns exemplos:
- Para contêineres e clusters, o mecanismo de convergência é fornecido pelo Kubernetes.
- O mesmo mecanismo pode ser usado para gerenciar aplicativos e designs baseados em Kubernetes (como Istio e Kubeflow).
- Um mecanismo para gerenciar a interação operacional entre Kubernetes, repositórios de imagens e Git fornece , que faz parte .
- Para máquinas básicas, o mecanismo de convergência deve ser declarativo e autônomo. Pela nossa própria experiência podemos dizer que mais próximo desta definição, mas ainda requer controle humano. Nesse sentido, o GitOps amplia a tradição da Infraestrutura como Código.
GitOps combina Git com o excelente mecanismo de convergência do Kubernetes para fornecer um modelo de exploração.
GitOps nos permite dizer: Somente aqueles sistemas que podem ser descritos e observados podem ser automatizados e controlados.
GitOps destina-se a toda a pilha nativa da nuvem (por exemplo, Terraform, etc.)
GitOps não é apenas Kubernetes. Queremos que todo o sistema seja conduzido de forma declarativa e use convergência. Por todo o sistema queremos dizer uma coleção de ambientes trabalhando com Kubernetes - por exemplo, “dev cluster 1”, “produção”, etc. Cada ambiente inclui máquinas, clusters, aplicativos, bem como interfaces para serviços externos que fornecem dados, monitoramento e etc.
Observe como o Terraform é importante para o problema de inicialização neste caso. O Kubernetes precisa ser implantado em algum lugar, e usar o Terraform significa que podemos aplicar os mesmos fluxos de trabalho do GitOps para criar a camada de controle que sustenta o Kubernetes e os aplicativos. Esta é uma prática recomendada útil.
Há um forte foco na aplicação de conceitos de GitOps às camadas superiores do Kubernetes. No 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 desenvolvimento de aplicações nativas em nuvem.
Kubernetes CI/CD: comparando GitOps com outras abordagens
Conforme afirmado, GitOps é duas coisas:
- O modelo operacional para Kubernetes e nativo da nuvem descrito acima.
- O caminho para um ambiente de gerenciamento de aplicativos centrado no desenvolvedor.
Para muitos, o GitOps é principalmente um fluxo de trabalho baseado em pushes do Git. Nós também gostamos dele. Mas isso não é tudo: vamos agora dar uma olhada nos pipelines de CI/CD.
GitOps permite implantação contínua (CD) para Kubernetes
GitOps oferece um mecanismo de implantação contínua que elimina a necessidade de “sistemas de gerenciamento de implantação” separados. O Kubernetes faz todo o trabalho para você.
- A atualização do aplicativo requer atualização no Git. Esta é uma atualização transacional para o estado desejado. A "implantação" é então feita dentro do cluster pelo próprio Kubernetes com base na descrição atualizada.
- Devido à natureza de funcionamento do Kubernetes, essas atualizações são convergentes. Isto fornece um mecanismo para implantação contínua em que todas as atualizações são atômicas.
- Nota: oferece um operador GitOps que integra Git e Kubernetes e permite que o CD seja executado reconciliando o estado desejado e atual do cluster.
Sem kubectl e scripts
Você deve evitar usar Kubectl para atualizar seu cluster e, especialmente, evitar usar scripts para agrupar comandos kubectl. Em vez disso, com o pipeline GitOps, um usuário pode atualizar seu cluster Kubernetes via Git.
Os benefícios incluem:
- Certo. Um conjunto de atualizações pode ser aplicado, convergido e finalmente validado, aproximando-nos do objetivo da implantação atômica. Por outro lado, o uso de scripts não oferece nenhuma garantia de convergência (mais sobre isso abaixo).
- segurança. Kelsey Hightower: “Restringir o acesso ao seu cluster Kubernetes às ferramentas de automação e aos administradores responsáveis por depurá-lo ou mantê-lo.” Veja também sobre segurança e conformidade com especificações técnicas, bem como roubando credenciais de um script Jenkins escrito descuidadamente.
- Experiência de usuário. Kubectl expõe a mecânica do modelo de objetos Kubernetes, que é bastante complexa. Idealmente, os usuários deveriam interagir com o sistema em um nível mais alto de abstração. Aqui vou me referir novamente a Kelsey e recomendar assistir .
Diferença entre CI e CD
GitOps melhora os modelos CI/CD existentes.
Um servidor de CI moderno é uma ferramenta de orquestração. Em particular, é uma ferramenta para orquestrar pipelines de CI. Isso inclui construção, teste, mesclagem com tronco, etc. Os servidores de CI automatizam o gerenciamento de pipelines complexos de várias etapas. Uma tentação comum é criar um script de um conjunto de atualizações do Kubernetes e executá-lo como parte de um pipeline para enviar alterações ao cluster. Na verdade, é isso que muitos especialistas fazem. No entanto, isso não é o ideal e aqui está o porquê.
O CI deve ser usado para enviar atualizações para o tronco, e o cluster Kubernetes deve mudar a si mesmo com base nessas atualizações para gerenciar o CD internamente. Nós chamamos isso , ao contrário do modelo push de CI. CD faz parte orquestração de tempo de execução.
Por que os servidores CI não devem fazer CDs por meio de atualizações diretas no Kubernetes
Não use um servidor de CI para orquestrar atualizações diretas no Kubernetes como um conjunto de trabalhos de CI. Este é o antipadrão do qual estamos falando em seu blog.
Voltemos a Alice e Bob.
Que problemas eles enfrentaram? O servidor de CI de Bob aplica as alterações ao cluster, mas se ele travar no processo, Bob não saberá em que estado o cluster está (ou deveria estar) ou como corrigi-lo. O mesmo acontece em caso de sucesso.
Vamos supor que a equipe de Bob criou uma nova imagem e, em seguida, corrigiu suas implantações para implantar a imagem (tudo do pipeline de CI).
Se a imagem for construída normalmente, mas o pipeline falhar, a equipe terá que descobrir:
- A atualização foi lançada?
- Vamos lançar uma nova construção? Isso levará a efeitos colaterais desnecessários – com a possibilidade de ter duas construções da mesma imagem imutável?
- Devemos esperar pela próxima atualização antes de executar a compilação?
- O que exatamente deu errado? Quais etapas precisam ser repetidas (e quais são seguras para serem repetidas)?
Estabelecer um fluxo de trabalho baseado em Git não garante que a equipe de Bob não encontrará esses problemas. Eles ainda podem cometer um erro com o commit push, a tag ou algum outro parâmetro; no entanto, esta abordagem ainda está muito mais próxima de uma abordagem explícita de tudo ou nada.
Para resumir, veja por que os servidores de CI não devem lidar com CD:
- Os scripts de atualização nem sempre são determinísticos; É fácil cometer erros neles.
- Os servidores de CI não convergem para o modelo de cluster declarativo.
- É difícil garantir a idempotência. Os usuários devem compreender a semântica profunda do sistema.
- É mais difícil recuperar de uma falha parcial.
Observação sobre o Helm: se você quiser usar o Helm, recomendamos combiná-lo com um operador GitOps como . Isto ajudará a garantir a convergência. O próprio Helm não é determinístico nem atômico.
GitOps como a melhor forma de implementar entrega contínua para Kubernetes
A equipe de Alice e Bob implementa GitOps e descobre que ficou muito mais fácil trabalhar com produtos de software, manter alto desempenho e estabilidade. Vamos terminar este artigo com uma ilustração que mostra como é a nova abordagem. Tenha em mente que estamos falando principalmente de aplicativos e serviços, mas o GitOps pode ser usado para gerenciar uma plataforma inteira.
Modelo operacional para Kubernetes
Observe o diagrama a seguir. Ele apresenta o Git e o repositório de imagens de contêiner como recursos compartilhados para dois ciclos de vida orquestrados:
- Um pipeline de integração contínua que lê e grava arquivos no Git e pode atualizar um repositório de imagens de contêiner.
- Um pipeline Runtime GitOps que combina implantação com gerenciamento e observabilidade. Ele lê e grava arquivos no Git e pode baixar imagens de contêiner.
Quais são as principais conclusões?
- Separação de preocupações: Observe que ambos os pipelines só podem se comunicar atualizando o Git ou o repositório de imagens. Em outras palavras, existe um firewall entre o CI e o ambiente de tempo de execução. Chamamos isso de "firewall da imutabilidade" (firewall de imutabilidade), já que todas as atualizações do repositório criam novas versões. Para mais informações sobre este tópico, consulte os slides 72-87 .
- Você pode usar qualquer servidor CI e Git: GitOps funciona com qualquer componente. Você pode continuar usando seus servidores CI e Git, repositórios de imagens e suítes de testes favoritos. Quase todas as outras ferramentas de entrega contínua no mercado exigem seu próprio servidor CI/Git ou repositório de imagens. Isso pode se tornar um fator limitante no desenvolvimento do nativo da nuvem. Com GitOps, você pode usar ferramentas familiares.
- Eventos como ferramenta de integração: assim que os dados no Git são atualizados, o Weave Flux (ou o operador Weave Cloud) notifica o tempo de execução. Sempre que o Kubernetes aceita um conjunto de alterações, o Git é atualizado. Isso fornece um modelo de integração simples para organizar fluxos de trabalho para GitOps, conforme mostrado abaixo.
Conclusão
GitOps fornece fortes garantias de atualização exigidas por qualquer ferramenta moderna de CI/CD:
- automação;
- convergência;
- idempotência;
- determinismo.
Isto é importante porque oferece um modelo operacional para desenvolvedores nativos da nuvem.
- Ferramentas tradicionais para gerenciamento e monitoramento de sistemas estão associadas a equipes de operações que operam dentro de um runbook (um conjunto de procedimentos e operações de rotina - tradução aproximada), vinculado a uma implantação específica.
- No gerenciamento nativo da nuvem, as ferramentas de observabilidade são a melhor forma de medir os resultados das implantações para que a equipe de desenvolvimento possa responder rapidamente.
Imagine muitos clusters espalhados por diferentes nuvens e muitos serviços com equipes e planos de implantação próprios. GitOps oferece um modelo invariável em escala para gerenciar toda essa abundância.
PS do tradutor
Leia também em nosso blog:
- «";
- «";
- «".
Apenas usuários registrados podem participar da pesquisa. por favor
Você conhecia o GitOps antes dessas duas traduções aparecerem no Habré?
-
Sim, eu sabia de tudo
-
Apenas superficialmente
-
Não
35 usuários votaram. 10 usuários se abstiveram.
Fonte: habr.com