Express.js
Deployment de Express
Explica cómo desplegar Express.js detrás de un proxy, configurar procesos, variables, health checks, timeouts, logs, releases y rollback.
- Última actualización
- Actualizada
- Nivel
- Profundización
Express.js
Explica cómo desplegar Express.js detrás de un proxy, configurar procesos, variables, health checks, timeouts, logs, releases y rollback.
Desplegar Express significa ejecutar un artifact reproducible detrás de infraestructura conocida, con configuración validada, health checks, observabilidad, migraciones compatibles y rollback.
commit
→ build + tests + scans
→ artifact inmutable
→ migraciones compatibles
→ rollout gradual
→ health y métricas
→ promoción o rollbackSubir código no es suficiente. Producción incluye red, procesos, datos y operación.
Compila TypeScript y empaqueta solo lo necesario:
npm ci
npm run typecheck
npm test
npm run buildEl artifact debe asociarse a commit, versión y SBOM. La misma imagen se promueve entre ambientes.
Inyecta env/secrets al ejecutar. Startup valida antes de recibir tráfico. No reconstruyas imagen por cada ambiente ni derives URLs críticas del request.
Ejecuta un proceso Node por contenedor normalmente. La plataforma administra réplicas. PM2/cluster puede ser útil fuera de orquestadores, pero añade otra capa de supervisión.
No uses un watcher de desarrollo en producción.
TLS, buffering, body limits, timeouts y forwarded headers deben coordinarse con Express. Restringe acceso directo y configura trust proxy según topología.
Usa expand-contract:
No mezcles una migración destructiva con rollout donde conviven versiones.
Reemplaza instancias gradualmente. Requiere compatibilidad entre versión vieja/nueva y DB.
Dos entornos; cambia tráfico. Rollback rápido, pero datos compartidos complican reversión.
Envía pequeño porcentaje y compara métricas. Necesita routing y criterios claros.
La estrategia depende de riesgo y plataforma.
Una instancia solo recibe tráfico cuando está lista. Durante startup no debe responder ready antes de conectar dependencias críticas.
Liveness no debe reiniciar por una DB temporalmente caída.
Rollout envía SIGTERM. La app marca not-ready, drena requests y cierra dependencias dentro del grace period.
Sin shutdown, rolling deploy puede producir 502, transacciones cortadas y jobs duplicados.
Coordina:
Valores contradictorios crean trabajo huérfano o conexiones reseteadas.
Rollback de código no siempre revierte datos. Una migración destructiva puede hacer imposible volver.
Diseña rollback antes del deploy:
Después del deploy:
Asocia resultados al deployment ID.
Compara nueva vs anterior:
Un 200 saludable no garantiza que las órdenes se creen correctamente.
Deploy que añade idempotency:
No se necesita downtime.
Express puede ejecutarse en funciones, pero cambian:
No asumas que un servidor tradicional se comporta igual. Usa adaptador/plataforma y servicios externos para jobs.
Desplegar múltiples regiones afecta latencia, consistencia, sesiones y DB. Es un problema de System Design; Express no replica estado.
Incluye source maps protegidos para stacks. Logs salen a stdout en contenedores y se recolectan. No escribas archivos locales persistentes.
Documenta:
El runbook se prueba en incidentes simulados.
Express en Docker construye un runtime mínimo, seguro y reproducible para ese deployment.