Qué es el build context en Docker

Contenido del curso

Optimización Avanzada en Docker

Buenas Prácticas en Docker

Instalación y Configuración en Entornos Multiplataforma

Redes Avanzadas y Balanceo de Carga

Automatización de CI/CD

Orquestación

Develop

34
Dev containers en VS Code con Docker
09:54 min

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:007:46

Qué es el build context en Docker

Curso de Docker Avanzado

Clase 9 de 34

Clase 9 / 34

Recursos

El build context en Docker define el área de archivos a la que tu Dockerfile tiene acceso al construir una imagen. Entender este concepto te ayuda a crear imágenes más ligeras, seguras y listas para producción, evitando que archivos innecesarios se cuelen en tu despliegue.

Qué es el build context en Docker

Cuando ejecutas docker build, el motor de Docker no trabaja con todo tu disco: trabaja con un contexto específico que tú le indicas. Ese contexto es la carpeta donde Docker puede leer archivos para construir la imagen.

La pista está en el famoso puntito al final del comando. Ese . no es decoración: le dice a Docker dónde buscar el Dockerfile y qué archivos puede tocar.

¿Qué significa el punto en docker build? Es el indicador de la ubicación del Dockerfile y del build context. Le dice a Docker: trabaja con todo lo que esté en esta carpeta y nada más.

Cómo organizar tu proyecto con Dockerfile fuera del código

En proyectos reales no encontrarás el Dockerfile mezclado con tu código fuente. La práctica habitual es separarlo así:

Una carpeta raíz del proyecto, por ejemplo api-node.
Dentro, una carpeta src con todo el código.
En la raíz, junto a package.json y package.lock, vive el Dockerfile.

Con esa estructura, cuando ejecutas docker build desde la raíz del proyecto usando el punto, Docker tiene acceso a src, a los archivos de Node y al propio Dockerfile. Todo lo que esté dentro de api-node queda dentro de la jurisdicción del build context.

Cómo apuntar a un Dockerfile en otra carpeta

No siempre vas a parado dentro de la carpeta del Dockerfile. A veces tu terminal está un nivel arriba y necesitas señalarle a Docker dónde mirar.

En lugar del punto, puedes pasar la ruta de la carpeta. Por ejemplo, parado en build-context:

bash docker build -t aplicacion-node ./api-node

Eso le dice a Docker dos cosas a la vez: dónde está el Dockerfile y cuál es la carpeta que define el build context. Si pones solo el punto desde fuera, Docker te responderá que no encuentra el Dockerfile.

¿Para qué sirve apuntar a una carpeta específica en docker build? Sirve para acotar el área de acceso. Solo los archivos dentro de esa carpeta entran al contexto, lo que reduce peso y evita que documentos o assets innecesarios se cuelen en la imagen.

Por qué importa la regla del build context acotado

La regla es simple: todo lo necesario para construir tu imagen debe estar dentro del build context, y todo lo que sobre debería quedarse fuera. Si tienes documentación, imágenes de marketing o archivos de configuración local que no aportan a la imagen, déjalos fuera de la carpeta a la que apunta Docker.

Esto te da tres beneficios concretos:

Imágenes más ligeras porque no arrastras archivos basura.
Builds más rápidos porque Docker envía menos información al daemon.
Menor superficie de ataque al no incluir archivos sensibles por descuido.

Cómo usar EXPOSE sin abrir puertos de más

Dentro del Dockerfile de Node aparece la sentencia EXPOSE, que declara qué puerto de la imagen queda disponible por defecto al publicarla. En este caso, el puerto 3000.

Aquí va una recomendación de seguridad importante: abre solo los puertos estrictamente necesarios. Si tu app usa un único puerto, no expongas tres o cuatro por inercia. Cada puerto abierto es una puerta más por la que un atacante puede intentar entrar.

dockerfile EXPOSE 3000

Menos puertos expuestos significa una imagen menos vulnerable a ataques externos.

Pasos para construir la imagen Node con build context

Para replicar el flujo de la práctica:

Crea una carpeta contenedora, por ejemplo build-context.
Dentro, coloca tu carpeta de proyecto api-node con su src, package.json y el Dockerfile.
Muévete con cd build-context a la carpeta padre.
Ejecuta docker build -t aplicacion-node ./api-node para apuntar al Dockerfile y delimitar el contexto.
Verifica que la imagen se haya creado y revisa su tamaño.

Un detalle práctico: los nombres de imágenes en Docker deben ir en lowercase. Si usas mayúsculas, el comando fallará y tendrás que corregirlo antes de seguir.

Cómo reducir el tamaño de tu imagen Docker desde el contexto

Delimitar bien el build context es una de las palancas más directas para reducir peso. Si tu carpeta de proyecto tiene PDFs, capturas, datasets de prueba o carpetas de documentación, sácalas del contexto antes de construir.

La imagen resultante de la API de Node sigue siendo grande y necesita refactor adicional con imágenes base más ligeras, pero el primer paso siempre es el mismo: llevar a la imagen lo estrictamente necesario. Cada archivo que evitas incluir es espacio que ahorras en el registry, en el pull y en el despliegue.

¿Cómo organizas tú las carpetas de tus proyectos cuando trabajas con Docker? Cuéntame en los comentarios qué estructura te ha funcionado mejor.

Romina Toledo Benalcazar

Hace 2 años

La instrucción EXPOSE en un Dockerfile no publica el puerto, sino que simplemente informa a Docker sobre los puertos que estarán disponibles para la comunicación, pero no realiza la acción de hacerlos accesibles desde fuera del contenedor. Para exponer realmente un puerto, se debe usar la opción -p al ejecutar el contenedor.

EXPOSE es solo informativo.
-p o --publish se usa para hacer que un puerto sea accesible fuera del contenedor.

Jhonnier Isaza Gonzalez

Hace un año

Gracias por la aclaración, si es importante saber que ahí solo se informa, porque si después no se agrega en la ejecución del contenedor, el puerto no se habilitará

Leonardo Caicedo

Hace un año

Aunque EXPOSE es principalmente informativo, sí tiene un efecto cuando se usa con -P o --publish-all: en ese caso, Docker publica automáticamente los puertos definidos con EXPOSE, asignándoles puertos aleatorios (mayores a 1024) en el host.

Con -p (--publish), en cambio, se definen los puertos manualmente y EXPOSE no se tiene en cuenta.

Optimización Avanzada en Docker

Optimización avanzada de Docker para cloud native

Docker productivo vs comandos básicos

Multi-stage builds en Docker con ASP.NET

Cómo escanear vulnerabilidades en imágenes Docker

Imágenes distroless: de 840 MB a 52 MB

Imágenes Docker para múltiples arquitecturas

Cómo funciona el caché en Docker builds

De 1.19 GB a 126 MB con Alpine

Qué es el build context en Docker

Docker Hub para compartir imágenes en la nube

Buenas Prácticas en Docker

Cómo reducir capas en Docker

Cómo usar .dockerignore para imágenes más pequeñas

Limpia Docker y recupera gigas con prune

Creando usuarios en Docker sin privilegios root

6 prácticas Docker para imágenes listas para producción

Instalación y Configuración en Entornos Multiplataforma

Publica imágenes Docker en Azure Container Registry

Azure Container Registry hacia Container App

Redes Avanzadas y Balanceo de Carga

Redes en Docker: los 5 modelos explicados

Cómo funcionan los puertos en Docker

Balanceo de carga con NGINX en Docker

Automatización de CI/CD

Optimizar Dockerfile con comandos RUN y scripts

Automatiza Docker con GitHub Actions

Pruebas automáticas de Docker con GitHub Actions

Despliegue automático en Azure con GitHub Actions

Orquestación

Docker Compose: balanceo de cargas automatizado

Estructura y plantilla de Docker Compose YAML

Volúmenes Docker: bind vs nombrados

docker-compose down vs Control C en apagado

Docker Swarm para principiantes paso a paso

Despliegue Docker Swarm con réplicas de Nginx

Costos ocultos de contenedores en la nube

Cómo habilitar Kubernetes en Docker Desktop

Planes y límites de Docker Hub en producción

Develop

Dev containers en VS Code con Docker

Qué es el build context en Docker