Softonic

Generador de Dockerfile

Paso 1 / 2 Dockerfile
Resultados

Un Dockerfile es una de esas archivos que parece corto hasta que recuerdas los detalles: el orden de las capas importa para el caché, COPY package.json va antes de RUN npm install, y los lenguajes compilados se benefician de un build multi-etapa. Este generador escribe un Dockerfile listo para usar con la tecnología que elijas y con el patrón de caché ya correcto.

Cómo generar un Dockerfile

  1. 1

    Elige la tecnología

    Node.js, Python, PHP, Go o Rust. Cada plantilla usa una imagen base apropiada para ese lenguaje y el comando de instalación de dependencias correcto.

  2. 2

    Configura el directorio de trabajo y el puerto

    Elige el WORKDIR y el puerto en el que escucha tu aplicación; ambos se escriben en el archivo generado.

  3. 3

    Revisa el Dockerfile

    Comprueba que la línea EXPOSE y el comando de inicio coinciden con tu aplicación. Las plantillas de Go y Rust usan un build multi-etapa.

  4. 4

    Copia el Dockerfile

    Copia el resultado y pégalo en la raíz de tu repositorio, y luego construye la imagen.

Por qué los builds multi-etapa

Un Dockerfile simple instala toda la cadena de herramientas del compilador en la imagen final. Los builds multi-etapa te dan una etapa “builder” que compila y una etapa final que solo lleva el artefacto compilado:

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
USER node
EXPOSE 3000
CMD ["node", "dist/index.js"]

La imagen final elimina todas las dependencias de desarrollo, los archivos fuente y el caché de build, y a menudo reduce el tamaño de la imagen en un 60-80 por ciento.

Variantes de imagen base

Las plantillas usan imágenes slim o alpine cuando es posible. Si ajustas la imagen base por tu cuenta, estas son las opciones típicas:

Variante Tamaño típico Cuándo elegirla
full 300-900 MB Imágenes de desarrollo, dependencias de sistema poco habituales
slim 80-200 MB Estándar de producción para la mayoría de lenguajes
alpine 30-100 MB Imágenes pequeñas, cuidado con los problemas glibc vs musl
distroless 20-80 MB Máxima seguridad; sin shell ni gestor de paquetes

Reglas del caché de capas

Docker guarda en caché cada línea; cuando una capa cambia, todo lo que está debajo se reconstruye. Orden de menor a mayor volatilidad:

  1. Imagen base FROM (casi nunca cambia).
  2. Paquetes del sistema (apt-get install), cambios poco frecuentes.
  3. Manifiestos de dependencias (package.json, requirements.txt, composer.json).
  4. Paso de instalación de dependencias. Solo se ejecuta cuando cambia el manifiesto.
  5. Copia del código fuente. La capa más activa; todo lo que va después se reconstruye en cada commit.
  6. Compilación y CMD final.

Romper este orden es la causa más común de que los builds de CI sean lentos.

Lista de verificación de seguridad

  • Ejecutar como no root. Pon USER appuser (o USER 1000) cerca del final.
  • Fijar versiones. python:3.12.7-slim supera a python:3.12, que a su vez supera a python:latest.
  • Establecer un WORKDIR explícito en lugar de depender de /.
  • Usar COPY en lugar de ADD para archivos locales; ADD tiene efectos secundarios de autoextracción.
  • Añadir un HEALTHCHECK para que los orquestadores detecten un proceso bloqueado.
  • Limpiar los cachés de paquetes en la misma línea RUN: apt-get install ... && rm -rf /var/lib/apt/lists/*.

Preguntas frecuentes

Slim es un valor predeterminado más seguro porque sigue basado en glibc, como la mayoría de las ruedas precompiladas de las bibliotecas. Alpine usa musl y a veces provoca errores de ejecución misteriosos en Python (pandas, numpy) o Node (módulos nativos de node-gyp). Elige alpine cuando el tamaño de la imagen sea crítico y hayas probado la pila.

Sí, añade uno a tu proyecto. Sin él, Docker envía todo tu repositorio al daemon como contexto de build: historial de git, node_modules, archivos .env locales, pruebas. Eso es lento, desperdicia caché y filtra secretos.

Sí. Usa docker buildx con la opción --platform para compilar para ambas arquitecturas a la vez. Las imágenes base que usan las plantillas publican variantes arm64.

No. La tecnología, el directorio de trabajo y el puerto elegidos solo se usan para generar el Dockerfile en esta página; nada se almacena ni se comparte.

Herramientas relacionadas

Referencia de la tabla ASCII

Tabla ASCII completa del 0 al 127 con decimal, hex, octal, binario y referencia numérica HTML para cada carácter, incluidos los códigos de control como NUL, LF y DEL.

Referencia de caracteres HTML

Lista buscable de entidades HTML, sus códigos nombrados y numéricos, y una copia con un clic para caracteres y símbolos especiales.

Referencia de atajos de teclado

Busca los atajos predeterminados documentados de VS Code, Chrome y Bash con GNU Readline en macOS, Windows y Linux.

Generador de letras aleatorias

Genera letras aleatorias A-Z. Elige la cantidad, usa mayúsculas, minúsculas o mezcla de ambas, y aplica el resultado en juegos, consignas o clase.

Formateador de JSON

Pega JSON para verlo con sangría de 2 o 4 espacios, minificarlo en una salida compacta o comprobar rápidamente la sintaxis antes de copiar el resultado.

Generador de Paletas de Color

Genera paletas monocromáticas, análogas, complementarias, triádicas o tetrádicas desde un color base HEX y exporta variables CSS listas para copiar.

Herramienta disponible en otros idiomas