Generador de .dockerignore
Elige tu lenguaje, framework y extras para obtener un .dockerignore listo para usar. Un contexto de compilación más pequeño significa ejecuciones de docker build más rápidas, mejor caché de capas y que no se copien por accidente secretos ni node_modules en tu imagen.
Última actualización:
1. Elige las plantillas
2. Opciones
4. Tu .dockerignore
Guarda el archivo como .dockerignore junto a tu Dockerfile, en la raíz del contexto de compilación (algunos navegadores quitan el punto inicial al descargar, así que cámbiale el nombre si hace falta). A diferencia de .gitignore, los patrones se comparan desde la raíz del contexto, así que usa **/ para que coincidan a cualquier profundidad.
Cómo usar Generador de .dockerignore
- Elige una pila rápida como Next.js o Django, o haz clic en plantillas sueltas para tu lenguaje, framework y extras.
- Configura las opciones: mantén los encabezados y comentarios para que se lea mejor, o activa el modo lista de permitidos para el contexto de compilación más ajustado.
- Añade entradas personalizadas para las carpetas propias de tu proyecto, usando ! para volver a incluir un archivo.
- Comprueba una ruta como src/index.js o .env para confirmar si se envía a la compilación o se excluye.
- Copia o descarga el archivo y guárdalo como .dockerignore junto a tu Dockerfile.
Reglas de patrones de .dockerignore
Docker lee el archivo línea por línea. Las líneas que empiezan por # son comentarios, y el último patrón que coincide con una ruta decide si se excluye o se incluye.
| Patrón | Con qué coincide |
|---|---|
node_modules | Solo node_modules en la raíz del contexto, y todo lo que contiene |
**/node_modules | node_modules a cualquier profundidad, como packages/web/node_modules |
*.log | Archivos de log solo en la raíz; usa **/*.log para todas las carpetas |
docs/*.md | Archivos Markdown directamente en docs, no en sus subcarpetas |
temp? | temp1, tempA: ? es exactamente un carácter distinto de / |
*.py[cod] | Archivos .pyc, .pyo y .pyd en la raíz |
!README.md | Vuelve a incluir un archivo excluido por un patrón anterior |
* y después !src | Lista de permitidos: se excluye todo excepto la carpeta src |
Por qué importa un contexto de compilación pequeño
- Velocidad: todo el contexto se transfiere al builder antes de que se ejecute la primera instrucción. Una carpeta
node_moduleso.gitolvidada puede añadir cientos de megabytes a cada compilación. - Caché:
COPY . .se vuelve a construir cada vez que cambia cualquier archivo del contexto. Excluir logs, cachés y archivos del editor mantiene esa capa en caché mientras trabajas. - Corrección: las dependencias instaladas en tu portátil pueden estar compiladas para otro sistema operativo o CPU. Ignorar
node_modules,.venvotargetobliga a una instalación limpia dentro de la imagen. - Seguridad: los archivos
.env, las claves SSH y las credenciales de la nube del contexto pueden acabar en una capa que cualquiera con acceso de descarga puede leer.
Consejos
- Mira el tamaño de "transferring context" en la salida de
docker buildantes y después de añadir el archivo para ver cuánto ahorra. - Si una compilación falla con "file not found" después de añadir un .dockerignore, comprueba la ruta con el comprobador de arriba: un patrón amplio como
buildo**/*.mdpuede excluir un archivo que copia tu Dockerfile. - Excluye
Testssolo si tu Dockerfile no ejecuta los tests durante la compilación. - Combina este archivo con un .gitignore para el repositorio y revisa el propio Dockerfile con el Dockerfile Linter.
Preguntas frecuentes
¿Para qué sirve un archivo .dockerignore?
Cuando ejecutas docker build, la CLI envía el contexto de compilación (normalmente la carpeta actual) al builder. Los archivos que coinciden con .dockerignore quedan fuera de ese contexto, así que no pueden copiarse a la imagen con COPY o ADD, la subida es más pequeña y los cambios en los archivos ignorados no invalidan la caché de compilación.
¿En qué se diferencia .dockerignore de .gitignore?
La sintaxis parece similar, pero la coincidencia es distinta. En .dockerignore cada patrón es relativo a la raíz del contexto de compilación, así que node_modules solo coincide con la carpeta del nivel superior; usa **/node_modules para que coincida a cualquier profundidad. La barra final no tiene un significado especial, y las excepciones ! pueden volver a incluir archivos dentro de una carpeta excluida, algo que .gitignore no permite.
¿Debo ignorar el propio Dockerfile y el .dockerignore?
Puedes hacerlo. Docker sigue enviando ambos archivos al builder porque los necesita, pero no se copiarán a la imagen con COPY . . y editarlos no invalidará la caché de una capa COPY . .. La plantilla de archivos de Docker hace exactamente esto.
¿Qué es el modo lista de permitidos?
En lugar de enumerar todo lo que hay que excluir, el archivo empieza con * para ignorar todo el contexto y después vuelve a incluir solo las rutas que necesita la compilación, como !package.json y !src. Genera el contexto más pequeño posible y evita sorpresas cuando aparecen archivos nuevos, pero debes acordarte de añadir las carpetas nuevas que use la compilación.
¿Por qué hay que ignorar los archivos .env y las claves?
Cualquier cosa del contexto de compilación puede acabar en una capa de la imagen mediante COPY . ., y cualquiera que pueda descargar la imagen puede extraer sus capas fácilmente. Ignorar los archivos .env, las claves privadas y las credenciales de la nube los mantiene fuera; pasa los secretos en tiempo de ejecución o con los secret mounts de BuildKit.
¿Dónde pongo el archivo .dockerignore?
En la raíz del contexto de compilación, que es la carpeta que pasas a docker build (el . de docker build .). Con BuildKit también puedes colocar un archivo específico para un Dockerfile junto a él, con su mismo nombre, por ejemplo app.Dockerfile.dockerignore.
¿El comprobador de rutas coincide exactamente con Docker?
Sigue las reglas documentadas: los patrones se anclan a la raíz del contexto, * y ? no cruzan separadores de carpeta, ** coincide con cualquier número de carpetas, un patrón que coincide con una carpeta excluye todo lo que contiene y gana la última línea que coincide. Algunos casos poco habituales pueden diferir, así que verifica las rutas críticas con una compilación de prueba.
¿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.