Generador de Dockerfile
Elige tu stack y tus opciones para obtener un Dockerfile listo para producción que sigue las buenas prácticas actuales: builds multi-stage, capas de dependencias en caché, un usuario no root y un health check opcional. También se generan un .dockerignore a juego y los comandos de build y run.
Última actualización:
Archivos generados
Cómo usar Generador de Dockerfile
- Elige un stack: Node.js, Python, Go o un sitio estático servido por nginx.
- Elige la versión y la variante de imagen base (alpine, slim, distroless) y tu gestor de paquetes o archivo de dependencias.
- Define los datos de la app: directorio de trabajo, puerto, comando de inicio, variables de entorno y una ruta de health check opcional.
- Activa las buenas prácticas como el build multi-stage, el usuario no root y los cache mounts de BuildKit.
- Copia o descarga el Dockerfile y el .dockerignore en la raíz de tu proyecto y ejecuta el comando docker build que se muestra.
Referencia de instrucciones de Dockerfile
| Instrucción | Qué hace | Consejo |
|---|---|---|
FROM image AS name | Inicia una etapa de build a partir de una imagen base. | Fija una etiqueta de versión (node:24-alpine); nunca dependas de latest. |
WORKDIR /app | Define (y crea) el directorio de trabajo para los pasos siguientes. | Úsalo en lugar de RUN cd …. |
COPY src dest | Copia archivos desde el contexto de build o, con --from=stage, desde otra etapa. | Añade --chown=user:group para que un usuario no root pueda escribir. |
RUN command | Ejecuta un comando y guarda el resultado como una capa nueva. | Combina comandos relacionados con && para mantener las capas pequeñas. |
ENV KEY=value | Define variables de entorno para los pasos siguientes y para el contenedor en ejecución. | Nunca incluyas secretos; quedan en el historial de la imagen. |
EXPOSE 3000 | Documenta el puerto en el que escucha la app. | Para publicarlo sigue haciendo falta -p host:container. |
USER name | Ejecuta los pasos siguientes y el contenedor con este usuario. | Ponlo después de los pasos que necesitan root (instalación de paquetes). |
HEALTHCHECK CMD … | Permite a Docker marcar el contenedor como saludable o no saludable. | El comando debe existir en la imagen (las imágenes slim no tienen curl). |
CMD ["exe","arg"] | Comando predeterminado, reemplazado por los argumentos de docker run. | Usa la forma exec en JSON para que las señales lleguen a tu app. |
ENTRYPOINT ["exe"] | Ejecutable fijo; CMD y los argumentos de run se añaden a continuación. | Ideal para imágenes de un solo binario, como las apps de Go. |
Tamaños típicos de imagen según la base
Tamaños comprimidos aproximados de las imágenes base en Docker Hub (tu app y sus dependencias se suman encima). Lo importante es el orden de magnitud: elegir la base de ejecución importa más que casi cualquier otra optimización.
| Imagen base | Tamaño aprox. | Ideal para |
|---|---|---|
gcr.io/distroless/static-debian12 | ~2 MB | Binarios estáticos de Go o Rust |
alpine:3.22 | ~4 MB | Imágenes diminutas que aún necesitan un shell |
nginx:1.28-alpine | ~20 MB | Sitios estáticos y SPA |
node:24-alpine | ~55 MB | Apps de Node sin módulos nativos complicados |
python:3.13-slim | ~45 MB | La mayoría de las apps web de Python |
node:24-slim | ~75 MB | Apps de Node que necesitan glibc |
golang:1.26 / node:24 (full) | 300 MB+ | Solo etapas de build, no la imagen final |
Lista de comprobación para una imagen lista para producción
- Ordena las capas de la que menos cambia a la que más: imagen base, paquetes del sistema, manifiestos de dependencias, instalación de dependencias y luego el código fuente.
- Usa un archivo de bloqueo y un comando de instalación limpia (
npm ci,pnpm install --frozen-lockfile,requirements.txtcon versiones fijadas) para que los builds sean reproducibles. - Mantén los secretos fuera del contexto de build con
.dockerignore, y pásalos al ejecutar o conRUN --mount=type=secret. - Ejecuta como no root y da a ese usuario la propiedad solo de lo que debe escribir.
- Gestiona SIGTERM: inicia tu proceso directamente en forma exec, o añade
--initadocker runsi tu app crea procesos hijos. - Analiza y recompila con regularidad (por ejemplo con
docker scout cves) para incorporar los parches de seguridad de la imagen base.
Preguntas frecuentes
¿Qué es un build multi-stage de Docker?
Un Dockerfile con varias instrucciones FROM. Las primeras etapas instalan compiladores y dependencias de desarrollo y compilan la app; la etapa final parte de una imagen base pequeña y copia solo el resultado compilado. El resultado es una imagen más pequeña y segura, sin herramientas de compilación.
¿Por qué ejecutar el contenedor con un usuario no root?
Si un atacante entra en la app, un proceso no root tiene muchos menos privilegios dentro del contenedor y en el host. La imagen oficial de node incluye un usuario node, las imágenes distroless ofrecen una etiqueta nonroot y, para otras imágenes, el generador crea un usuario dedicado.
¿Por qué copiar package.json antes que el resto del código?
Docker guarda en caché cada capa. Copiar primero solo los manifiestos de dependencias y el archivo de bloqueo hace que el lento paso de instalación se reutilice desde la caché hasta que cambien tus dependencias, así que los cambios solo de código se recompilan en segundos.
Alpine, slim o distroless: ¿qué base debo usar?
Alpine es la más pequeña, pero usa musl libc, lo que puede romper algunos módulos nativos y wheels de Python. Debian slim es una opción predeterminada segura y compatible. Las imágenes distroless solo contienen tu app y su runtime, sin shell ni gestor de paquetes, lo que es ideal para binarios estáticos de Go.
¿Qué hace .dockerignore?
Enumera los archivos que Docker no debe enviar al contexto de build, como node_modules, .git, archivos .env locales y la salida de compilación. Así los builds son más rápidos, se evita filtrar secretos en las imágenes y se impide que las dependencias compiladas en el host sobrescriban las instaladas en el contenedor.
¿EXPOSE publica el puerto?
No. EXPOSE solo documenta en qué puerto escucha la app. Aun así tienes que publicarlo al ejecutar con docker run -p 8080:3000 o con la sección ports de docker-compose.
¿Cuál es la diferencia entre CMD y ENTRYPOINT?
CMD define el comando predeterminado, que se reemplaza por los argumentos que pases a docker run. ENTRYPOINT define el ejecutable que siempre se ejecuta, y CMD o los argumentos de run se añaden a él. Usa la forma exec en JSON para que señales como SIGTERM lleguen a tu proceso.
¿Se prueban todas las herramientas de FreeToolCabin para comprobar su calidad y precisión?
Sí. Cada herramienta del sitio pasa pruebas automáticas en navegadores reales para comprobar que el resultado es correcto y que no hay errores. Si encuentras un fallo o tienes una sugerencia, escríbenos a [email protected] y lo revisaremos.