GitOps e certificações ArgoCD

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:

1. 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

2. 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.

3. 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:

1. 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

2. Todos os tokens e demais credenciais para acessar o repositório estão no cluster como Secrets, etc.

3. 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.

4. 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