Observação. trad.: Na comunidade Kubernetes, uma tendência chamada GitOps está ganhando popularidade óbvia, como vimos pessoalmente, KubeCon Europe 2019. Este termo era relativamente recente pelo chefe da Weaveworks - Alexis Richardson - e significa o uso de ferramentas familiares aos desenvolvedores (principalmente Git, daí o nome) para resolver problemas operacionais. Em particular, estamos falando sobre a operação do Kubernetes armazenando suas configurações no Git e implementando automaticamente as alterações no cluster. Matthias Jg fala sobre duas abordagens para esta implementação neste artigo.
No ano passado, (na verdade, formalmente isso aconteceu em agosto de 2017 - tradução aproximada) Há uma nova abordagem para implantação de aplicativos no Kubernetes. Chama-se GitOps e baseia-se na ideia básica de que as versões de implantação são rastreadas no ambiente seguro de um repositório Git.
As principais vantagens desta abordagem são as seguintes::
- Controle de versão de implantação e histórico de alterações. O estado de todo o cluster é armazenado em um 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 usando o histórico de commits.
- Reversões usando comandos Git familiares... Avião
git resetpermite redefinir alterações nas implantações; estados anteriores estão sempre disponíveis. - Controle de acesso pronto. Normalmente, um sistema Git contém muitos dados confidenciais, por isso a maioria das empresas presta atenção especial à sua proteção. Assim, esta proteção também se aplica a operações com implantações.
- Políticas para implantações. A maioria dos sistemas Git oferece suporte nativo a políticas branch-by-branch – por exemplo, apenas pull requests podem atualizar o master, e as alterações devem ser revisadas e aceitas por outro membro da equipe. Tal como acontece com o controle de acesso, as mesmas políticas se aplicam às atualizações de implantação.
Como você pode ver, o método GitOps traz muitos benefícios. No ano passado, duas abordagens ganharam popularidade especial. Um é baseado em push, o outro é baseado em pull. Antes de examiná-los, vamos primeiro ver como são as implantações típicas do Kubernetes.
Métodos de implantação
Nos últimos anos, o Kubernetes estabeleceu vários métodos e ferramentas para implantações:
- Baseado em modelos nativos do Kubernetes/Kustomize. Esta é 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 necessidade de reescrever constantemente os mesmos modelos, o Kustomize foi desenvolvido (ele transforma modelos do Kubernetes em módulos). Observação. trad.: Kustomize foi integrado ao kubectl com .
- Gráficos do Helm. Os gráficos Helm permitem criar conjuntos de modelos, contêineres de inicialização, sidecars, etc., que são usados para implantar aplicativos com opções de personalização mais flexíveis do que em uma abordagem baseada em modelo. Este método é baseado em arquivos YAML modelados. Helm os preenche com vários parâmetros e depois os envia para o Tiller, um componente de cluster que os implanta no cluster e permite atualizações e reversões. O importante é que o Helm basicamente apenas insere os valores desejados nos templates e depois os aplica da mesma forma que é feito na abordagem tradicional (leia mais sobre como tudo funciona e como você pode usá-lo em nosso - Aproximadamente. trad.). Há uma grande variedade de gráficos Helm prontos para uso, cobrindo uma ampla variedade de tarefas.
- Ferramentas Alternativas. Existem muitas ferramentas alternativas. O que todos eles têm em comum é que transformam alguns arquivos de modelo em arquivos YAML legíveis pelo Kubernetes e depois os usam.
Em nosso trabalho, usamos constantemente gráficos Helm para ferramentas importantes (já que eles já têm muitas coisas prontas, o que facilita muito a vida) e arquivos YAML “puros” do Kubernetes para implantar nossas próprias aplicações.
Puxe empurre
Em uma de minhas postagens recentes no blog, apresentei a ferramenta , que permite confirmar modelos no repositório Git e atualizar a implantação após cada confirmação ou push do contêiner. Minha experiência mostra que esta ferramenta é uma das principais na promoção da abordagem pull, por isso irei me referir a ela com frequência. Se você quiser saber mais sobre como usá-lo, aqui .
NB! Todos os benefícios do uso do GitOps permanecem os mesmos para ambas as abordagens.
Abordagem baseada em pull
A abordagem pull é baseada no fato de que todas as alterações são aplicadas dentro do cluster. Há um operador dentro do cluster que verifica regularmente os repositórios associados do Git e Docker Registry. Se ocorrer alguma alteração neles, o estado do cluster será atualizado internamente. Este processo é geralmente considerado muito seguro, uma vez que nenhum cliente externo tem acesso aos direitos de administrador do cluster.
Prós:
- Nenhum cliente externo tem direitos para fazer alterações no cluster; todas as atualizações são implementadas de dentro.
- Algumas ferramentas também permitem sincronizar atualizações de gráficos do Helm e vinculá-las ao cluster.
- O Docker Registry pode ser verificado em busca de novas versões. Se uma nova imagem estiver disponível, o repositório Git e a implantação serão atualizados para a nova versão.
- As ferramentas pull podem ser distribuídas em diferentes namespaces com diferentes repositórios e permissões Git. Graças a isso, um modelo multilocatário pode ser usado. Por exemplo, a equipe A pode usar o namespace A, a equipe B pode usar o namespace B e a equipe de infraestrutura pode usar o espaço global.
- Via de regra, as ferramentas são muito leves.
- Combinado com ferramentas como operador , os segredos podem ser armazenados criptografados em um repositório Git e recuperados no cluster.
- Não há conexão com pipelines de CD, pois as implantações ocorrem dentro do cluster.
Contras:
- Gerenciar segredos de implantação a partir de gráficos Helm é mais difícil do que os normais, pois primeiro eles precisam ser gerados na forma de, digamos, segredos selados, depois descriptografados por um operador interno e somente depois disso ficam disponíveis para a ferramenta pull. Em seguida, você pode executar a versão no Helm com os valores dos segredos já implantados. A maneira mais fácil é criar um segredo com todos os valores do Helm usados para implantação, descriptografá-lo e enviá-lo ao Git.
- Quando você adota uma abordagem pull, você fica preso às ferramentas pull. Isto limita a capacidade de personalizar o processo de implantação em um cluster. Por exemplo, o Kustomize é complicado pelo fato de que ele deve ser executado antes que os modelos finais sejam confirmados no Git. Não estou dizendo que você não pode usar ferramentas independentes, mas elas são mais difíceis de integrar ao seu processo de implantação.
Abordagem baseada em push
Na abordagem push, um sistema externo (principalmente pipelines de CD) inicia implantações no cluster após um commit no repositório Git ou se o pipeline de CI anterior for bem-sucedido. Nesta abordagem, o sistema tem acesso ao cluster.
Prós:
- A segurança é determinada pelo repositório Git e pelo pipeline de construção.
- A implantação de gráficos do Helm é mais fácil e oferece suporte a plug-ins do Helm.
- Os segredos são mais fáceis de gerenciar porque os segredos podem ser usados em pipelines e também podem ser armazenados criptografados no Git (dependendo das preferências do usuário).
- Não há conexão com uma ferramenta específica, pois qualquer tipo pode ser utilizado.
- As atualizações de versão do contêiner podem ser iniciadas pelo pipeline de build.
Contras:
- Os dados de acesso ao cluster estão dentro do sistema de compilação.
- Atualizar contêineres de implantação ainda é mais fácil com um processo pull.
- Forte dependência do sistema CD, já que os pipelines que precisamos podem ter sido originalmente escritos para Gitlab Runners, e então a equipe decide migrar para Azure DevOps ou Jenkins... e terá que migrar um grande número de pipelines de construção.
Resultados: Empurrar ou Puxar?
Como normalmente 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 começo eu fazia implantações manualmente, mas depois de ler alguns artigos sobre Weave Flux, decidi implementar processos GitOps para todos os projetos. Para modelos básicos isso foi fácil, mas comecei a ter dificuldades com os gráficos do Helm. Na época, o Weave Flux oferecia apenas uma versão rudimentar do Helm Chart Operator, mas mesmo agora algumas tarefas são mais difíceis devido à necessidade de criar segredos manualmente e aplicá-los. Você poderia argumentar que a abordagem pull é muito mais segura porque as credenciais do cluster não são acessíveis fora do cluster, tornando-o tão mais seguro que vale a pena o esforço extra.
Depois de pensar um pouco, cheguei à conclusão inesperada de que não é assim. Se falarmos de componentes que requerem proteção máxima, esta lista incluirá armazenamento secreto, sistemas CI/CD e 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 código para lá, poderá implantar o que quiser (seja pull ou push) e se infiltrar nos sistemas do cluster. Assim, os componentes mais importantes que precisam ser protegidos são o repositório Git e os sistemas CI/CD, e não as credenciais do cluster. Se você tiver políticas e controles de segurança bem configurados para esses tipos de sistemas, e as credenciais do cluster forem extraídas apenas para pipelines como segredos, a segurança adicional de uma abordagem pull pode não ser tão valiosa quanto se pensava originalmente.
Portanto, se a abordagem pull exige mais mão-de-obra e não proporciona um benefício de segurança, não é lógico utilizar apenas a abordagem push? Mas alguém pode argumentar que na abordagem push você está muito preso ao sistema CD e, talvez, seja melhor não fazer isso para que seja mais fácil realizar migrações no futuro.
Na minha opinião (como sempre), você deve usar o que for mais adequado para um determinado caso ou combinação. Pessoalmente, eu uso ambas as 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 facilita a aplicação de gráficos Helm ao cluster e permite criar segredos perfeitamente. Acho que nunca haverá uma solução única adequada para todos os casos, porque sempre há muitas nuances e dependem da aplicação específica. Dito isto, eu recomendo fortemente o GitOps – ele torna a vida muito mais fácil e melhora a segurança.
Espero que minha experiência neste tópico ajude você a decidir qual método é mais adequado para o seu tipo de implantação e ficarei feliz em ouvir sua opinião.
PS Nota do tradutor
A desvantagem do modelo pull é que é difícil colocar manifestos renderizados no Git, mas não há nenhuma desvantagem de que o pipeline de CD no modelo pull viva separadamente da implementação e essencialmente se torne um pipeline de categoria Aplicação Contínua. 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, de preferência com referência ao sistema de CD.
Neste sentido, o modelo push permite-nos fornecer pelo menos algumas garantias de rollout, porque o tempo de vida do pipeline pode ser igual ao tempo de vida do rollout.
Tentamos os dois modelos e chegamos às mesmas conclusões do autor do artigo:
- O modelo pull é adequado para organizar atualizações de componentes do sistema em um grande número de clusters (consulte. ).
- O modelo push baseado no GitLab CI é adequado para implementar aplicativos usando gráficos Helm. Ao mesmo tempo, a implementação de implantações em pipelines é monitorada usando a ferramenta . A propósito, no contexto deste nosso projeto, ouvimos o constante “GitOps” quando discutimos os problemas prementes dos engenheiros DevOps no nosso stand na KubeCon Europe'19.
PPS do tradutor
Leia também em nosso blog:
- «";
- «";
- «";
- «".
Apenas usuários registrados podem participar da pesquisa. por favor
Você está usando GitOps?
-
Sim, abordagem pull
-
Sim, empurre
-
Sim, puxar + empurrar
-
Sim, outra coisa
-
Não
30 usuários votaram. 10 usuários se abstiveram.
Fonte: habr.com