No meu último post falei sobre a evolução do meu laboratório. Neste post, vou tentar explicar da melhor forma possível o que se passa lá dentro, desde o momento em que escrevo o código até ao momento em que entra em “produção”.

Vou utilizar este website como exemplo, mas aplica-se a praticamente tudo o que mantenho, desde os meus websites pessoais, projetos, PiVPN, ou outras aplicações.

Desenvolvimento: funciona no meu PC!

Algumas das coisas, como o website, blog e CV, são desenvolvidas por mim com recurso às mais variadas ferramentas. Não tenho um critério muito específico na escolha, mas, por norma, a escolha é feita com base no que quero aprender. O meu foco está em aprender mais sobre cloud, DevOps e GitOps, testar aplicações novas, pipelines, um pouco de tudo! É aqui que começa a jornada de aprendizagem e que, por norma, resulta em implementações mais sérias dentro da empresa onde trabalho.

O processo é muito semelhante para quase tudo. No caso deste blog, atualmente utilizo HUGO para gerar o website. Não vou entrar em detalhes sobre o que HUGO é e faz, mas de forma muito simples, cada artigo é um documento markdown que é depois utilizado para gerar um website estático.

No caso de outras aplicações, depende. Mas, por norma, desenvolvo sempre com consciência de que nada corre no meu computador e vai ter que correr algures. Normalmente, acaba tudo dentro de imagens Docker.

Controlo de Versão: Git é verdade, Git é vida, GitOps, GitOps, GitOps!

Como não há DevOps nem GitOps sem controlo de versão, para tal, utilizo Git. Para alojar o código, utilizo GitLab se forem repositórios privados e GitHub se forem projetos OpenSource. Sim… Posso ter tudo no mesmo, mas assim estou a privar-me de conhecimento, e esta jornada é toda sobre conhecimento!

Ao utilizar ambos, conheço não só as duas plataformas de forma relativamente bem, como também fico a conhecer as suas ferramentas de CI/CD (GitlabCI, GithubActions e até mesmo TravisCi no caso do PiVPN).

De volta ao tópico! Depois de testada a aplicação, website, script — o que lhe quiserem chamar —, faço commit do código. Cada commit obedece ao estilo de commits de Angular (Aguentem um bocadinho, que já vão perceber porquê!). Submeto o código para o repositório para a “branch” de teste e, depois, mais tarde, para a branch “master”.

E é aqui que acaba o “trabalho manual”. Abro uma cerveja e que trabalhem as máquinas!

Pipelines e Docker: DevOps, um estilo de vida!

Assim que o código “aterra” numa das “branches” definidas, as ferramentas de CI/CD começam a sua dança em perfeita sincronia! GitHub Actions ou GitlaCI são responsáveis por executar estas pipelines, que correm (mais!) testes se necessário.

Fazem a build da imagem do container e, por fim, correm Semantic-release para calcular e versionar o código de forma automática. Para isso, esta ferramenta analisa cada commit e calcula a qual vai ser a próxima versão com base nos mesmos e de acordo com as regras de versionamento semântico. Lembram-se do "Angular Commit style"? Pronto, é por isso que é importante! Por fim, faz tag dos containers e faz o “push” para o registo (GitLab, DockerHub, GitHub)!

Kubernetes, Flux CD, Watchtower

Tudo o que corre na cloud está atualmente a correr num cluster Kubernetes na cloud da Google (GCP).

Utilizo Terraform para criar infraestrutura e FluxCD para gerir tudo o que corre no cluster.

FluxCD monitoriza constantemente o repositório git onde estão as configurações das aplicações a correr no cluster e reverte qualquer alteração que não esteja contemplada nas configurações submetidas. Isto significa que, se fizer kubectl apply AplicaCaoNova.yaml diretamente do meu PC, as alterações vão acabar por ser revertidas minutos depois ao verdadeiro estilo GitOps!

Mas, se fizer commit da configuração e pushar para o repositório sem fazer apply, o FluxCD vai detetar a nova aplicação e fazer apply automaticamente! Yay!!!

Para além disso, o FluxCD monitoriza os registos dos containers e, sempre que sai uma versão nova da aplicação, atualiza as configurações, faz commit e submete para repositório, e faz a atualização da aplicação!

commit 844ec31b7d74838f50b72836d4d1c8c2fc2dd84f
Author: fluxcdbot <fluxcdbot@4s3ti.net>
Date:   Thu Mar 16 20:27:51 2023 +0000

    pivpn/docs:1.4.0

diff --git a/pivpn/03-docs.yml b/pivpn/03-docs.yml
index 78f5c97..495269e 100644
--- a/pivpn/03-docs.yml
+++ b/pivpn/03-docs.yml
@@ -22,7 +22,7 @@ spec:
         node_pool: "cfplayground-global"
       containers:
       - name: pivpn
-        image: pivpn/docs:1.3.0 # {"$imagepolicy": "flux-system:pivpn-docs"}
+        image: pivpn/docs:1.4.0 # {"$imagepolicy": "flux-system:pivpn-docs"}
         imagePullPolicy: Always
         ports:
         - containerPort: 80

Que coisa linda!

O mesmo se aplica a tudo o que esstá alojado nos meus servidores mas que não é desenvolvido por mim desde PrivateBin, Whiteboard, ferramentas de monitorização a helm charts!!

Aquilo que corre no laboratório dentro de casa, o processo é mais simples. Utilizo a tag :latest para tudo, e o Watchtower trata do resto!

Resumindo e Baralhando!

O conteúdo pode não cair aqui muitas vezes, e para dizer a verdade, a qualidade do mesmo pouco me importa. O que de facto me importa mesmo é a qualidade do que acontece por trás deste “simples website” e até digo mais! Bendita Inteligência artificial que me ajudou a escrever, estruturar, corrigir e traduzir este artigo!

Mas o que quero realçar é que, um “simples website”, às vezes é o que basta para distinguir um profissional de um bom profissional! Um “simples website” é o que basta para ganhar conhecimento e entender uma grande panóplia de ferramentas importantes na vida profissional, desde um pouco de código, seja ele que linguagem for, infraestrutura, cloud, ferramentas de CI/CD!

Nos dias de hoje, em que cada vez há mais trabalho para fazer e a demanda por funcionalidades novas é cada vez maior, há cada vez menos tempo para manutenção e cada vez maior necessidade de automatizar tarefas rotineiras! Ninguém quer ter que fazer sempre as mesmas coisas tipo robot, para isso existem máquinas!

Agora, vou só ali beber uma cerveja enquanto as máquinas tratam de meter este artigo no ar! E passar um bocadinho mais de tempo a pensar e questionar-me, “como é que posso fazer ainda melhor e automatizar isto tudo ainda mais?”