[Review and Proprosal] Docker, Kubernetes and Helm support.

Ola a todos, gostei muito do projeto e quero ajudar. Vou adicionar ao projeto uma imagem docker, a action para fazer deploy da mesmo no docker hub e no podman, ficheiros para rodar o docker-compose, Dockerfile para test, Dockerfile para ambiente de desenvolvimento no vscode, ficheiros para a execução em K8s e de quebra um helm se tiver tempo. (E um Makefile, para setup e test do projeto 👍🏽 ).

Entregaveis .:

• Dockerfile de execução
• Dockerfile de dev//build
• Dockerfile para support do vscode dev environment with container
• docker-compose.yaml
• Kubernetes .:
  • deployment.yaml
  • service.yaml
  • namespace.yaml
• brasilapi_helmchart.yaml [opt]
• .github/docker_deploy

Proposta inicial.:

• Docker build feita em duas fases, primeira a build, testes e construção do package; Segunda fase copiar o package da primeira e correr em uma imagem docker alpine-npm com o minimo de overhead.

Dockerfile.:
User || Uid .: brasilapi || 1000
Group || Gid .: brasilapi || 1000
workdir .: /home/brasilapi
ServicePort .: 5055
Entrypoint.: BrasilApi app

Hoje já é 02:20h am aqui amanhã já adiciono mais requisitos a issue, alguem tem algum requisito a mais? Testes, processos, compliences que a imagem ou configurações devem seguir? Até daqui a pouco. ^^

[magusd]

TLDR; As vantagens são as mesmas que ter só o docker. Compliance, segurança e estabilidade.

hospedar na vercel é o standard de quem é frontend, kubernetes e container é o standard de quem trabalha com infraestrutura. Caso o projeto seja adotado por empresas, há casos em que: 1 - compliance empresas exigem que haja o mínimo de comunicação com projetos de terceiros. Caso o projeto de vocês e a vercel não seja, por exemplo, PCIe ou HIPPA compliant, empresas na área de finanças e saúde não poderiam usá-lo. Trazer o projeto pra dentro de casa (k8s, docker) e fazer auditoria, ou simplesmente colocar atrás de um firewall seria uma forma de viabilizar a adoção do projeto nesses casos.

2 - version locking conforme o projeto evolui e as versões são lançadas, os métodos mudam, apis quebram e dinheiro é perdido. Para evitar isso, trazer o container em uma versão estática é uma boa prática. Aí quando o desenvolvedor puder, ele vai lá e muda a versão do container pra mais atual e testa, hoje nada impede de vocês mudarem a assinatura de um método e arrumarem os testes e quebrarem a api pra todo mundo.

3 - ambiente de dev hoje isso é comum em alguns lugares (onde eu trabalho) mas vai ficar mais comum com o passar dos anos, a gente tem o ambiente de dev com kubernetes, instalamos um mini cluster na máquina do dev e o processo de deploy é o mesmo que prod.

[lucianopf]

Dúvida sincera de um leigo @dsmello 😬

Quais as vantagens de ter todo o setup do projeto em K8s se a gnt deploya ele na Vercel e o npm run dev simula exatamente o ambiente que é rodado na Vercel?

O ambiente de dev bastaria rodar dentro de uma imagem do Docker com Node, não? 🤔 😬

Perdão se to sendo petulante mas é realmente curiosidade ^^