Generador de Dockerfile

Genera un Dockerfile, docker-compose.yml y .dockerignore listos para producción para Node, Python, Go, PHP o un sitio estático. Multi-etapa, no-root.

🌐 English

🔒 Privado por diseño: todo se genera localmente en tu navegador; nada se sube nunca a ningún servidor.

Escrito y mantenido por Última actualización

Cómo generar un Dockerfile

  1. Elige tu lenguaje/framework: Node.js, Python, Go, PHP o un sitio estático servido por Nginx.
  2. Activa build multi-etapa, usuario no-root y una directiva HEALTHCHECK según necesites.
  3. Pulsa Generar, aparece debajo un Dockerfile completo, listo para copiar.
  4. Cambia “Qué archivo mostrar” a docker-compose.yml o .dockerignore y pulsa Generar de nuevo para ver el archivo correspondiente con las mismas opciones.
  5. Guarda cada archivo con su nombre real (Dockerfile, docker-compose.yml, .dockerignore, los dos primeros sin extensión) en la raíz de tu proyecto.

Por qué un generador visual de Dockerfile

Un Dockerfile funcional para una app real es más que una línea FROM y un CMD, acertar de verdad con uno listo para producción significa elegir una imagen base sensata, ordenar los pasos COPY/RUN para que la caché de capas de Docker realmente ayude, separar las herramientas de compilación de lo que se ejecuta en producción, y no ejecutar el contenedor como root por defecto. La mayoría de la gente parte de una entrada de blog de hace años o de un ejemplo poco relacionado y lo parchea hasta que compila, que es exactamente cómo acaban en producción imágenes sobredimensionadas, que corren como root y sin caché. Esta herramienta en cambio compone cada Dockerfile a partir de un pequeño conjunto de patrones bien conocidos y verificados para el lenguaje que elegiste, combinando solo las funciones que realmente pediste.

Qué genera realmente cada preajuste

Seguridad: ejecutar como no-root

Cada preajuste puede ejecutarse como un usuario sin privilegios en lugar de root, una buena práctica genuina, no una casilla por marcar por marcar, ya que un escape de contenedor desde un proceso root dentro del contenedor es materialmente peor que uno desde un proceso no-root. Para PHP (Apache) y el sitio estático (Nginx), hacerlo correctamente también significa mover el puerto de escucha a 8080, ya que solo root puede vincular puertos por debajo de 1024 en Linux, esta herramienta gestiona ese cambio automáticamente y mantiene coherentes EXPOSE, el HEALTHCHECK y el mapeo de puertos de docker-compose.yml entre sí.

Sin ida y vuelta al servidor, sin cuenta

Cada fragmento se genera con JavaScript normal ejecutado en tu navegador, nada se sube, no hace falta ninguna cuenta, y esta herramienta no tiene acceso a un demonio Docker real para construir o ejecutar las imágenes que describe. Eso también la hace honesta sobre sus propios límites: es un generador de sintaxis, no un validador. Ejecuta siempre docker build localmente y prueba la imagen antes de publicarla.

Usos habituales

Cómo funciona, en imágenes

Captura de pantalla de la herramienta Generador de Dockerfile con Language / framework en Node.js (Express, Next.js API, etc.), Multi-stage build (separate build stage from a slim runtime stage) en on
Generador de Dockerfile en pleno proceso: Language / framework en Node.js (Express, Next.js API, etc.), Multi-stage build (separate build stage from a slim runtime stage) en on.
Captura de pantalla del resultado de Generador de Dockerfile mostrando la salida generada «FROM node:20-alpine AS build WORKDIR /app COPY p…»
El resultado final: la salida generada «FROM node:20-alpine AS build WORKDIR /app COPY p…». El enlace de descarga es una URL blob local: el archivo nunca sale de tu dispositivo.

Preguntas frecuentes

¿El Dockerfile generado tiene garantizado que construirá y funcionará correctamente?

Está construido a partir de patrones Docker estándar y extremadamente comunes para cada lenguaje (los mismos patrones de la propia documentación oficial de imágenes de Docker y años de Dockerfiles reales ampliamente repetidos), pero esta herramienta no tiene acceso a un demonio Docker real para construirlo/probarlo por ti, todo se ejecuta en tu navegador sin ninguna ida y vuelta al servidor. Es un generador de sintaxis, no un validador, así que ejecuta siempre "docker build" localmente y prueba la imagen resultante antes de desplegarla.

¿Por qué la herramienta muestra solo un archivo a la vez?

La estructura compartida de "opciones + una caja de resultado" que usan las herramientas generadoras de este sitio solo muestra un único resultado. En lugar de forzar una página completamente distinta y a medida para esta única herramienta, la opción "Qué archivo mostrar" te deja generar el Dockerfile, el docker-compose.yml correspondiente, o un .dockerignore correspondiente uno a la vez, cambia el desplegable y pulsa Generar de nuevo para ver los otros archivos con exactamente las mismas opciones/casillas que ya elegiste.

¿Qué cambia realmente "build multi-etapa"?

Un Dockerfile multi-etapa tiene una etapa de compilación que instala todas las dependencias y compila/empaqueta tu app, y luego una segunda etapa de ejecución separada que copia solo lo necesario para ejecutarla de verdad (el resultado compilado más las dependencias solo de producción), el compilador, las herramientas de desarrollo y el árbol completo de dependencias de la etapa de compilación nunca llegan a la imagen final, que es notablemente más pequeña y tiene una superficie de ataque menor. Desactivarlo produce un Dockerfile de una sola etapa más simple que instala y ejecuta todo en una imagen, más fácil de leer, pero más pesado y envía herramientas de compilación que no necesitas en tiempo de ejecución.

¿Por qué los preajustes de PHP y sitio estático a veces usan el puerto 8080 en lugar del 80?

Vincularse al puerto 80 requiere privilegios de root en Linux, cualquier puerto por debajo de 1024 los requiere. Cuando "Ejecutar como usuario no-root" está activado para el preajuste de PHP (Apache) o de sitio estático (Nginx), el Dockerfile generado ajusta la propia configuración del servidor web para escuchar en el puerto 8080 en su lugar y ajusta la propiedad de los archivos antes de cambiar al usuario no-root, la misma técnica que usa internamente la imagen real nginx-unprivileged. Las apps de Node, Python y Go no se ven afectadas ya que sus puertos por defecto idiomáticos ya están por encima de 1024.

¿Por qué CGO_ENABLED=0 en el Dockerfile de Go?

Sin ello, "go build" puede producir un binario enlazado dinámicamente contra la librería C del host, que luego falla al ejecutarse en una imagen de ejecución Alpine mínima con un error de "no encontrado" o de librería ausente, uno de los errores más comunes en Dockerfiles reales de Go. Fijar CGO_ENABLED=0 fuerza un binario totalmente estático que se ejecuta correctamente en la pequeña etapa de ejecución Alpine (o scratch) sin nada extra instalado.

¿Esta herramienta envía mis elecciones a un servidor?

No. Cada opción que eliges se combina en texto de Dockerfile/compose/ignore usando JavaScript normal ejecutado en tu pestaña del navegador, no hay llamada a ninguna API, ni cuenta, y ningún dato sobre tu proyecto sale nunca de tu dispositivo. Eso también significa que la herramienta no puede validar ni probar-construir el resultado contra un demonio Docker real; solo puede generar texto sintácticamente estándar.

¿Puedo editar los archivos generados después?

Sí, los tres son archivos de texto normales y editables. Añade pasos RUN extra, variables de entorno, volúmenes o servicios adicionales a docker-compose.yml exactamente como lo harías con un Dockerfile escrito a mano; nada en la salida generada es especial ni tiene que quedarse tal cual.

Herramientas relacionadas