Escribir un Dockerfile óptimo es una habilidad que ahorra minutos en cada build y megabytes en cada despliegue. Este generador de Dockerfile crea plantillas listas para producción para Node.js, Python, Go, Java o sitios estáticos, aplicando por defecto multi-stage build, usuario no-root, cacheo agresivo de dependencias y healthcheck. Aquí te contamos por qué cada línea importa y cómo pasar de una imagen de 900 MB a una de 40 MB sin sacrificar funcionalidad.
Por qué usar multi-stage build
Un build en varias fases separa la compilación (con todo el toolchain: compiladores, paquetes -dev, node_modules completos) del runtime (solo el binario final o los artefactos JS estáticos). La imagen final contiene únicamente lo imprescindible para ejecutar la aplicación, reduciendo drásticamente el tamaño, la superficie de ataque y el tiempo de pull. En una app Node típica pasas de 1.2 GB (node:20) a 180 MB (node:20-alpine con producción) o incluso 80 MB (distroless).
Orden de las instrucciones y cache de capas
Docker cachea cada instrucción como una capa. Un cambio invalida la capa y todas las siguientes. La regla de oro: copia primero package.json y package-lock.json, instala dependencias, y sólo entonces copia el código fuente. Así, cuando cambias tu código pero no las dependencias, Docker reutiliza el paso caro (npm ci) y el build es cuestión de segundos.
Usuario no-root y hardening
Un contenedor que corre como root es un contenedor peligroso: cualquier vulnerabilidad en la app o en una lib puede escalar al host si hay una fuga del namespace. El generador añade un USER 1001 por defecto, con directorio de trabajo /app y permisos ajustados. Combínalo con --read-only y --cap-drop=ALL en tu docker run para reducir aún más el radio de daño.
Healthcheck y observabilidad
HEALTHCHECK permite a Docker, Kubernetes o Swarm saber si tu contenedor responde. Sin él, un proceso zombie sigue apareciendo como healthy y el orquestador no le rota tráfico fuera. Usa un endpoint ligero (/health) que verifique dependencias críticas (DB, cache) y devuelva 200 rápido; evita chequeos que ejecuten queries pesadas.
Casos de uso comunes
- Migrar una app Node.js legacy a una imagen ligera y segura.
- Preparar un Dockerfile para pipelines de CI/CD reproducibles.
- Empaquetar servicios Go compilados estáticamente en imágenes scratch < 20 MB.
- Servir un SPA (React, Vue, SvelteKit) con Nginx en producción.
Buenas prácticas
- Fija versiones exactas de imagen base (node:20.11.1-alpine, no node:latest).
- Ejecuta como usuario no-root y monta volúmenes read-only cuando puedas.
- Usa .dockerignore para excluir node_modules, .git, .env y archivos de test.
- Escanea la imagen final con Trivy o Grype antes de subirla al registry.
- Firma imágenes con cosign para garantizar la cadena de suministro.