Melhorando meu Homelab aos poucos

Há pouco mais de um ano, eu não tinha nada além de uma VPS. Hoje tenho um mini PC dedicado rodando vários laboratórios isolados e estou planejando um cluster. No meio do caminho, o meu "lab" virou staging, depois produção, e um restart bobo derrubou serviços que clientes usavam.

Este texto conta essa evolução fase por fase. Não é um tutorial, é um relato com os erros e as lições de quem foi montando as coisas aos poucos.

Fase 1: uma VPS e muita curiosidade

Tudo começou com uma VPS daquelas de custo-benefício, de uma marca bem conhecida justamente por isso. E o custo-benefício é bom mesmo. Ela é fácil de configurar, fechar as portas é tranquilo e expor uma aplicação é basicamente apontar o domínio e pronto.

VPS (Virtual Private Server) é uma máquina virtual alugada dentro de um servidor físico de um provedor. Você tem root, IP público e faz o que quiser, mas divide o hardware com outros clientes.

No começo eu subi coisas que, sinceramente, não faziam muito sentido. Eu só queria ver funcionando. Com o tempo elas passaram a fazer sentido:

• n8n, para automações e workflows;
• Portainer, para gerenciar os containers Docker por uma interface web;
• Traefik, como reverse proxy na frente de tudo.

Depois de um tempo, troquei o Traefik pelo nginx. O Traefik é muito bom no modelo de descobrir os serviços sozinho, via labels nos containers, mas para o meu cenário eu queria outra coisa: configurar tudo em um arquivo só e apontar as portas. Para mim, essa centralização foi a melhor coisa da migração. Bato o olho num arquivo e sei exatamente o que está exposto e para onde.

  upstream api {
      server 127.0.0.1:3000;
  }

  upstream frontend {
      server 127.0.0.1:8080;
  }

  server {
      listen 80;
      server_name exemplo.com;

      proxy_set_header Host            $host;
      proxy_set_header X-Real-IP       $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

      # /api/... -> api (sem o prefixo /api)
      location /api/ {
          proxy_pass http://api/;
      }

      # Todo o resto -> frontend
      location / {
          proxy_pass http://frontend;
      }
  }

Fase 2: o lab virou staging

A coisa mudou quando comecei a servir aplicações de verdade nessa VPS. Ela deixou de ser só um lab e passou a ser um ambiente de staging.

O problema é que esse staging morava ao lado de aplicações instáveis e inconstantes: experimentos, serviços de teste, coisas que eu subia e esquecia. Tudo na mesma máquina, dividindo CPU, memória e o mesmo Docker.

Na época, isso não me incomodou tanto. Foi aprendizado: eu estava vendo na prática por que ambientes existem separados.

Fase 3: o staging virou produção

Um ano depois, aquele lab já não era lab nem staging. Era produção. E isso não foi uma decisão planejada, foi algo que simplesmente aconteceu: aplicações que começaram como teste passaram a ter gente dependendo delas.

E aí veio o aviso que eu precisava. Descobri que serviços que alguns clientes usavam ficaram fora do ar por causa de um restart da VPS. Não foi um ataque nem um bug complexo, foi um restart. Como tudo dividia a mesma máquina, qualquer manutenção ou experimento afetava todo mundo.

Descobri que emm SRE, isso tem nome: blast radius, ou raio de explosão. É o tamanho do estrago quando algo dá errado. Ao misturar teste e produção na mesma máquina, o blast radius de qualquer mudança passa a ser tudo.

A solução foi fazer uma limpeza. Removi as aplicações inconstantes e os serviços de teste que estavam lá só por estar. A VPS passou a ter um papel só: rodar o que é produção.

Fase 4: um mini PC e os microlabs

Só que eu ainda precisava de um lugar para testar. E, apesar de a hospedagem ter um preço realmente atrativo, decidi investir em hardware próprio: um Lenovo M710q, um mini PC com i3 de 6ª geração e 16 GB de RAM, cerca de duas vezes mais potente que a VPS que eu usava.

Colocando lado a lado o que paguei em cada um:

vCPU é uma CPU virtual: em geral corresponde a uma thread de um processador físico que o provedor divide entre vários clientes. Por isso a comparação justa é vCPU × thread, e não vCPU × núcleo.

Por cerca de 23% a mais, tenho o dobro de RAM e o dobro de threads, e o hardware é só meu, sem vizinhos disputando CPU. Em compensação, a conta de luz e a internet passam a ser minhas, e não existe IP público nem datacenter por trás. Por isso a VPS continua sendo a casa da produção.

A estratégia, então, foi ter microlabs: uma VM aqui, outra ali, tudo gerenciado pelo Proxmox. E, cara, está sendo sensacional.

Proxmox VE é um hypervisor open source: você instala direto no hardware e ele vira uma plataforma para criar e gerenciar máquinas virtuais (KVM) e containers Linux (LXC) por uma interface web. Na prática, é como ter uma mini cloud em casa. Cada lab fica isolado na sua própria VM, e se um quebrar, os outros nem percebem.

Esse isolamento é exatamente a lição da fase 3, agora aplicada no lab. Posso quebrar uma VM à vontade, restaurar um snapshot e seguir em frente.

O mundo self-hosted

Com o Proxmox, descobri um mundo de serviços mantidos pela comunidade self-hosted. Alguns que estou usando:

• Gitea: um servidor Git leve, tipo um GitHub próprio, para os meus repositórios;
• Pi-hole: um servidor DNS para a rede de casa que bloqueia anúncios e rastreadores para todos os dispositivos;
• Uptime Kuma: um monitor de disponibilidade que avisa quando algum serviço cai. Olhando para trás, era exatamente o que teria me avisado do downtime da fase 3 antes de um cliente perceber.

Batendo nos limites

Rodar as coisas em casa também me fez enxergar limites que na VPS eu não via. Com esses serviços rodando e a demanda que veio vi de perto o gargalo: workers tentando rodar um pipeline meu e a minha rede local reduzida a zero.

Não pense quer era uma pipeline complexa, era justamente para testar o build de uma api nodejs expondo hello world. Ou seja um arquivo e suas dependencias.

Num provedor, esses limites ficam escondidos atrás de um painel. Em casa, você sente na pele, e aprende muito mais com isso.

O que eu aprendi até aqui

• Ambientes misturados viram um problema quando ninguém está olhando. Lab vira staging, staging vira produção, e você só percebe quando algo cai.
• Produção merece máquina própria, ou pelo menos isolamento de verdade. Um restart não pode derrubar cliente.
• Monitoramento não é opcional quando alguém depende do serviço. Descobrir um downtime depois é pior do que ser avisado na hora.
• Hardware próprio ensina o que a cloud abstrai: CPU, memória e rede são finitos.
• Um passo de cada vez funciona. Nada disso foi planejado desde o início, e tudo bem. ## Próximo passo: um cluster

O passo inicial foi a VPS, e hoje tenho um PC dedicado a isso. O próximo é montar um cluster de 2 ou 3 nodes e ver o que consigo fazer.