🔗 💒 👩‍👩‍👦‍👦 O que é GitOps? 💃 🦄 👠

Nota perev. : Após a recente publicação de material sobre métodos pull e push no GitOps, vimos interesse nesse modelo como um todo; no entanto, havia muito poucas publicações em russo sobre esse tópico (elas simplesmente não estão no hub). Portanto, temos o prazer de chamar a atenção para a tradução de outro artigo - há quase um ano! - da empresa Weaveworks, cujo chefe cunhou o termo "GitOps". O texto explica a essência da abordagem e as principais diferenças das existentes.

Há um ano, publicamos uma introdução ao GitOps . Depois, conversamos sobre como a equipe do Weaveworks lançou o SaaS baseado em Kubernetes e desenvolveu um conjunto de práticas recomendadas prescritivas para implantar, gerenciar e monitorar em um ambiente nativo da nuvem.

O artigo acabou sendo popular. Outras pessoas começaram a falar sobre GitOps, começaram a publicar novas ferramentas para git push , desenvolvimento , segredos , funções , integração contínua etc. Um grande número de publicações e casos de uso do GitOps apareceu em nosso site. Mas algumas pessoas ainda têm dúvidas. Como o modelo difere da infraestrutura tradicional como código e entrega contínua? É obrigatório usar o Kubernetes?

Logo percebemos que era necessária uma nova descrição, oferecendo:

Um grande número de exemplos e histórias;
A definição específica de GitOps;
Comparação com entrega contínua tradicional.

Neste artigo, tentamos abordar todos esses tópicos. Nele, você encontrará uma introdução atualizada ao GitOps e uma visão do lado dos desenvolvedores e do CI / CD. Nós nos concentramos principalmente no Kubernetes, embora o modelo possa ser generalizado.

Conheça GitOps

Imagine Alice. Ela administra a Family Insurance, uma empresa que oferece apólices de seguro de saúde, carro, imóveis e viagens para pessoas que estão ocupadas demais para entender as nuances de seus contratos por conta própria. Seu negócio começou como um projeto paralelo quando Alice trabalhou no banco como cientista de dados. Uma vez que ela percebeu que poderia usar algoritmos avançados de computador para analisar com mais eficiência os dados e formar pacotes de seguros. Os investidores financiaram o projeto e agora sua empresa fatura mais de US $ 20 milhões por ano e está crescendo rapidamente. Atualmente, 180 pessoas trabalham em vários cargos. Entre eles, uma equipe de tecnologia que desenvolve, mantém um site, um banco de dados e analisa a base de clientes. Uma equipe de 60 pessoas é liderada por Bob, diretor técnico da empresa.

A equipe de Bob está implantando 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 várias ferramentas para trabalhar com dados e análises em seu trabalho.

O Family Insurance não usaria contêineres, mas estava infectado com entusiasmo por Docker. Em breve, os especialistas da empresa descobriram que o GKE facilita e facilita a implantação de clusters para testar novos recursos. Foram adicionados Jenkins para CI e Quay para organizar o registro de contêiner, foram escritos scripts para Jenkins que enviam ou novos contêineres e configurações no GKE.

Algum tempo se passou. 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 aumentou a produtividade tanto quanto a equipe esperava. Às vezes, as implantações eram interrompidas e não era claro se as alterações no código eram responsáveis. Também se mostrou difícil rastrear alterações nas configurações. Muitas vezes, era necessário criar um novo cluster e mover aplicativos para ele, pois era a maneira mais fácil de eliminar 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 no aprendizado de máquina estava sendo produzido). Bob automatizou a maior parte do trabalho e não entendeu por que o pipeline ainda é instável, não escala bem e requer intervenção manual de tempos em tempos?

Então eles aprenderam sobre o GitOps. Essa decisão acabou sendo exatamente o que eles precisavam para avançar com confiança.

Alice e Bob ouviram falar sobre fluxos de trabalho baseados em Git, DevOps e infraestrutura como código há anos. A singularidade do GitOps é que ele traz várias práticas recomendadas - categóricas e normativas - para implementar essas idéias no contexto do Kubernetes. Este tópico foi levantado repetidamente , inclusive no blog do Weaveworks .

O Seguro de Família decide implementar GitOps. A empresa agora possui um modelo operacional automatizado compatível com o Kubernetes que combina velocidade com estabilidade , pois:

descobriu que a equipe dobrou a produtividade e ninguém está ficando louco;
parou de executar scripts. Em vez disso, agora eles podem se concentrar em novos recursos e melhorar os métodos de engenharia - por exemplo, introduzir lançamentos de canários e melhorar os testes;
processo de implantação aprimorado - agora raramente quebra;
teve a oportunidade de recuperar implantações após falhas parciais sem intervenção manual;
ganhou maior confiança nos sistemas de suprimentos. Alice e Bob descobriram que a equipe pode ser dividida em grupos que trabalham em microsserviços e trabalham em paralelo;
pode fazer de 30 a 50 mudanças no projeto todos os dias pelos esforços de cada grupo e tentar novas técnicas;
eles são facilmente atraídos para o projeto por novos desenvolvedores que têm a capacidade de lançar atualizações na produção usando solicitações pull em poucas horas;
auditado facilmente no SOC2 (para conformidade dos provedores de serviços com requisitos para gerenciamento seguro de dados; leia mais, por exemplo, aqui - trad. aprox.) .

O que aconteceu

GitOps são duas coisas:

Modelo de operação para Kubernetes e nativo da nuvem. Ele fornece um conjunto de práticas recomendadas para implantar, gerenciar e monitorar clusters e aplicativos em contêiner. Definição elegante em um único slide de Luis Faceira :
O caminho para criar um ambiente orientado ao desenvolvedor para gerenciar aplicativos. Aplicamos o fluxo de trabalho do Git à exploração e desenvolvimento. Observe que não se trata apenas de push do Git, mas de organizar todo o conjunto de ferramentas de CI / CD e UI / UX.

Algumas palavras sobre o Git

Se você não estiver familiarizado com os sistemas de controle de versão e o fluxo de trabalho baseado em Git, é altamente recomendável que você os estude. A princípio, trabalhar com solicitações de ramificações e pull pode parecer magia negra, mas os profissionais valem o esforço. Aqui está um bom artigo para você começar.

Como o Kubernetes funciona

Em nossa história, Alice e Bob se voltaram para o GitOps depois de trabalhar com o Kubernetes por um tempo. De fato, o GitOps está intimamente ligado ao Kubernetes - é um modelo operacional para a infraestrutura e aplicativos baseados no Kubernetes.

O que o Kubernetes oferece aos usuários?

Aqui estão alguns dos principais recursos:

No modelo Kubernetes, tudo pode ser descrito de forma declarativa.
O servidor da API do Kubernetes aceita essa declaração como entrada e, em seguida, tenta constantemente 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, as alterações no aplicativo e no cluster devem-se a:
- alterações nas imagens do contêiner;
- alterações na especificação declarativa;
- erros no ambiente - por exemplo, travamentos de contêineres.

As grandes habilidades de convergência de 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 Kubernetes e se estende às Definições de Recursos Customizados (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 das alterações corretamente e em tempo hábil.
Convergência : o Kubernetes continuará tentando as atualizações até o sucesso.
Idempotência : aplicações repetidas de convergência produzem o mesmo resultado.
Determinismo : com recursos suficientes, o estado do cluster atualizado depende apenas do estado desejado.

Como o GitOps funciona

Nós aprendemos o suficiente sobre o Kubernetes para explicar como o GitOps funciona.

Vamos voltar às equipes de Seguros familiares relacionadas aos microsserviços. O que eles geralmente têm que fazer? Veja a lista abaixo (se algum ponto parecer estranho ou desconhecido - adie as críticas 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 nos repositórios Git. Essas alterações no Git fazem com que a "instrução GitOps" atualize o cluster:

1. Fluxo de trabalho: " Jenkins Build - filial principal ".
A lista de tarefas:

Jenkins envia imagens marcadas no Quay;
Jenkins envia gráficos de configuração e Helm para o bucket de armazenamento principal;
A função cloud copia a configuração e os gráficos do bucket de armazenamento principal para o repositório master git;
A instrução GitOps atualiza o cluster.

2. Jenkins build - release ou hotfix branch :

Jenkins envia imagens não identificadas no Quay;
Jenkins envia os gráficos de configuração e Helm para o balde de armazenamento temporário;
A função de nuvem copia a configuração e os gráficos do bucket do armazenamento temporário para o armazenamento temporário do repositório Git;
A instrução GitOps atualiza o cluster.

3. Jenkins build - ramo de desenvolvimento ou recurso :

Jenkins envia imagens não identificadas no Quay;
Jenkins envia os gráficos de configuração e Helm para o depósito de desenvolvimento;
A função de nuvem copia a configuração e os gráficos do depósito de armazenamento de desenvolvimento para o repositório git de desenvolvimento;
A instrução GitOps atualiza o cluster.

4. Adicionando um novo cliente :

Um gerente ou administrador (LCM / ops) chama a Gradle para implantar e configurar inicialmente os balanceadores de carga de rede (NLBs);
LCM / ops confirma uma nova configuração para preparar a implantação para atualizações;
A instrução 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 nosso histórico, 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 através de confirmações no Git.
- Todos os parâmetros de cluster desejados também são observáveis no próprio cluster. Assim, podemos determinar se os estados desejados e observados coincidem (convergem, convergem ) ou diferem ( divergem , divergem ).
Se os estados desejados e observados forem diferentes, então:
- Existe um mecanismo de convergência que, mais cedo ou mais tarde, sincroniza automaticamente o destino e os estados observados. Dentro do cluster, o Kubernetes faz isso.
- O processo começa imediatamente com uma notificação de "alteração confirmada".
- Após um período de tempo configurável, um alerta de diferença pode ser enviado se os estados forem diferentes.
Portanto, todas as confirmações no Git acionam atualizações verificáveis e idempotentes no cluster.
- A reversão é uma convergência para um estado anteriormente desejado.
A convergência é final. Sobre o seu início, testemunhe:
- Falta de alertas "diff" por um determinado período de tempo.
- Um alerta convergente (por exemplo, webhook, evento de write-back do Git).

O que é divergência?

Repetimos novamente: todas as propriedades desejadas do cluster devem ser observáveis no próprio cluster .

Alguns exemplos de divergência:

Mudança no arquivo de configuração devido à mesclagem de ramificações no Git.
Uma alteração no arquivo de configuração devido a uma confirmação no Git feita pelo cliente da GUI.
Várias alterações no estado desejado devido ao PR no Git com a montagem subsequente da imagem do contêiner e alterações na configuração.
Alteração do estado do cluster devido a um erro, conflito de recursos levando a "mau comportamento" ou apenas um desvio acidental do estado original.

O que é um mecanismo de convergência?

Alguns exemplos:

Para contêineres e clusters, o mecanismo de convergência fornece o Kubernetes.
O mesmo mecanismo pode ser usado para gerenciar aplicativos e designs baseados no Kubernetes (por exemplo, Istio e Kubeflow).
O mecanismo para gerenciar a interação de trabalho entre o Kubernetes, os repositórios de imagens e o Git é fornecido pelo operador Weave Flux GitOps , que faz parte do Weave Cloud .
Para máquinas de base, o mecanismo de convergência deve ser declarativo e autônomo. De nossa própria experiência, podemos dizer que o Terraform está mais próximo dessa definição, mas ainda requer controle humano. Nesse sentido, o GitOps estende a tradição da infraestrutura como código.

O GitOps combina o Git com o excelente mecanismo de convergência do Kubernetes, oferecendo um modelo para operação.

O GitOps nos permite declarar que apenas os sistemas que podem ser descritos e observados podem ser automatizados e controlados .

GitOps é para toda a pilha nativa da nuvem (por exemplo, Terraform etc.)

GitOps não é apenas Kubernetes. Queremos que todo o sistema seja gerenciado declarativamente e use convergência. Por um sistema inteiro, queremos dizer um conjunto de ambientes que trabalham com o 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 neste caso para o problema de inicialização. O Kubernetes precisa ser implantado em algum lugar, e o uso do Terraform significa que podemos usar os mesmos fluxos de trabalho do GitOps para criar a camada de controle subjacente ao Kubernetes e aplicativos. Essa é uma boa prática recomendada.

É dada muita atenção à aplicação dos conceitos do GitOps a camadas sobre o Kubernetes. Atualmente, 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 nativos da nuvem.

Kubernetes CI / CD: comparando GitOps com outras abordagens

Como afirmado, GitOps são duas coisas:

O modelo operacional para o Kubernetes e o nativo da nuvem descrito acima.
O caminho para organizar um ambiente de gerenciamento de aplicativos centrado no desenvolvedor.

Para muitos, o GitOps é principalmente um fluxo de trabalho baseado em push do Git. Nós também gostamos dele. Mas isso não é tudo: vamos agora olhar para os pipelines de CI / CD.

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çã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” é realizada dentro do cluster pelo próprio Kubernetes com base em uma descrição atualizada.
Devido às especificidades do Kubernetes, essas atualizações são convergentes. Isso fornece um mecanismo para implantação contínua em que todas as atualizações são atômicas.
Nota: O Weave Cloud oferece um operador GitOps que integra o Git e o Kubernetes e permite executar um CD, correspondendo ao estado desejado e atual do cluster.

Sem kubectl e scripts

Evite usar o Kubectl para atualizar o cluster e, especialmente, scripts para agrupar comandos do kubectl. Em vez disso, com um pipeline GitOps, um usuário pode atualizar seu cluster Kubernetes através do Git.

Os benefícios incluem:

Correção . Um grupo de atualizações pode ser aplicado, convergido e finalmente validado, o que nos aproxima do objetivo da implantação atômica. Pelo contrário, o uso de scripts não oferece nenhuma garantia de convergência (mais sobre isso abaixo).
Segurança Citando Kelsey Hightower: “Limite o acesso ao cluster Kubernetes a ferramentas de automação e administradores responsáveis pela depuração ou manutenção do mesmo”. Veja também minha publicação sobre segurança e conformidade, bem como um artigo sobre hackers da Homebrew roubando credenciais de um script de Jenkins descuidadamente escrito.
Experiência do usuário . O Kubectl expõe a mecânica do modelo de objetos Kubernetes, que é bastante complexo. Idealmente, os usuários devem interagir com o sistema em um nível mais alto de abstração. Aqui, refiro-me novamente a Kelsey e recomendo examinar esse currículo .

A diferença entre IC e CD

O GitOps aprimora os modelos de CI / CD existentes.

O servidor de CI moderno é um instrumento para orquestração. Em particular, é um instrumento para orquestrar pipelines de IC. Eles incluem compilação, teste, mesclagem ao tronco, etc. Os servidores de CI automatizam o gerenciamento de pipelines complexos de várias etapas. Uma tentação comum é criar um script para o conjunto de atualizações do Kubernetes e executá-lo como um elemento de pipeline para enviar alterações ao cluster. De fato, é isso que muitos especialistas fazem. No entanto, isso não é ideal, e aqui está o porquê.

O IC deve ser usado para fazer atualizações no tronco, e o cluster Kubernetes deve mudar automaticamente com base nessas atualizações para gerenciar o CD "internamente". Chamamos isso de modelo pull para o CD , diferentemente do modelo push de IC. O CD faz parte de uma orquestração de tempo de execução .

Por que os servidores de CI não devem criar CDs por meio de atualizações diretas no Kubernetes

Não use o servidor de IC para orquestrar atualizações diretas no Kubernetes como um conjunto de tarefas de IC. Esse é o antipadrão que já falamos em nosso blog.

Vamos voltar para Alice e Bob.

Que problemas eles encontraram? O servidor de IC de Bob aplica as alterações ao cluster, mas se ele cair no processo, Bob não saberá em que estado o cluster está (ou deveria estar) e como corrigi-lo. O mesmo vale se for bem-sucedido.

Vamos supor que a equipe de Bob montou uma nova imagem e depois corrigiu suas implantações para implantar a imagem (todas do pipeline de IC).

Se a imagem for criada normalmente, mas o pipeline cair, a equipe precisará descobrir:

A atualização foi implantada?
Estamos iniciando uma nova compilação? — ?
, ?
? ( )?

Git' , . - push' , - ; --.

, CI- CD:

; .
CI- .
. .
.

Helm'e: Helm, GitOps-, Flux-Helm . . Helm , .

GitOps Continuous Delivery Kubernetes

GitOps , , . , , . , , GitOps .

Kubernetes

. Git :

, Git .
Runtime GitOps, . Git .

?

: , , Git . , CI runtime-. « » (immutability firewall) , . 72-87 .
CI- Git- : GitOps . CI- Git-, . Continuous Delivery CI-/Git- . cloud native. GitOps .
: Git , Weave Flux ( Weave Cloud) runtime. , Kubernetes , Git . GitOps, .

Conclusão

GitOps , CI/CD:

;
;
;
.

, cloud native.

, runbook' ( — . .) , deployment'.
cloud native- , .

, . GitOps - .

O que é GitOps?