GitOps: comparação entre métodos Pull e Push

Nota do tradutor.: Na comunidade Kubernetes, a tendência chamada GitOps está ganhando popularidade, do que pessoalmente temos certeza, visitando o KubeCon Europe 2019. Este termo foi criado relativamente recentemente, pelo chefe da Weaveworks — Alexis Richardson — e refere-se ao uso de ferramentas familiares para desenvolvedores (principalmente o Git, de onde vem o nome) para resolver problemas de operação. Em particular, fala-se da operação do Kubernetes através do armazenamento de suas configurações no Git e da implantação automática de alterações no cluster. Matthias Jg discute esses dois métodos de implantação neste artigo. No ano passado

(na verdade, oficialmente isso ocorreu em agosto de 2017 — nota do tradutor) apareceu uma nova abordagem para a implantação de aplicações no Kubernetes. Ela é chamada GitOps, e sua base é a ideia de que o rastreamento de versões de implantações é feito em um ambiente seguro de repositório Git. As principais vantagens dessa abordagem são as seguintes

Versionamento de implantações e histórico de alterações:

1. . O estado de todo o cluster é armazenado no repositório Git, e as implantações são atualizadas apenas por meio de commits. Além disso, todas as alterações podem ser rastreadas através do histórico de commits.Reversões usando comandos Git familiares
2. . Simplespermite desfazer alterações nas implantações; estados anteriores estão sempre disponíveis. git reset Controle de acesso pronto
3. . Normalmente, um sistema Git contém muitos dados confidenciais, portanto, a maioria das empresas dá grande importância à sua proteção. Consequentemente, essa proteção se estende também às operações com implantações.Políticas para implantações
4. . A maioria dos sistemas Git originalmente suporta políticas para diferentes ramificações — por exemplo, apenas pull requests podem atualizar o master, e as alterações devem ser revisadas e aprovadas por outro membro da equipe. Assim como no controle de acesso, as mesmas políticas se aplicam às atualizações das implantações.Como você pode ver, o método GitOps possui muitas vantagens. No último ano, dois métodos se destacaram. Um é baseado em push, o outro em pull. Antes de analisá-los, vamos primeiro olhar como as implantações do Kubernetes são tipicamente configuradas.

Métodos de implantação

Nos últimos anos, surgiram várias maneiras e ferramentas para implantações no Kubernetes:

Baseadas em templates nativos do Kubernetes/Kustomize

1. Baseado em modelos nativos do Kubernetes/KustomizeEste é o método mais simples de implantar aplicativos no Kubernetes. O desenvolvedor cria arquivos YAML básicos e os aplica. Para evitar a reescrita constante dos mesmos modelos, foi desenvolvido o Kustomize (que transforma os modelos do Kubernetes em módulos). Nota do tradutor.: O Kustomize foi integrado ao kubectl com o lançamento do Kubernetes 1.14.
2. Charts do Helm. Os Charts do Helm permitem criar conjuntos de modelos, init-containers, sidecars, etc., que são aplicados para implantar aplicativos com opções de configuração mais flexíveis do que na abordagem baseada em modelos. A base desse método são arquivos YAML modelados. O Helm os preenche com vários parâmetros e depois os envia para o Tiller — um componente do cluster que os implanta no cluster e permite executar atualizações e rollbacks. O importante é que, na essência, o Helm simplesmente insere os valores necessários nos modelos e, em seguida, os aplica da mesma forma que na abordagem tradicional (para saber mais sobre como tudo isso funciona e como usá-lo, leia o nosso artigo sobre Helm — nota do tradutor.). Existe uma grande variedade de charts do Helm prontos, cobrindo uma ampla gama de tarefas.
3. Ferramentas alternativas. Existem muitas ferramentas alternativas. Todas elas têm em comum o fato de transformar certos arquivos-modelo em arquivos YAML compreensíveis para o Kubernetes e, em seguida, aplicá-los.

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

Pull & Push

Em uma de suas publicações recentes no blog, apresentei a ferramenta Weave Flux, que permite fazer commit de modelos em um repositório Git e atualizar o deployment após cada commit ou push do contêiner. Minha experiência mostra que essa ferramenta é uma das principais no avanço da abordagem pull, portanto, frequentemente farei referência a ela. Se você quiser saber mais sobre como usá-la, aqui está o link para o artigo.

NB! Todas as vantagens do uso do GitOps são mantidas para ambas as abordagens.

Abordagem baseada em Pull

A abordagem pull baseia-se 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 relacionados do Git e do Docker Registry. Se houver alguma alteração, o estado do cluster é atualizado internamente. Geralmente, acredita-se que esse processo é bastante seguro, pois nenhum cliente externo tem acesso aos direitos de administrador do cluster.

Acesso direto aos sistemas de cabos transpacíficos. Ping mínimo para a China, Japão, Austrália e costa oeste dos EUA.

1. Nenhum cliente externo tem direitos para fazer alterações no cluster, todas as atualizações são aplicadas de dentro.
2. Algumas ferramentas também permitem sincronizar atualizações de Helm charts e vinculá-las ao cluster.
3. O Docker Registry pode ser escaneado em busca de novas versões. Se uma nova imagem aparecer, o repositório Git e a implementação são atualizados para a nova versão.
4. As ferramentas pull podem ser distribuídas em diferentes namespaces com diferentes repositórios Git e direitos de acesso. Isso permite a aplicação de um modelo multitenant. Por exemplo, a equipe A pode usar o namespace A, a equipe B o namespace B, e a equipe de infraestrutura pode usar o namespace global.
5. Geralmente, as ferramentas são bastante leves.
6. Em combinação com ferramentas como o operador Bitnami Sealed Secrets, segredos podem ser armazenados de forma criptografada no repositório Git e extraídos dentro do cluster.
7. Não há conexão com pipelines de CD, uma vez que as implementações ocorrem dentro do cluster.

Desvantagens:

1. Gerenciar segredos das implementações de Helm charts é mais complicado do que os comuns, pois primeiro eles precisam ser gerados na forma de sealed secrets, depois decifrados pelo operador interno e só então se tornam acessíveis para a ferramenta pull. Então, um release pode ser iniciado no Helm com os valores já desdobrados nos segredos. A maneira mais simples é criar um segredo com todos os valores do Helm utilizados para a implementação, decifrá-lo e confirmar no Git.
2. Ao aplicar a abordagem pull, você fica vinculado a ferramentas que operam com pulls. Isso limita a capacidade de personalizar o processo de implantação de deploys no cluster. Por exemplo, trabalhar com Kustomize é complicado, pois ele deve ser executado antes que os templates finais sejam enviados ao Git. Não estou dizendo que não se pode usar ferramentas separadas, mas é mais difícil integrá-las ao processo de implantação.

Abordagem baseada em Push

Na abordagem push, um sistema externo (principalmente pipelines de CD) dispara implantações no cluster após um commit no repositório Git ou em caso de sucesso da execução anterior do pipeline de CI. Nessa abordagem, o sistema tem acesso ao cluster.

Prós:

1. A segurança é determinada pelo repositório Git e pelo pipeline de construção.
2. Implantar charts do Helm é mais simples, já que há suporte para plugins do Helm.
3. Gerenciar segredos é mais fácil, pois os segredos podem ser aplicados em pipelines e também armazenados no Git de forma criptografada (dependendo das preferências do usuário).
4. Ausência de dependência a ferramentas específicas, pois é possível usar qualquer tipo delas.
5. Atualizações de versões de contêineres podem ser iniciadas pelo pipeline de construção.

Desvantagens:

1. Os dados para acesso ao cluster estão dentro do sistema de construção.
2. A atualização de contêineres de deploys ainda é mais fácil de realizar com o processo pull.
3. Forte dependência do sistema de CD, uma vez que os pipelines necessários podem ter sido inicialmente escritos para Gitlab Runners, e depois a equipe decide migrar para Azure DevOps ou Jenkins... e será necessário migrar um grande número de pipelines de construção.

Concluindo: Push ou Pull?

Como geralmente acontece, cada abordagem tem seus prós e contras. Algumas tarefas são mais fáceis de realizar com uma e mais difíceis com outra. No início, eu fazia implementações manualmente, mas depois de encontrar alguns artigos sobre Weave Flux, decidi implementar processos GitOps para todos os projetos. Para os templates básicos, isso foi fácil, mas depois comecei a enfrentar dificuldades ao trabalhar com charts do Helm. Naquela época, o Weave Flux oferecia apenas uma versão inicial do Helm Chart Operator, mas mesmo agora algumas tarefas são mais complicadas devido à necessidade de criar segredos manualmente e aplicá-los. Você pode argumentar que a abordagem pull é muito mais segura, pois as credenciais do cluster não estão disponíveis fora dele, o que aumenta tanto a segurança que vale o esforço extra.

Após refletir um pouco, cheguei à conclusão inesperada de que isso não é verdade. Quando falamos sobre componentes que exigem máxima proteção, essa lista incluirá sistemas de armazenamento de segredos e CI/CD, bem como repositórios Git. As informações dentro deles são bastante vulneráveis e precisam de máxima proteção. Além disso, se alguém invadir seu repositório Git e conseguir fazer push de código para lá, poderá implantar o que desejar (independentemente da abordagem escolhida, seja pull ou push) e se infiltrar nos sistemas do cluster. Assim, os componentes mais importantes que precisam de proteção são o repositório Git e os sistemas CI/CD, e não as credenciais do cluster. Se você tiver boas políticas e medidas de segurança para sistemas desse tipo, e as credenciais do cluster forem extraídas nos pipelines apenas na forma de segredos, a segurança adicional da abordagem pull pode não ser tão valiosa quanto se pensava inicialmente.

Então, se a abordagem pull é mais trabalhosa e não oferece uma vantagem em segurança, não seria mais lógico usar apenas a abordagem push? Mas alguém pode argumentar que na abordagem push você fica muito dependente do sistema de CD e, talvez, seja melhor não fazer assim, para que seja mais fácil realizar migrações no futuro.

Na minha opinião (como sempre), é necessário usar o que melhor se adapta à situação específica ou combinar abordagens. Pessoalmente, uso ambas: Weave Flux para implantações baseadas em pull, que geralmente incluem nossos próprios serviços, e a abordagem push com Helm e plugins, que simplifica a aplicação de charts do Helm ao cluster e permite a criação de segredos sem problemas. Acredito que nunca haverá uma solução única que sirva a todos os casos, pois sempre existem muitas nuances que dependem do contexto específico. Nesse sentido, recomendo fortemente o GitOps — ele facilita muito a vida e aumenta a segurança.

Espero que minha experiência sobre esse tema ajude a determinar qual método é mais adequado para o seu tipo de implantações, e ficarei feliz em saber sua opinião.

P.S. Nota do tradutor

Nos contras do modelo pull, há o ponto de que é difícil colocar manifests renderizados no Git, porém não há desvantagem de que o pipeline de CD no modelo pull vive separado do rollout e, na verdade, se torna um pipeline da categoria Continuous Apply. Portanto, será necessário ainda mais esforço para coletar o status de todas as implantações e de alguma forma fornecer acesso aos logs/status, preferencialmente vinculado ao sistema de CD.

Nesse sentido, o modelo push permite oferecer algumas garantias de rollout, pois a vida do pipeline pode ser igual ao tempo de vida do rollout.

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

1. O modelo pull se adequa para organizar a atualização de componentes do sistema em um grande número de clusters (veja o artigo sobre addon-operator).
2. O modelo push baseado em GitLab CI se adequa bem para o rollout de aplicações usando charts do Helm. Nesse caso, a implantação das aplicações dentro dos pipelines é monitorada por uma ferramenta werf. A propósito, no contexto deste nosso projeto, ouvimos constantemente "GitOps" ao discutir problemas urgentes dos engenheiros de DevOps em nosso stand na KubeCon Europe’19.

P.P.S. do tradutor

Confira também em nosso blog:

• «Dicas e truques do Kubernetes: migrando recursos em execução no cluster para o Helm 2»;
• «Apresentamos a biblioteca kubedog para monitoramento de recursos Kubernetes»;
• «Expandindo e complementando o Kubernetes (visão geral e vídeo da apresentação)»;
• «Dicas para criar workflows personalizados no GitLab CI».

Apenas usuários registrados podem participar da pesquisa. Entre, por favor.

Você utiliza GitOps?

• Sim, abordagem pull

• Sim, push

• Sim, pull + push

• Sim, algo diferente

• Não

30 usuários votaram. 10 usuários se abstiveram.

Fonte: habr.com