Viernes 17:00, despliegue urgente: pm2 restart api. Durante treinta segundos, la sonda externa muestra 502, el soporte se sumerge y un socio reinicia sus webhooks en un bucle. El lunes por la mañana, alguien probó la pm2 reload api en modo clúster: misma versión, mismo código, y la sonda no detectó ninguna interrupción.
PM2 no es sólo un demonio “para que Node.js lo ejecute”. Es un orquestador de procesos con una semántica de reinicio precisa. Reiniciar y recargar confusamente en producción significa elegir voluntariamente un microcorte cada vez que lo pone en línea.
ecosistema.config.js: la base de una implementación limpia
Un archivo ecosystem.config.js versionado evita que se olviden los comandos ad hoc en el siguiente inicio. Aquí hay una configuración inicial para una API de Node.js en producción:
módulo.exportaciones = {
aplicaciones: [{
nombre: 'api',
secuencia de comandos: './dist/server.js',
instancias: 'max',
exec_mode: 'clúster',
esperar_listo: verdadero,
tiempo de espera de escucha: 10000,
kill_timeout: 5000,
max_memory_restart: '600M',
env_producción: {
NODE_ENV: 'producción',
ENVÍO: 3000,
},
}],
};
Si habilita wait_ready: true, la aplicación debería informar su disponibilidad con process.send('ready') una vez que el servidor HTTP esté listo para recibir tráfico. El parámetro kill_timeout define el tiempo permitido para que los trabajadores completen las solicitudes en curso antes de un cierre forzado.
Un
kill_timeoutque es demasiado corto transforma una recarga elegante en un reinicio disfrazado.
Apagado elegante: lo que PM2 no hará por usted
PM2 puede esperar, pero sólo si su código sabe cómo salir limpiamente. Sin un administrador SIGINT o SIGTERM, recargar y reiniciar tienen el mismo aspecto: las conexiones se cortan en medio del procesamiento.
proceso.on('SIGNO', () => {
servidor.close(() => proceso.exit(0));
setTimeout(() => proceso.exit(1), 8000).unref();
});
Recuerde también cerrar el grupo de conexiones de la base de datos, vaciar los búferes de registro y detener los consumidores de la cola. Para WebSockets, hay dos opciones: notificar a los clientes que necesitan volver a conectarse o drenar las conexiones activas antes de apagarlas.
Flujo de trabajo de implementación recomendado
Una implementación perfecta suele seguir esta secuencia:
- Recupere la versión (Git pull o alternancia de enlace simbólico atómico).
- Instale dependencias con
npm ci --production. - Ejecute
pm2 reload ecosistema.config.js --env production --update-env. - Guarde la configuración con
pm2 savepara que sobreviva al reinicio del servidor. - Ejecute una prueba de humo en el punto final de salud.
Para una reversión, vuelva a apuntar el enlace simbólico al artefacto anterior y reinicie una recarga. Evite pm2 delete seguido de un inicio excepto durante la primera instalación: perderá el historial de métricas y reinicios.
Nginx frente a PM2: distribución de roles
En producción, nginx finaliza TLS y reenvía el tráfico dinámico a PM2:
proxy_pass http://127.0.0.1:3000;
proxy_http_versión 1.1;
Alinee los tiempos de espera de nginx (proxy_read_timeout, proxy_connect_timeout) con el kill_timeout de PM2. Para WebSockets, consulte nuestra guía de tiempo real con WebSocket.
En un VPS, configure pm2 startup systemd con un usuario que no sea root. Dimensione la RAM según la cantidad de trabajadores y el consumo máximo de memoria por instancia. En una PaaS tipo Heroku, la plataforma a menudo gestiona el ciclo de vida del proceso: PM2 sigue siendo especialmente relevante en el autohospedaje en VPS o bare metal.
La cumbre: PM2 oculta la ausencia de gracia, hasta que se recarga
Antes de cada fusión en producción, pruebe SIGINT y SIGTERM localmente y luego ejecute una recarga en preparación. Es la diferencia entre una implementación invisible y medio minuto de 502 medidos por sus clientes.
Decide y avanza sin puntos ciegos
Durante medio día, podrá proteger sus implementaciones de Node.js:
- Vaya al modo de clúster si su API HTTP no tiene estado y reemplace "reiniciar" con "recargar" en todos sus scripts de implementación.
- Implementar y probar controladores SIGINT/SIGTERM: cierre de servidor, grupo de bases de datos, consumidores de colas.
- Versión un
ecosystem.config.jscompleto con variables de entorno de producción y límites de memoria. - Coloque nginx delante de PM2 para TLS, archivos estáticos y limitación de velocidad.
- Supervise el número de reinicios y la latencia del bucle de eventos para detectar pérdidas de memoria antes de que activen un reinicio automático.
Para obtener más información sobre las pérdidas de memoria de Node.js, consulte Pérdida de memoria de Node.js. Para comparar hosts adecuados para la implementación de VPS, explore nuestro directorio.
Preguntas frecuentes
¿Diferencia entre reinicio de pm2 y recarga de pm2?
El reinicio se detiene repentinamente y luego se reinicia: apagado garantizado. reload envía un apagado elegante, espera a que se completen las solicitudes actuales y luego reinicia a los trabajadores uno por uno en modo clúster. En producción, recargar es la opción predeterminada.
¿Cuándo utilizar el modo de clúster?
Siempre que una aplicación HTTP sin estado necesite aprovechar varios núcleos de CPU. Limítese a un trabajador por núcleo. Para WebSockets, agregue una sesión persistente o un adaptador de Redis compartido entre trabajadores.
¿PM2 es suficiente sin nginx?
Es posible, pero todavía se recomienda nginx para el cifrado TLS, el servicio de archivos estáticos y la protección contra abusos. PM2 escucha el puerto de la aplicación; nginx hace el proxy inverso público.
¿Cómo gestionar las variables ambientales en la implementación?
Centralice la configuración en un ecosystem.config.js versionado y use --update-env al recargar. Los secretos permanecen fuera de Git: archivos en el servidor o en una bóveda dedicada.
PM2 en producción se recarga con un apagado ordenado, no se reinicia mientras los usuarios aún están conectados.