¿Odias los anuncios? Ir Sin publicidad Hoy 

Generador de Dockerfile

Desarrollador

ANUNCIO · ¿ELIMINAR?

APORTE

Proceso automático

Pila

Etiqueta de imagen

La etiqueta añadida después del nombre de la imagen (image:TAG).

Imagen base

Referencia completa de la imagen incluyendo etiqueta.

WORKDIR

Argumentos de construcción

Variables de construcción. Cada línea se convierte en una instrucción ARG.

Variables de entorno

Variables de ejecución. Cada línea se convierte en una instrucción ENV.

Paquetes del sistema

Instalados mediante apk/apt-get según la imagen base. Deje vacío para omitir.

Archivos de dependencias

Copiados primero para una mejor caché de capas de Docker.

Comando de instalación

Se ejecuta después de que se copien los archivos de dependencias.

Comando de construcción

Opcional. Se ejecuta después de que se copie el código completo.

Exponer puertos

Puertos TCP separados por comas.

Usuario no root

Opcional. Establece el usuario para la ejecución.

HEALTHCHECK

Opcional. Comando en shell que se ejecuta dentro del contenedor.

Intervalo de HEALTHCHECK

Forma ejecutiva (recomendada)

Forma en shell

CMD

Proceso predeterminado cuando el contenedor inicia.

ENTRYPOINT

Opcional. Utilice cuando CMD solo proporcione argumentos.

PROD.

Lado cliente

ANUNCIO · ¿ELIMINAR?

Guía

Generador de Dockerfile

Crea un Dockerfile listo para producción en segundos. Elige una pila como Node.js, Python, Go, OpenJDK, Ruby, PHP, Rust, .NET, Nginx, Alpine, Ubuntu o Debian y el generador establece valores razonables por defecto para la imagen base, variables de entorno, archivos de dependencias, comando de instalación, puerto expuesto y usuario de ejecución. Ajusta cualquier campo y el Dockerfile se actualiza instantáneamente con las instrucciones en orden de capas recomendadas.

Cómo Usar

Elige una pila del menú desplegable. El nombre de la imagen, la etiqueta, las variables de entorno, los archivos de dependencias y el CMD se rellenan con valores por defecto probados.
Ajusta la etiqueta de la imagen, WORKDIR, argumentos de construcción y variables de entorno de ejecución para que coincidan con tu proyecto.
Lista cualquier paquete del sistema que necesites (uno por línea). El generador los instala con apk en imágenes Alpine y con apt-get en imágenes de Debian.
Establece los archivos de dependencias que deben copiarse primero para la caché de capas, el comando de instalación que sigue y un comando de construcción opcional.
Configura los puertos expuestos, un usuario no root, un HEALTHCHECK opcional y elige entre forma ejecutiva o en shell para el CMD o ENTRYPOINT final.
Copia el Dockerfile generado o descárgalo directamente a la raíz de tu proyecto.

Características

Preestablecimientos de pila – un clic semilla Node, Python, Go, OpenJDK, Ruby, PHP, Rust, .NET, Nginx, Alpine, Ubuntu, Debian o una imagen personalizada.
Orden de capas recomendado – FROM, ARG, WORKDIR, ENV, paquetes del sistema, copia de dependencias + instalación, copia del código fuente, construcción, EXPOSE, USER, HEALTHCHECK, luego ENTRYPOINT/CMD.
Amigable con la caché de capas – copia los manifestos de dependencias antes del resto del código fuente para que los rebuilds omitan la reinstalación de dependencias cuando cambia el código.
Consciente del gestor de paquetes – emite apk add --no-cache para bases Alpine y una sola capa limpiada apt-get update && install para bases de Debian.
Forma ejecutiva o en shell – CMD y ENTRYPOINT se renderizan como un array JSON (recomendado) o como una cadena literal de shell.
Ayudante de HEALTHCHECK – intervalo configurable con tiempos razonables por defecto, periodo de inicio y número de intentos.
Regeneración en tiempo real – cada cambio actualiza el resultado sin necesidad de hacer clic en un botón de generación. Copia o descarga el resultado con un solo toque.

 Preguntas frecuentes

¿Por qué importa el orden de las instrucciones del Dockerfile?

Docker cachea cada instrucción como una capa inmutable clave por sus entradas. Cuando cambia una capa, todas las capas por debajo deben reconstruirse. Colocar instrucciones que cambian raramente, como FROM, ENV y la instalación de dependencias, cerca del principio y las copias del código fuente y las construcciones cerca del final, permite a Docker reutilizar las capas costosas de configuración en la mayoría de los reconstrucciones y solo reconstruir las últimas capas económicas.
¿Cuál es la diferencia entre la forma ejecutiva y la forma en shell del CMD?

La forma ejecutiva es un array JSON (por ejemplo, ["node", "server.js"]) que Docker ejecuta directamente con execve, por lo que el proceso se convierte en el PID 1 y recibe señales como SIGTERM de forma limpia. La forma en shell es una cadena única que Docker envuelve con /bin/sh -c, que añade una shell como PID 1, absorbe las señales y rompe el cierre graciosamente. La forma ejecutiva es la recomendación por defecto para servicios de larga duración.
¿Por qué copiar package.json o requirements.txt antes del resto del código fuente?

La instalación de dependencias suele ser el paso más lento en una construcción. Al copiar solo el manifest y el archivo de bloqueo primero, y luego ejecutar la instalación, Docker puede cachear esa capa y reutilizarla en cada construcción hasta que esos archivos cambien. Copiar todo el código fuente primero invalidaría la capa de instalación en cada edición de código, forzando una reinstalación completa cada vez.
¿Por qué ejecutar como un usuario no root dentro del contenedor?

Por defecto, los procesos dentro de un contenedor se ejecutan como root. Si un atacante explota un fallo en tu aplicación, hereda root dentro del contenedor, lo que amplía el alcance del ataque. Cambiar a un usuario dedicado y no privilegiado con USER reduce lo que puede leer, escribir o escalar el código malicioso, y es una exigencia básica para muchos entornos de producción y políticas de seguridad de contenedores en Kubernetes.
¿Qué hace realmente el HEALTHCHECK?

HEALTHCHECK indica a Docker qué comando ejecutar periódicamente para decidir si el contenedor está saludable. El resultado se expone mediante docker inspect y se consume por orquestadores y balanceadores de carga para bloquear tráfico, reiniciar contenedores no saludables y marcar despliegues como fallidos. Un buen chequeo ejecuta la misma ruta de código que utilizan los clientes reales, responde rápidamente y se ejecuta con frecuencia suficiente para detectar fallos antes de que los usuarios los noten.