Olá, como vai? Voltando com carga total nos artigos e nada melhor que iniciar com uma série sobre GitOps, onde vou abordar vários tópicos interessantes. Apertem o cinto e venham comigo.
O que é GitOps ?
O conceito de GitOps é bastente simples e consiste em utilizar o Git como a única fonte da verdade relativo estado da nossa infra ou deployments. Apesar de a grande parte dos artigos mostrarem a utilização de GitOps para controlar as cargas de trabalho em um cluster Kunernetes, ele não é exclusivo do mesmo - apesar do Kubernetes possuir algumas características que tornam a implementação desta abordagem mais fácil.
Alguns exemplos do que podemos fazer com GitOps.
- Gerenciar micro vms com Firecracker e Ignite
- Gerenciar nossa infra estrutura nos provedores de cloud, etc
Neste momento, creio que alguns já devem ter pensado:
Hum, eu já faço GitOps, pois tenho os meus manifestos das minhas aplicações criadas utilizando Helm ou usando Kustomize - no caso do Kubernetes -, esses manifestos passam pelo processo de pull request e review e depois o meu sistema de CI/CD excuta o
kubectl apply
e pronto. GitOps !!!
Bem, você já está no caminho certo para adotar GitOps, mas o problema aqui é justamente a última parte do processo. Vamos analisar
Push deployments
Na descrição do processo acima, veja que estamos utilizando o que chamo de push deployment ou seja, a sua ferramenta de CI/CD é que está aplicando os manifestos em um determinado cluster. Funciona, mas temos algumas questões aqui:
O sistema de CI precisa ter acesso ao(s) cluster(s) Kubernetes e devemos tratar de forma adequada a forma como essas credenciais são utilizados a fim de evitar problemas de segurança
Um desenvolvedor com acesso ao(s) cluster(s) poderia aplicar uma atualizar, executando o kubectl localmente e neste situação teríamos um configuration drift - o seu repositório já não reflete o estado atual do cluster.
O cluster é totalmente alheio da origem destes deployments, o que significa por exemplo que caso precise testar uma aplicação em um determinado namespace, mas o seu sistema de CI/CD só aplicar os manifestos quando os commits estiverem na main por exemplo, o cluster não possui formas de saber que essa aplicação deveria estar presente.
Nota: O item 3 pode ser facilmente remediado tendo um job que executa o a aplicação dos manifestos sempre que uma branch seja criada. Mas isso ainda não é GitOps
Pull Deployments
Já quando adotamos GitOps, essa inteligência está no próprio cluster. Por si só o _Kubernetes _não sabe como realizar esta operação, por isso precisamos ter um _Controller _no cluster que adicione essa capacidade. E é isso que as ferramentas como o ArgoCD - e o Flux - fazem. Agora temos o seguinte cenário:
O sistema de CI/CD não precisa mais ter acesso aos clusters, ficando responsável agora por apenas criar nossas imagens Docker e enviar para os respectivos registries
Todos os tokens e demais credenciais para acessar o repositório estão no cluster como Secrets, etc.
Após a instalação do ArgoCD, o cluster agora sabe exatamente qual deve ser o estado corrente baseado em seu repositório, conseguinda assim manter a consistência.
Não há necessidade de realizar
kubectl apply
localmente, mas mesmo que realizemos, o cluster agora poderá realizar rollbacks automaticamente, pois o repositório é a única fonte da verdade sobre o estado do cluster.
Como vimos acima, GitOps é uma forma bastante poderosa de gerenciarmos as aplicações e o próprio cluster. Nos próximos artigos abordarei com mais ênfase outros tópicos interessantes sobre tema.
Certifições ArgoCD
A Coderesh lançou dois cursos e certificação de forma gratuita sobre GitOps com Argo, um terceiro curso GitOps at Edge estará disponível no futuro. Vejamos qual o conteúdo abordado em cada módulo, como são as provas e como se preparar
GitOps Fundamentals
Apresenta os fundamentos do GitOps e aborda:
- O que é GitOps
- ArgoCD basics: Instalação, criação de aplicações, estratégias de sincronização, gerenciamento de segredos, deploy com Helm e Kustomize, progressive delivery, etc
GitOps at Scale
Os temas abordados neste módulo são:
- Gerenciamento de múltiplas aplicações
- Gerenciamento multi cluster
- Generators
- Sync/Phase hooks e Sync Waves
- Sync/Diff strategies
- Sync Windows
Labs
Os dois cursos apresentam diversos laboratório para a aplicação dos tópicos apresentados. Nesta etapa, sugiro que faça todos os exercícios usando um fork do repositório que a Codefresh disponibiliza, assim quando quiser reproduzir os experimentos em outro cluster, todo o código estará atualizado.
No curso de fundamentos, são apresentadas dicas de como resolver os exercícios,já no módulo GitOps at Scale, não são apresentadas dicas para auxiliar o aluno na resolução.
Discord
A Codefresh disponibiliza um servidor onde pode-se trocar experiência sobre GitOps e possui canais focados como argoworkflows, etc. Sugiro fortemente que entre no servidor, pois é uma boa oportunidade de trocar experiência com outros praticantes do GitOps.
As avaliações e dicas
Ao final dos módulos há uma avaliação de múltipla escolha englobando os temas apresentados. Você precisa obter 85% nos testes para passar na avaliação, caso precise refazer o módulo, verifique o Feedback report, pois através dele, poderá verificar quais questões errou.
Para encerrar deixo algumas dicas:
Faça os laboratórios dos módulos em seu cluster local - minikube, k3s, etc.
Preste bastante atenção na parte de Sync Phase/hooks e Sync Waves, pois esses temas apresentam possibilidades interesantes.
Caso tenha problemas em alguma parte. consulte a documentação do ArgoCD
Interaja através dos Discord, a troca de experiência com outras pessoas irá enriquecer ainda mais os seus conhecimentos e a comunidade do ArgoCD é bem ativa.
Como vimos brevemente neste primeiro artigo da série, GitOps é uma forma poderosa de gerenciarmos clusters Kubernetes utilizando o Git como a fonte da verdade.
Bom, é isso aí pessoal. Depois comentem aqui o que acharam do curso. Até o próximo artigo
Top comments (0)