El Build Context es la carpeta que Docker envía al motor de construcción cuando ejecutamos docker build.
Si escribes docker build -t mi-app ., pulsas Enter y la terminal se queda congelada con este mensaje:
load build definition from Dockerfile load .dockerignore load build context Transferring context: 890.50MB 25.3s
Esperas… esperas… y te preguntas: ¿Por qué tarda tanto si mi Dockerfile solo tiene 4 líneas?.
La respuesta está en cómo funciona la arquitectura de Docker. Hoy veremos el concepto llamado Build Context, y además como quitar ficheros de él con el fichero .dockerignore.
Entendiendo la arquitectura: Cliente vs Daemon
Para entender el problema, tenemos que recordar lo que vimos al principio del curso: Docker es Cliente-Servidor.
- El Cliente (CLI): Es tu terminal, donde escribes los comandos.
- El Daemon (Engine): Es el servidor que crea las imágenes y contenedores.
Cuando ejecutas:
docker build -t mi-imagen .
Ese punto final . no es decorativo. Define el contexto. Le estás diciendo al cliente: “empaqueta todo lo que hay en este directorio y envíaselo al daemon para que pueda trabajar con ello”.
El Daemon no tiene acceso a tu disco duro. Para que pueda ejecutar instrucciones como COPY . ., el Cliente primero tiene que hacer un .tar (un zip) de toda la carpeta y enviárselo por la red (o socket) al Daemon.
El error tipico es Ejecutar docker build . desde la carpeta raíz de tu usuario (C:\Users\Luis).
Docker intentará empaquetar tus Documentos, Descargas, Vídeos… Y te colgará medio PC intentando enviar todo eso al Daemon.
La Solución: .dockerignore
Al igual que en Git tenemos el archivo .gitignore para no subir basura al repositorio, en Docker tenemos el .dockerignore.
Es un archivo de texto plano que debe estar en la misma carpeta que el Dockerfile. En él, listamos los archivos y carpetas que el Cliente debe ignorar al preparar el contexto.
¿Cómo funciona?
Cuando ejecutas docker build:
- El Cliente busca el archivo
.dockerignore. - Filtra los archivos de la carpeta según esa lista.
- Empaqueta solo lo que queda y lo envía al Daemon.
El resultado: Un contexto que pasa de 1GB a 200KB
Sintaxis
La sintaxis es muy parecida a la de .gitignore.
# Ignorar dependencias locales (se instalarán dentro de la imagen)
node_modules
dist
build
# Ignorar carpeta de control de versiones
.git
.gitignore
# Ignorar archivos de entorno con claves secretas
.env
*.pem
# Ignorar archivos de sistema operativo
.DS_Store
Thumbs.db
# Ignorar logs y temporales
*.log
tmp/
Ejemplo práctico
Vamos a simularlo para que veas la diferencia real.
Crea una carpeta. Crea un archivo grande (simulando basura).
# En Linux/Mac (crea un archivo de 100MB)
dd if=/dev/zero of=archivo-grande bs=1M count=100
Crea un Dockerfile simple:
FROM alpine
COPY . /app
Ejecuta el build:
time docker build -t test-sucio .
Observa el mensaje Transferring context: 105MB. Tardará unos segundos.
Crea un archivo .dockerignore y añade:
archivo-grande
Vuelve a ejecutar el build:
time docker build -t test-limpio .
Mensaje: Transferring context: 2KB. Instantáneo.
Más allá de la velocidad: Seguridad
Usar .dockerignore no es solo una cuestión de rendimiento. Es una cuestión de seguridad.
Si haces COPY . . en tu Dockerfile y no has ignorado archivos sensibles, estarás metiendo en la imagen final:
- Archivos
.envcon contraseñas de producción. - Carpetas
.gitque contienen todo el historial de cambios (y quizás claves borradas en el pasado). - Claves SSH privadas.
Si luego subes esa imagen a Docker Hub, cualquiera podrá descargarla y extraer tus secretos, aunque no estén visibles a simple vista en la aplicación.
Añade siempre .env y .git a tu .dockerignore antes incluso de empezar a escribir el Dockerfile.
