Node em produção: systemd, PM2 ou contentor?

O programa funciona na máquina de quem o escreveu. Falta decidir quem o mantém de pé num servidor — e há três respostas comuns, cada uma com um custo diferente.

1. O que é preciso resolver

A pergunta não é «qual é o melhor», é «o que é que isto tem de garantir». São sempre as mesmas cinco coisas:

• Voltar a arrancar depois de um reinício da máquina.

• Levantar-se sozinho quando o processo morre.

• Deixar registos num sítio que não encha o disco.

• Correr com um utilizador sem privilégios.

• Receber os segredos sem os ter escritos no código.

Qualquer das três opções resolve as cinco. A diferença está no que custam e no que trazem a mais.

2. systemd: já lá está

É a opção com menos peças móveis. Não se instala nada — a unidade são dez linhas, e o sistema operativo trata do resto. Os registos vão para o journal, que já tem rotação. O artigo sobre unidades tem o ficheiro completo.

O que fica por resolver é a implantação: pôr a versão nova lá dentro continua a ser copiar ficheiros, correr o npm ci e reiniciar. Se houver uma máquina só e uma aplicação só, é perfeitamente razoável.

3. PM2: a razão de existir é outra

O PM2 costuma ser apresentado como «o systemd do Node», e assim descrito não faz sentido nenhum — é um gestor de processos a correr por cima de outro gestor de processos.

A razão a sério é esta: o Node usa um núcleo só. Num servidor com oito, sete ficam a olhar.

pm2 start servidor.js -i max     # um processo por núcleo
pm2 reload servidor              # trocar a versão sem cortar ligações

Aquele reload é o argumento principal: levanta os processos novos, espera que respondam, e só então desliga os antigos. Quem está a meio de um pedido não dá por nada.

O preço é passar a haver duas camadas a gerir processos, e perguntas com duas respostas — está parado para o systemd ou para o PM2? O mesmo efeito consegue-se com o cluster do Node e várias unidades, com mais escrita e menos ferramenta.

4. Contentor: o que este site faz

A vantagem não é a execução — é o que vai dentro. A imagem leva a versão do Node, as dependências já instaladas e os ficheiros construídos; o servidor não compila nada.

Isso muda a implantação por completo: deixa de ser «copiar e reinstalar» e passa a ser trocar uma etiqueta de versão. E o regresso à versão anterior é trocá-la outra vez — ao contrário de desfazer uma instalação à mão.

As cinco garantias da lista vêm do compose e do Dockerfile, e não de um gestor de processos:

restart: unless-stopped   # levanta-se sozinho, e volta no arranque
env_file: [.env]          # os segredos entram por fora
logging:                  # com limite, para não encher o disco
  options: { max-size: '10m', max-file: '3' }

E dentro da imagem, duas linhas: USER node para não correr como root, e um healthcheck para alguém saber que está vivo.

O custo é real: é mais uma coisa a saber, e numa máquina com uma aplicação só, pode ser mais peso do que vantagem.

5. O que eu escolheria

• Uma aplicação, uma máquina, implantação manual — systemd. Não instalar nada é uma vantagem a sério.

• Várias aplicações, ou já há Docker na casa — contentor. A partir da segunda aplicação, ter tudo igual vale mais do que a simplicidade de cada uma.

• Vários núcleos a aproveitar — é aí que o PM2 entra, ou o cluster à mão. É um problema de desempenho, não de arranque.

O resumo

As três mantêm o processo de pé. O que as separa é o resto: o systemd não traz nada para instalar, o PM2 traz vários núcleos e troca sem corte, e o contentor traz a certeza de que o que corre é exatamente o que foi testado. Escolher pelo que se precisa, não pelo que é mais moderno.