</> HTML5Advent
ENFRESDEITPT

// hosting · Web Platform Advent #14

Como hospedar uma app Node.js: VPS, PaaS e serverless

As formas práticas de fazer deploy de uma aplicação Node.js — VPS, PaaS gerido ou serverless — mais PM2, um reverse proxy, variáveis de ambiente e um fluxo de deploy sensato.

Uma mão a inserir uma blade de servidor num rack de servidores iluminado a azul

Hospedar uma app Node.js é diferente de hospedar um site estático ou uma página PHP. O Node executa um processo de longa duração que possui o seu próprio servidor HTTP, por isso o host tem de manter esse processo vivo, reiniciá-lo após uma falha e encaminhar o tráfego público para ele. Este guia percorre as três opções realistas e as peças de que precisas independentemente da que escolheres.

Três formas de hospedar Node.js

Quase todos os deployments se enquadram num destes modelos. A escolha certa depende de quanto do servidor queres gerir e de como o teu tráfego se comporta.

  • VPS (autogerido) — obténs uma máquina Linux e acesso root completo. Controlo máximo e custo previsível, mas instalas e manténs tu mesmo o Node, o gestor de processos, o reverse proxy e o TLS.
  • PaaS (platform-as-a-service) — fazes push do código (muitas vezes via Git) e a plataforma constrói, executa e escala o processo por ti. Menos controlo, mais rápido a entregar, normalmente faturado por utilização.
  • Serverless / funções — fazes deploy de handlers individuais em vez de um servidor em execução. A plataforma inicia-os a pedido. Ótimo para cargas de trabalho irregulares ou de baixo tráfego, mas stateless e sujeito a cold starts.

Manter o processo vivo com PM2

Num VPS, executar node server.js na tua shell para no momento em que terminas a sessão, e nada o reinicia após uma falha. Um gestor de processos resolve ambas as coisas. O PM2 é a escolha mais comum:

npm install -g pm2

# start the app and name it
pm2 start server.js --name web

# restart automatically after a server reboot
pm2 startup
pm2 save

# useful day-to-day commands
pm2 list
pm2 logs web
pm2 restart web

O PM2 também executa a tua app em modo cluster para usar todos os núcleos da CPU, a forma mais simples de escalar uma única máquina:

pm2 start server.js --name web -i max
Uma fila de servidores montados em rack num data center
Num VPS o teu processo Node corre numa máquina física ou virtual como estas; um gestor de processos mantém-no em execução e um reverse proxy expõe-no à web.

Um reverse proxy à frente do Node

Não exponhas o Node diretamente na porta 80/443. Coloca à frente um reverse proxy como o Nginx: ele termina o TLS, serve ficheiros estáticos de forma eficiente e pode encaminhar várias apps numa só máquina. Um bloco de servidor Nginx mínimo que encaminha o tráfego para uma app Node a escutar na porta 3000:

server {
  listen 80;
  server_name example.com;

  location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
  }
}

Os cabeçalhos Upgrade e Connection importam se a tua app usar WebSockets. Para HTTPS, a via habitual é um certificado gratuito da Let's Encrypt através do certbot, que edita esta configuração por ti.

Variáveis de ambiente e configuração

Nunca escrevas segredos (URLs de base de dados, chaves de API) diretamente no teu código-fonte. Lê-os do ambiente com process.env e deixa a plataforma injetá-los:

const port = process.env.PORT || 3000;
const dbUrl = process.env.DATABASE_URL;

app.listen(port, () => {
  console.log(`listening on ${port}`);
});

Num VPS podes mantê-los num ficheiro .env (carregado por uma biblioteca e excluído do Git) ou passá-los através do ficheiro ecosystem do PM2. Numa PaaS, defines-os no painel. Lê sempre process.env.PORT — as plataformas geridas atribuem-te a porta.

Um fluxo de deploy sensato

Independentemente de como hospedas, procura um deploy repetível em vez de editar ficheiros no servidor à mão:

  • Obtém o novo código (git pull ou um artefacto de CI).
  • Instala apenas as dependências de produção: npm ci --omit=dev.
  • Executa o passo de build, se tiveres um (npm run build).
  • Recarrega o processo sem tempo de inatividade: pm2 reload web.

Numa PaaS toda esta sequência é despoletada por um git push; num VPS podes criar um script para ela ou ligá-la a um CI runner.

Que opção encaixa?

OpçãoTu geresMelhor quando
VPSOS, Node, PM2, Nginx, TLSQueres controlo e custo previsível
PaaSApenas o teu código + variáveis de ambienteQueres entregar depressa e escalar facilmente
ServerlessHandlers individuaisTráfego irregular ou baixo, trabalho stateless

Se estás a começar, um único VPS bem configurado com PM2 e Nginx executará confortavelmente a maioria das apps Node e ensina-te o que as plataformas geridas automatizam. Passa para uma PaaS ou serverless quando a escalabilidade ou a sobrecarga operacional se tornarem o estrangulamento — não antes.