Rolling Deploy no Node.js: atualize sem downtime

Rolling Deploy no Node.js substitui instâncias antigas por novas gradualmente, mantendo o serviço disponível durante a atualização. O processo depende de readiness correta, compatibilidade entre versões e encerramento gracioso.

Estratégia do Deployment

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 0
    maxSurge: 1

maxUnavailable: 0 preserva a quantidade disponível, enquanto maxSurge permite criar capacidade temporária.

Readiness antes do tráfego

A nova instância só deve receber tráfego após carregar configuração, conectar recursos essenciais e concluir aquecimento. Consulte Kubernetes Probes no Node.js.

Graceful shutdown

Ao receber SIGTERM, marque readiness como falha, pare de aceitar novas conexões e aguarde requisições em andamento.

process.on('SIGTERM', () => {
  state.shuttingDown = true;
  server.close(() => process.exit(0));

  setTimeout(() => process.exit(1), 20_000).unref();
});

terminationGracePeriodSeconds

O prazo do Kubernetes deve ser maior que o timeout interno de shutdown. Caso contrário, o processo recebe SIGKILL antes de concluir.

preStop

Um hook pode criar pequena espera para propagação da remoção dos endpoints, mas não substitui readiness nem shutdown correto.

Compatibilidade com banco

Durante o rollout, versões antiga e nova coexistem. Use migrations expand and contract: primeiro adicione estruturas compatíveis, depois altere aplicações e só remova campos em etapa posterior.

Consulte Database Migrations no Node.js.

Contratos de eventos e APIs

A nova versão deve aceitar mensagens antigas enquanto elas ainda podem existir na fila. Em APIs, preserve compatibilidade ou versione explicitamente.

Sessões

Não dependa de memória local para sessões importantes. Use armazenamento compartilhado ou tokens adequados, pois o usuário pode alcançar pods diferentes.

Conexões persistentes

WebSockets, SSE e streams longos exigem prazo e estratégia de drenagem. Um rollout pode aguardar demais se conexões nunca terminarem.

Canary

Para mudanças arriscadas, direcione pequena porcentagem à nova versão e compare erros, latência e SLO antes de ampliar.

Rollback

Rollback de imagem deve ser rápido, mas só funciona se banco e contratos continuarem compatíveis. Teste o procedimento antes de incidentes.

Configuração

Associe versão da imagem e checksum de ConfigMap/Secret ao pod template. Isso torna a mudança rastreável e força novo rollout quando necessário.

Observabilidade

Compare métricas por versão:

• taxa de erro;
• latência;
• reinícios;
• readiness;
• consumo de CPU e memória;
• error budget;
• falhas de dependência.

Veja Error Budget no Node.js.

Erros comuns

• readiness sempre positiva;
• processo ignorar SIGTERM;
• migration incompatível;
• remover campo usado pela versão anterior;
• não comparar métricas por versão;
• depender de sessão em memória;
• não ter rollback testado.

Conclusão

Rolling Deploy no Node.js exige mais que trocar containers. A aplicação precisa iniciar com segurança, coexistir com a versão anterior e encerrar sem interromper trabalho.

Combine probes, shutdown gracioso, migrations compatíveis e métricas por versão. Consulte a documentação de Rolling Update do Kubernetes e a documentação de fechamento do servidor HTTP.