👨‍👨‍👧 👨🏽‍🎨 🍢 GitOps: comparando métodos Pull e Push 🚽 👴🏻 🔑

Nota perev. : Na comunidade Kubernetes, uma tendência chamada GitOps está ganhando popularidade, como vimos pessoalmente visitando o KubeCon Europe 2019. Esse termo foi cunhado há relativamente pouco tempo pelo chefe da Weaveworks - Alexis Richardson - e significa o uso de ferramentas familiares para desenvolvedores (principalmente Git, daí o próprio nome) para resolver problemas operacionais. Em particular, estamos falando sobre explorar o Kubernetes armazenando suas configurações no Git e implementando automaticamente alterações no cluster. Matthias Jg fala sobre duas abordagens para este lançamento neste artigo.

No ano passado (de fato, formalmente isso aconteceu em agosto de 2017 - aproximadamente tradução) , uma nova abordagem para implantar aplicativos no Kubernetes apareceu. Ele se chama GitOps e baseia-se na ideia básica de que o rastreamento da versão de implantação é feito em um ambiente seguro de repositório Git.

As principais vantagens dessa abordagem são as seguintes :

Implementações de versão e histórico de alterações . O estado de todo o cluster é armazenado no repositório Git, e as implantações são atualizadas apenas por confirmações. Além disso, todas as alterações podem ser rastreadas usando o histórico de confirmação.
Propinas usando comandos Git familiares . Uma simples git reset permite descartar alterações na implantação; estados passados estão sempre disponíveis.
Controle de acesso pronto . Normalmente, um sistema Git contém muitos dados confidenciais; portanto, a maioria das empresas presta atenção especial à sua proteção. Assim, essa proteção se estende às operações com implantações.
Políticas para implantações . A maioria dos sistemas Git inicialmente suporta políticas para diferentes ramificações - por exemplo, apenas solicitações pull podem atualizar o mestre e outro membro da equipe deve verificar e aceitar as alterações. Assim como no controle de acesso, as mesmas políticas se aplicam às atualizações de implantação.

Como você pode ver, o método GitOps tem muitas vantagens. No último ano, duas abordagens ganharam popularidade particular. Um é baseado em push, o outro em pull. Antes de olhar para eles, vamos primeiro ver como são as implantações típicas do Kubernetes.

Métodos de implantação

Nos últimos anos, vários métodos e ferramentas de implantação foram estabelecidos no Kubernetes:

Baseado em modelos nativos do Kubernetes / Kustomize . Essa é a maneira mais fácil de implantar aplicativos no Kubernetes. O desenvolvedor cria os arquivos YAML básicos e os aplica. Para se livrar da constante reescrita dos mesmos padrões, o Kustomize foi desenvolvido (transforma os padrões do Kubernetes em módulos). Nota perev. : O Kustomize foi integrado ao kubectl com o lançamento do Kubernetes 1.14 .
Elmo de gráficos . Os gráficos de leme permitem criar conjuntos de modelos, contêineres init, sidecar'ov etc., usados para implantar aplicativos com opções de configuração mais flexíveis do que na abordagem baseada em modelos. Este método é baseado em arquivos YAML de modelo. O Helm os preenche com vários parâmetros e os envia para o Tiller, o componente do cluster que os implanta no cluster e permite atualizações e reversões. O importante é que, de fato, o Helm simplesmente insere os valores necessários nos modelos e os aplica da mesma maneira que é feito na abordagem tradicional (para obter mais detalhes sobre como tudo isso funciona e como você pode usá-lo, leia nosso artigo sobre Helm - aprox. .) . Existe uma grande variedade de gráficos Helm prontos para uso, cobrindo uma ampla gama de tarefas.
Ferramentas alternativas . Existem muitas ferramentas alternativas. Todos eles estão unidos pelo fato de transformar alguns arquivos de modelo em arquivos YAML compatíveis com o Kubernetes e depois aplicá-los.

Em nosso trabalho, constantemente usamos gráficos Helm para ferramentas importantes (já que muitos deles já estão prontos, o que simplifica bastante a vida) e os arquivos YAML "limpos" do Kubernetes para implantar nossos próprios aplicativos.

Puxe e empurre

Em uma das minhas postagens recentes, apresentei a ferramenta Weave Flux , que permite confirmar modelos no repositório Git e atualizar a implantação após cada commit ou push container. Minha experiência mostra que essa ferramenta é uma das principais na promoção da abordagem pull, por isso frequentemente vou me referir a ela. Se você quiser saber mais sobre como usá-lo, aqui está um link para o artigo .

NB! Todos os benefícios do uso de GitOps são mantidos para ambas as abordagens.

Abordagem Baseada em Pull

A abordagem pull é baseada no fato de que todas as alterações são aplicadas de dentro do cluster. Dentro do cluster, há um operador que verifica regularmente os repositórios Git e Docker Registry associados. Se ocorrer alguma alteração neles, o estado do cluster é atualizado internamente. Geralmente, considera-se que esse processo é muito seguro, pois nenhum cliente externo tem acesso aos direitos de administrador do cluster.

Prós:

Nenhum cliente externo tem o direito de fazer alterações no cluster; todas as atualizações são roladas por dentro.
Algumas ferramentas também permitem sincronizar atualizações nos gráficos do Helm e vinculá-las a um cluster.
O Docker Registry pode ser verificado para novas versões. Se uma nova imagem aparecer, o repositório e a implantação do Git serão atualizados para a nova versão.
As ferramentas pull podem ser distribuídas por diferentes namespaces com diferentes repositórios e permissões do Git. Graças a isso, é possível usar o modelo multitenant. Por exemplo, a equipe A pode usar o espaço de nomes A, a equipe B pode usar o espaço de nomes B e uma equipe de infraestrutura pode usar o espaço global.
Como regra, as ferramentas são muito leves.
Combinado com ferramentas como a declaração Bitnami Sealed Secrets , os segredos podem ser armazenados criptografados no repositório Git e recuperados dentro do cluster.
Não há comunicação com os pipelines de CD, pois as implantações ocorrem dentro do cluster.

Contras :

O gerenciamento de segredos de implantação a partir dos gráficos Helm é mais complicado do que o habitual, pois você primeiro precisa gerá-los em, digamos, segredos selados, depois descriptografá-los com um operador interno e somente depois eles ficam disponíveis para a ferramenta pull. Em seguida, você pode iniciar a liberação no Helm com valores em segredos já implantados. A maneira mais fácil é criar um segredo com todos os valores do Helm usados para implantação, descriptografá-lo e confirmar no Git.
Usando a abordagem pull, você se vê vinculado a ferramentas que operam em pull. Isso limita a capacidade de personalizar o processo de implantação da implantação no cluster. Por exemplo, trabalhar com o Kustomize é complicado pelo fato de que ele deve ser executado antes que os modelos finais cheguem ao Git. Não estou dizendo que você não pode usar ferramentas individuais, mas elas são mais difíceis de integrar ao processo de implantação.

Abordagem Baseada em Push

Na abordagem push, um sistema externo (principalmente pipelines de CD) começa a implantar no cluster após confirmar o repositório Git ou em caso de execução bem-sucedida do pipeline de IC anterior. Nesta abordagem, o sistema tem acesso ao cluster.

Prós :

A segurança é determinada pelo repositório Git e compila o pipeline.
A implantação de gráficos do Helm é mais fácil; há suporte para plug-ins do Helm.
Os segredos são mais fáceis de gerenciar, porque os segredos podem ser usados em pipelines e também armazenados no Git de forma criptografada (dependendo das preferências do usuário).
Falta de ligação a uma ferramenta específica, pois qualquer um de seus tipos pode ser usado.
As atualizações da versão do contêiner podem ser acionadas pelo pipeline de montagem.

Contras :

Os dados para acessar o cluster estão localizados dentro do sistema de construção.
A atualização de contêineres de implantação ainda é mais fácil com o processo pull.
É muito dependente do sistema do CD, porque os pipelines de que precisamos provavelmente foram originalmente criados para os Gitlab Runners e, em seguida, a equipe decide mudar para o Azure DevOps ou Jenkins ... e você terá que migrar um grande número de pipelines de compilação.

Conclusão: Empurre ou Puxe?

Como sempre, cada abordagem tem seus prós e contras. Algumas tarefas são mais fáceis de realizar com uma e mais difíceis com a outra. No começo, passei as implantações manualmente, mas depois que deparei com vários artigos sobre o Weave Flux, decidi implementar os processos GitOps para todos os projetos. Para modelos básicos, isso acabou sendo fácil, mas então comecei a encontrar dificuldades em trabalhar com os gráficos do Helm. Naquela época, o Weave Flux oferecia apenas uma versão rudimentar do Helm Chart Operator, mas mesmo agora algumas tarefas são mais complicadas devido à necessidade de criar manualmente segredos e aplicá-los. Você pode dizer que a abordagem pull é muito mais segura, pois as credenciais do cluster não estão disponíveis fora dela, e isso aumenta a segurança tanto que custa um esforço extra.

Depois de pensar um pouco, cheguei à conclusão inesperada de que não é assim. Se falarmos sobre componentes que exigem proteção máxima, essa lista incluirá armazenamento de segredos e sistemas de CI / CD, repositórios Git. As informações contidas neles são muito vulneráveis e precisam de proteção máxima. Além disso, se alguém entrar no seu repositório Git e puder enviar o código por lá, ele poderá implantar tudo o que quiser (independentemente da abordagem escolhida, será puxar ou empurrar) e se infiltrar nos sistemas de cluster. Portanto, os componentes mais importantes que exigem proteção são o repositório Git e os sistemas de CI / CD, não as credenciais do cluster. Se você tiver políticas e medidas de segurança bem ajustadas para sistemas desse tipo, e as credenciais do cluster forem recuperadas nos pipes apenas como segredos, a segurança adicional da abordagem pull poderá não ser tão valiosa quanto o pretendido originalmente.

Portanto, se a abordagem pull é mais demorada e não oferece ganho de segurança, não é lógico usar apenas a abordagem push? Mas alguém pode dizer que, na abordagem por push, você está muito ligado ao sistema de CD e, talvez, seja melhor não fazer isso para facilitar as migrações no futuro.

Na minha opinião (como sempre), você deve usar o que é mais adequado para um caso ou combinação em particular. Pessoalmente, uso as duas abordagens: Weave Flux para implantações baseadas em pull que incluem principalmente nossos próprios serviços e uma abordagem push com Helm e plug-ins que simplificam a aplicação dos gráficos Helm ao cluster e permitem criar segredos facilmente. Acho que nunca haverá uma solução única adequada para todos os casos, porque sempre há muitas nuances e elas dependem da aplicação específica. Ao mesmo tempo, recomendo o GitOps - simplifica bastante a vida e melhora a segurança.

Espero que minha experiência neste tópico ajude a determinar qual método é mais adequado para seu tipo de implantação, e ficarei feliz em saber sua opinião.

Nota do PS do tradutor

Nas desvantagens do modelo pull, há um ponto sobre o fato de que é difícil colocar manifestos renderizados no Git, no entanto, não há menos que o pipeline de CD no modelo pull viva separadamente do rollout e, de fato, se torne um pipeline da categoria Aplicação Contínua . Portanto, serão necessários ainda mais esforços para coletar seu status de todas as implantações e, de alguma forma, dar acesso aos logs / status e, de preferência, com referência ao sistema de CD.

Nesse sentido, o modelo push permite que você dê pelo menos alguma implementação de garantia, porque a vida útil do pipeline pode ser igual à vida útil da implementação.

Testamos os dois modelos e chegamos às mesmas conclusões que o autor do artigo:

O modelo pull é adequado para nós para organizar atualizações de componentes do sistema em um grande número de clusters (consulte o artigo sobre addon-operator ).
O modelo push baseado em IC do GitLab é adequado para implantar aplicativos usando gráficos Helm. Nesta implementação, o deploy'ov dentro dos pipelines é monitorado usando a ferramenta werf . A propósito, no contexto de nosso projeto, ouvimos o constante "GitOps" quando discutimos os problemas prementes dos engenheiros de DevOps em nosso estande na KubeCon Europe'19.

GitOps: comparando métodos Pull e Push