Olá, pessoal.

Este é o primeiro post aqui no meu blog. A intenção aqui é postar conteúdo técnico, aprendizados, dicas de estudo, ferramentas open-source legais e divulgar meus trabalhos.

Pra começar, vamos falar como esse blog foi estruturado.

O Blog

Inicialmente, pensei em criar um blog usando o Jekyll, uma ferramenta em Ruby que permite gerar um blog estático com artigos definidos em arquivos Markdown. Também tinha achado muito interessanto o Docusaurus, uma alternativa mais moderna ao Jekyll, construída com React.

Apesar de ter gostado das opções disponíveis, eu queria estabelecer um desafio técnico: construir um blog eu mesmo, e então hospedá-lo no meu cluster Kubernetes pessoal.

Daí nasceu a ideia desse projeto. O blog é divido em um frontend estático com Next.JS e uma API feita em NEST. O conteúdo estático do blog (incluindo o arquivo markdown dos posts) é armazenado em um bucket S3.

Pude aproveitar também para construir o CI/CD do projeto usando o GitHub Actions, que publica a imagem em um registry privado do GitHub. O registry por sua vez é observado pelo ArgoCD Image Updater, que faz a atualização da tag da imagem no Deployment do Kubernetes (via Kustomize) toda vez que uma nova imagem é publicada. Prático? Sim. Overengineering? Talvez, mas a intenção é justamente obter a experiência completa, que definitivamente me garantiu muito aprendizado sobre cada uma das ferramentas utilizadas, além de uma grande satisfação quando a aplicação está de pé e você finalmente escreve o seu primeiro post! :)

No quesito estético, o visual do site é inspirado no tema Chirpy, do próprio Jekyll, e também no minimalismo do blog do Mitchell Hashimoto (Co-founder da HashiCorp), que eu acho bem interessante e limpo, com foco total no conteúdo textual.

A arquitetura

A arquitetura da aplicação é híbrida, utilizei a AWS e a Digital Ocean, o código e o CI/CD estão no GitHub.

Quem me conhece, sabe o quanto eu sou apaixonado pela AWS, mas manter um cluster EKS rodando por um mês é algo que minha mera carteira de pessoa física não aguenta, a menos que seja dentro de um LocalStack. Por conta disso, escolhi a Digital Ocean, que oferece uma hospedagem confiável de Kubernetes por um preço mais em conta.

Na AWS estão hospedados:

• O meu domínio (no Route 53)
• O Cognito, que é usado para a autenticação no painel administrativo do site (configuração client-side);
  • Em breve pretendo adicionar a funcionalidade de comentários também (se fizer sentido), então esse Cognito também deverá ser util para autenticar vocês, leitores.
• O Bucket S3 com os arquivos estáticos do site.
• A distribuição Cloudfront que faz a entrega de conteúdo do bucket S3 de maneira performática e segura (autenticação no bucket via OAC).

Na Digital Ocean temos:

• Um load balancer associado ao cluster.
• O cluster Kubernetes, que por sua vez contém:
  • ArgoCD para gerenciar e atualizar o estado do cluster, sincronizado ao meu repositório de GitOps.
  • A aplicação Client, feita com Next.JS.
  • A API, feita com NEST.
  • O banco de dados Postgres, aqui se encontram armazenados os metadados de posts e tags, bem como a relação entre essas duas entidades.

No GitHub estão:

• Os repositórios da aplicação Client e da API, além do repositório GitOps associado ao ArgoCD.
• Os workflows responsáveis pela integração contínua e build das imagens.
• O registry que armazena as imagens das aplicações.

Decisões de Arquitetura

Na hora de construir uma aplicação, precisamos tomar diversas decisões complicadas. Como: qual linguagem escolher? Qual framework? Qual engine de banco de dados? E o CI/CD?

• Para a escolha da linguagem, fiz questão de escolher o TypeScript, pois é a linguagem web que eu mais tenho experiência.

• Sobre os frameworks, também escolhi Next e Nest justamente pela experiência prévia.

  • Ora, mas por que não fazer só em Next, que é um framework fullstack?
    • Porque eu queria construir algo desacoplado, com uma melhor segregação de responsabilidades. A vantagem disso é que se a API cair, o client em si não fica indisponível, e ainda dá margem para cachear o conteúdo da API, que em sua maioria possui uma variação tão grande (posts, tags e arquivos markdown), o que colabora pra uma taxa alta de CACHE HIT.

• A engine de banco de dados escolhida foi o PostGres, pois possui a robustez e a flexibilidade necessária para oferecer uma aplicação performática, e eu particularmente gosto bastante da feature de Full Text Search do Postgres, que vai ser muito útil no futuro para incluir uma barra de busca aqui no site, uma feature que está no roadmap.

• Sobre o CI/CD, fiz questão de escolher o GitHub Actions pela praticidade, considerando que os repositórios já estão no GitHub. Dadas essas duas, a escolha no GitHub Container Registry como plataforma de armazenamento das imagens foi natural, pois possibilita a integração com o GitHub Actions de uma maneira bem fácil e rápida de configurar.

• Um outro detalhe importante é relativo ao frontend, inicialmente eu havia planejado hospedá-lo em um bucket S3, através da feature de construção de site estático do Next. Isso porém exigiria um redeploy do frontend toda vez que houvesse um novo conteúdo publicado (para remapear as rotas), o que não era muito prático, isso me fez optar por rodar o frontend no próprio Cluster Kubernetes, junto da API.

E como vai funcionar?

Como dito, aqui no blog você verá conteúdo técnico focado em Cloud, isso inclui dicas de ferramentas úteis no dia a dia de um engenheiro de DevOps, cases técnicos, estudos e comentários sobre aprendizados profissionais. Espero que gostem, que possam me acompanhar, e que o conteúdo oferecido aqui seja útil para vocês de alguma forma. Obrigado por ler até aqui!

#!/bin/bash
echo "Hello World"