¿Es mejor un Dockerfile monolítico o multi-stage para mi API Node.js + PostgreSQL?

Fashion

Hola comunidad, estoy reestructurando el despliegue de una API en Node.js (Express) con conexión a PostgreSQL. Mi Dockerfile actual es un "monstruo" de una sola etapa: instala dependencias, compila assets, copia todo y corre la app. Funciona, pero la imagen pesa casi 1.8GB.

He investigado sobre multi-stage builds. Mi idea es:
Stage 1 (builder): Usar node:18-alpine, instalar dependencias (incluyendo devDependencies para TypeScript), compilar TS a JS.
Stage 2 (production): Usar node:18-alpine, copiar solo node_modules (producción) y los JS compilados desde el builder. Instalar solo postgresql-client para healthchecks.

Mi duda de arquitectura: ¿Vale la pena la complejidad? La app necesita ejecutar migraciones de DB al iniciar (knex migrate:latest). En el enfoque multi-stage, ¿dónde y cuándo las ejecuto? ¿En el stage final como parte del CMD, o en un entrypoint script? Temo que el builder se quede sin las herramientas de knex si solo copio node_modules de producción.

¡Agradezco reviews de lógica y mejores prácticas!

Cooking

Definitivamente multi-stage. La reducción de tamaño no es solo por almacenamiento, es seguridad: menos paquetes, menos superficie de ataque. Sobre las migraciones, la práctica común es ejecutarlas en el entrypoint del contenedor final ANTES de levantar la app. Asegúrate de que tu stage de producción incluya knex como dependencia normal (no dev), y que el entrypoint verifique la conectividad a la DB antes de correr las migraciones. Te dejo un snippet de mi entrypoint.sh:

#!/bin/sh
until pg_isready -h $DB_HOST; do
  echo "Waiting for DB..."
  sleep 2
done
npx knex migrate:latest
node server.js

World

No siempre multi-stage es la respuesta. Si tu imagen se despliega en un entorno donde el tiempo de build es crítico (CI/CD con minutos limitados), añadir etapas lo hace más lento. Para una API simple, podrías optimizar el monolítico: usa .dockerignore agresivo, limpia la cache de apt/apk en la misma capa, y elimina los devDependencies después de la compilación en un RUN. A veces la simplicidad de un solo Dockerfile gana.

Fashion

Gracias por el snippet del entrypoint. Tiene sentido. Mi preocupación era que si en el stage de producción solo copio node_modules --production, knex no estaría porque es una devDependency en mi package.json (solo lo uso para migraciones). Entonces debo moverlo a dependencies, ¿cierto? Eso me obliga a repensar la separación de deps, pero es correcto para el runtime.

Soul

Exacto, knex debe ser dependency, no devDependency. Otra arquitectura que uso: tengo un contenedor aparte (ej. db-migrator) que se basa en el stage builder y solo corre las migraciones, y la imagen principal de la API es ultra-ligera sin knex. Se lanza como initContainer en Kubernetes o como servicio en docker-compose que sale al terminar. Separa responsabilidades.

Guitar

El comentario sobre la simplicidad tiene algo de razón, pero 1.8GB es excesivo. Incluso un enfoque intermedio: usa una sola etapa pero con limpieza agresiva. Algo como:
RUN npm ci --only=production && npm cache clean --force RUN apk del .build-deps
Pero el multi-stage es más elegante y claro en intención. Para las migraciones, yo las ejecuto desde el CI/CD (GitLab, GitHub Actions) con un contenedor efímero, no desde el entrypoint. Así la app no asume esa responsabilidad.

Fashion

La idea del contenedor migrator separado es interesante, pero añade complejidad a mi pipeline actual. Creo que iré por multi-stage, moviendo knex a dependencies y usando un entrypoint como el primero que compartieron. Reduje la imagen a ~380MB en mis pruebas. ¡Gran mejora! ¿Alguna recomendación adicional para el Dockerfile en cuanto a orden de capas para mejor cache?

ScienceFan

Para cache: copia package.json y package-lock.json ANTES del código de la app. En el builder, haz RUN npm ci solo después de copiar esos archivos. Así, si no cambian las dependencias, reutiliza la capa. En la etapa final, copia desde el builder solo lo necesario en el orden: de lo que menos cambia (node_modules) a lo que más (el código compilado). ¡Éxito!