Em quase 20 anos da minha trajetória profissional aprendi bastante depois de participar de vários projetos, tanto aqueles de infra mais raíz, quanto migrações para cloud, Kubernetes e por aí vai. Em algumas vezes tomei decisões erradas, mas o importante disso é o aprendizado. E nada mais justo do que repassar esse conhecimento a diante.

Por isso, eu vejo muitas pessoas (desde os que estão começando agora até os mais experientes) tomando decisões ou querendo surfar a onda do hype, ou como costumávamos dizer na Leroy Merlin, sendo “bleeding-edge”.

Esse post é para quem está trabalhando em projetos greenfield, stealths ou começando do zero.

1 - Escolha tecnologias maduras (boring tech)

Sim, escolha tecnologias maduras ao iniciar novos projetos. Aquele novo orquestrador de conteiner, aquele novo serviço da AWS ou aquele framework novo que promete ser 20% mais rápido que o framework que você utiliza não vale todo o overhead operacional.

Sim, é legal usar e testar novas tecnologias, eu gosto e todo mundo gosta, mas cuidado ao usar em projetos novos. As vezes o tempo gasto dando manutenção em algo que “ninguém usa”, seria muito mais útil se aproveitado trabalhando em melhorias reais de performance.

2 - Infra as Code desde o início

Simples como o título. Provisionar infra não é mais o famoso “next, next, finish” na console da AWS (ou qualquer outra cloud). Sem saber o que e como foi feito só vai gerar mais dívida técnica e impossibilitar de recriar o ambiente em caso de necessidade.

Sem contar as inúmeras vantagens que IaC traz, como rastreabilidade, consistência e redução de erros, já que o código pode ser revisado e testado.

3 - Segurança planejada, não acidental

Adicionar segurança depois que o projeto já está rodando, ou depois de um incidente é muito (mas muito) mais difícil do que construir desde o dia zero. Começar com o menor privilégio possível em roles, keys e etc já é um baita começo. Use IRSA ou Pod Identity na AWS.

Se seu escopo for além da cloud, Dependabot (ou Renovatebot) e Trivy salvam muito.

4 - Automatize tudo

É o mesmo ponto de Infra as Code. Não se trata de velocidade e sim de consistência. Processos manuais criam silos de conhecimento e pontos únicos de falha.

O mínimo aceitável é ter um fluxo de deploy automatizado tanto para infraestrutura quanto para o código.

5 - Documente decisões

Não adianta só documentar seu código, documente suas decisões e os motivos de escolher determinadas arquiteturas.

Um bom início é escrever ADRs (Architectural Decision Records). Não precisa ser nada rebuscado, um markdown em um repositório no GitHub já ajuda. Com certeza, vai ajudar as próximas pessoas do seu time a entender o por que as coisas são do jeito que são.

6 - Se questione o “por que”

Esse vai de encontro com o ponto acima.

A arquitetura das aplicações (ou infraestrutura) devem servir ao negócio, não ao contrário. Tecnologia não é o objetivo, é o meio. Mantenha as coisas simples, com propósitos e alinhado ao negócio.

Provavelmente você não precisa de microserviços para um MVP.

7 - Planeje para falhas

Uma hora seu serviço, sua infra, seu DNS vai falhar. Toda rede tem problemas. Desenhe sua arquitetura esperando que isso vai acontecer em algum momento.

Aprendi com um antigo gestor durante uma migração de servidores Microsoft Exchange 2003 para 2010 (ainda existe isso?), o seguinte pensamento:

Quem tem um, não tem nenhum.
Quem tem dois, tem um.
Quem tem três, tem dois.

E é sobre isso. Tenha no mínimo duas réplicas do que é core para o negócio.

8 - Observabilidade

O papo de observabilidade não é monitoração já tá batido. Identifique seus SLIs e defina SLOs para acompanhá-los. Novamente, tecnologia a favor do negócio e não ao contrário.

Comece instrumentando seu código e pontos chaves da infraestrutura. A stack LGTM é um ótimo ponto de partida.

An english version is coming soon. Stay tuned. 😃

Uma breve introdução

Sempre fui contra utilizar os Helm Charts da Bitnami - as imagens dos conteineres são super modificadas e no caso do Keycloak especificamente, é uma confusão enorme com as ENV VARs para configurá-lo (KC_*), as ENV VARs para configurar o conteiner da Bitnami (KEYCLOAK_*) e a documentação não é das melhores. Mas não posso negar que em alguns momentos esses Charts ajudam a subir algo rápido, e foi por esse motivo que o time que trabalho decidiu subir dessa forma, ao invés de utilizar o Keycloak Operator.

No fim do ano passado, puxei a iniciativa de atualizar as intâncias de Keycloak que utilizamos na Pier com outros Staff Engineers para suportar algumas funcionalidades que seriam interessantes implementar em algumas aplicações. Foi um trabalho de formiguinha, mas deu certo. Nesse post, irei explicar o processo e dar algumas dicas.

Vale ressaltar que nem todos ambientes são iguais, no nosso caso, utilizamos ALB Ingress Controller no AWS EKS, rodando Kubernetes 1.31.

Após uma pergunta no grupo Cloud & Infra da comunidade Platform Engineering no Whatsapp, resolvi escrever esse post para ajudar outras pessoas. Espero que possa te ajudar também!

Dicas de ouro

A ideia era atualizar para a última versão do Keycloak (26.0.7) e meu primeiro erro foi tentar subir da versão 22 direto para 26 e subindo a versão do Helm Chart da 16 para 24. E as coisas não funcionam assim.

Por isso, faça upgrades sequenciais, tanto do Keycloak quanto do Helm Chart. Entre as major versions do Keycloak, o banco é atualizado diversas vezes e não senti segurança na execução das migrations entre a 22 e a 26, principalmente pela alta customização da imagem feita pela Bitnami. Os Helm Charts também devem ser atualizados de forma sequencial, porém, nem sempre atualizações entre major versions funcionam bem.

Segunda dica, antes de cada upgrade leia o Upgrading Guide na documentação oficial do Keycloak. A doc não é das melhores, mas explica mudanças significativas como alteração do hostname_v1 para hostname_v2 e na API.

A terceira dica é, testar, testar e testar. Verifique se o login na console de administração está funcionando e o principal, se sua aplicação continua funcionando conforme o esperado.

Atualizando

Os values utilizados a partir da versão 16.0.3 do Chart (Keycloak 22.0.1) estão nesse Gist. Eu usarei o mesmo YAML como referência até a versão 24.2.3 e mencionando apenas as mudanças, caso você não queira ir até a última versão do Chart.

Upgrades sem mudanças nos values

• Helm Chart: 16.0.3 → 17.3.6 / Keycloak: 22.0.5

• Helm Chart: 17.3.6 → 18.7.1 / Keycloak: 23.0.7

• Helm Chart: 18.7.1 → 19.4.1 / Keycloak: 23.0.7

  • Você pode pular esse upgrade e ir direto para a 19.4.1, caso queira ir para a versão 24.0.2 do Keycloak.

• Helm Chart: 19.4.1 → 21.0.0 / Keycloak: 24.0.2

• Helm Chart: 21.0.0 → 21.1.3 / Keycloak: 24.0.4

• Helm Chart: 21.1.3 → 21.2.2 / Keycloak: 24.0.4

  • Você pode pular esse upgrade e ir direto para a 21.3.4, caso queira ir para a versão 24.0.5 do Keycloak.

• Helm Chart: 21.2.2 → 21.3.4 / Keycloak: 24.0.5

• Helm Chart: 21.3.4 → 21.4.6 / Keycloak: 24.0.5

• Helm Chart: 21.4.64 → 21.5.0 / Keycloak: 24.0.5

• Helm Chart: 21.5.0 → 21.6.0 / Keycloak: 24.0.5

Upgrades com mudanças nos values

A partir da versão 21.6.0, uma série de releases foram lançadas tentando corrigir vários bugs, regressões e etc… um caos completo.

Você também irá notar que eu voltei para a 21.5.0. Isso se deve ao fato de puro troubleshooting, tentando quebrar minha cabeça para entender a bagunça feita pelos mantenedores e comunidade.

• Helm Chart: 21.5.0 → 22.1.0 / Keycloak: 25.0.2

  • Mudanças:

    • proxy: none - Isso se deve ao fato da remoção de como o Keycloak trata requests atrás de um proxy reverso.

    • proxyHeaders: forwarded - Devido a mudança acima, existe uma nova forma de tratar e configurar os proxy headers atrás de um ingress ou proxy reverso. Vale a pena ler a documentação oficial sobre o tema.

    • ingress.controller: gce - Alguns usuários utilizando o ingress-gce, setam /* no ingress.path, assim como eu, utilizando o ALB Ingress Controller. Setar gce nesse parâmetro vai fazer com que ao utilizar /*, o ingress rule não quebre.

    • hostnameStrict: false - Ajustando o configuração de hostname v2 do Keycloak.

• Helm Chart: 22.1.0 → 24.0.0 / Keycloak: 26.0.0

  • Sem mudanças

• Helm Chart: 24.0.0 → 24.2.3 / Keycloak: 26.0.7

  • As mudanças realizadas aqui foram feitas para resolver problemas que tivemos no nosso cenário:

    • global.security.allowInsecureImages: true - Utilizamos uma imagem customizada do Keycloak onde inserimos temas e mais alguns componentes desenvolvidos internamente. Mais infos aqui.

    • proxyHeaders: xforwarded - Após iniciarmos os testes, alguns fluxos de autenticação retornavam erros relacionados aos cookies. Setar xforwarded resolveu o problema.

O resultado final dessa saga, você pode conferir nesse Gist.

Notas finais

Eu levei um dia e meio para ler e entender todas as mudanças feitas no Helm Chart entre as versões 16.0.3 e a 24.2.3. Recomendo não só para o Keycloak, mas para qualquer Chart da Bitnami fazer o mesmo. Anotar e documentar o processo é importante para não perder o fio da meada.

Se atentar as mudanças na API do Keycloak no Upgrading Guide é super importante também. No nosso caso tivemos que fazer alguns ajustes nas aplicações, então tenha tudo mapeado.

Espero que esse post possa ajudar a comunidade de alguma forma.

Até mais!