GitOps e certificações ArgoCD

Marc Pires — Sun, 09 Oct 2022 11:23:47 +0000

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

Automatic CHANGELOG with git

Marc Pires — Tue, 06 Mar 2018 12:16:24 +0000

Automatic CHANGELOG with git

This is a simple tip of how you can generate automatic changelogs for your projects using git.

Know your hooks

For Git novices that never dared to tap into the .git folder, there resides the hooks folder. Inside this folder, you'll find a series of scripts can be activated and will run on git actions, let's take a look.

Content of .git/hooks subfolder

As you see for the image above, there are bunch of hooks we can activate. Here some:

pre-push : This will always run, as its name implies, before a push. You can use this hook for example, to run all your tests before you send code to a remote.

pre-commit : Runs before a commit

The CHANGELOG hook

Know, let's go straight to the point.

First create a post-commit file in the .git/hooks folder. The contents of my post-commit file is as follows.

The script is very simple, I do a git log with 3 parameters:

- -no-pager : Do not pipe Git output into a pager (less)

- -no-merges: Does not print commits with more than one parent (same as max-parents=1)

- -format : Pretty print the commit content in a specific format, possible values are ‘oneline’, ‘short’, ‘medium’, ‘full’, ‘fuller’, ‘email’, ‘raw’, ‘format:’ and ‘tformat:’

The log output is then redirected do the CHANGELOG.md file on the project root folder.

After saving the file, just do a chmod +x .git/hooks/post-commit and that's it. Now, always after the commit, your CHANGELOG.md will be updated.

I hope you find it useful and does not forget to comment. 'till next tip.

DEV Community: Marc Pires