Optimiza tu imagen de Docker para producción controlando el build context. Al delimitar qué archivos puede “tocar” Docker durante el build, reduces peso, evitas arrastrar recursos innecesarios y mantienes un flujo claro de despliegue. Aquí verás cómo organizar carpetas, cuándo usar el punto y cuándo una ruta, y por qué abrir solo los puertos necesarios.
¿Qué es el build context y por qué importa en Docker?
El build context define la “jurisdicción” de todo lo que Docker puede acceder al construir una imagen. Si apuntas al directorio correcto, Docker solo verá los archivos que realmente necesitas. Esto es clave para no incluir documentos, imágenes u otros recursos que no forman parte de la imagen final.
Delimita el acceso: solo lo necesario entra al build.
Reduce el tamaño: evita peso extra innecesario.
Control explícito: especifica la carpeta donde está el Dockerfile y los archivos que Docker puede tocar.
¿Qué archivos puede tocar Docker durante el build?
Depende de la carpeta que indiques al ejecutar el comando. Si usas el punto, Docker verá todo lo que hay en el directorio actual. Si indicas una ruta, verá solo esa carpeta y su contenido. Archivos comunes en proyectos de Node como package.json, package-lock.json y la carpeta src quedarán disponibles solo si están dentro del contexto.
¿Cómo organizar carpetas y el Dockerfile para un build limpio?
Una organización típica: el código dentro de una carpeta src y el Dockerfile en la raíz del proyecto (por ejemplo, dentro de “API Note”). Esta separación es común en proyectos reales y facilita definir qué entra al build context.
Coloca el Dockerfile fuera de src y en la raíz del servicio.
Incluye en el contexto solo lo que la imagen necesita.
Deja fuera del contexto todo lo que no quieras empaquetar.
¿Qué pasa si mueves el Dockerfile de carpeta?
Si el Dockerfile se mueve fuera de “API Note” y lo colocas en “Build Context”, entonces, al construir desde ahí, Docker podría ver más archivos de los necesarios. La regla práctica: decide el contexto desde el que harás el build y ubica el Dockerfile donde tenga acceso únicamente a lo indispensable.
¿Por qué abrir solo puertos necesarios con EXPOSE?
La instrucción EXPOSE declara el puerto que expondrá la imagen, por ejemplo el 3000 en Node. Abre únicamente los puertos estrictamente necesarios para evitar exposición innecesaria.
# Dentro del DockerfileEXPOSE 3000
Abre solo el puerto que vas a usar.
Evita declarar múltiples puertos si no se utilizarán.
¿Cómo construir la imagen: punto o ruta del contexto?
En la terminal, el punto indica “construye usando el directorio actual como build context”. Si el Dockerfile no está ahí, especifica la carpeta donde sí vive el archivo.
Si el Dockerfile está en el directorio actual:
docker build -t aplicacion-node .
Si el Dockerfile está en otra carpeta (ejemplo: “API Note”):
docker build -t aplicacion-node API Note
Usa nombres de imagen en minúscula para evitar errores.
Al indicar la carpeta, limitas explícitamente qué puede “tocar” Docker.
Evita llevar recursos innecesarios que aumenten el tamaño de la imagen.
Nota práctica: tras el build, la aplicación de Node queda creada. Si es “enorme”, considera refactorizar más adelante para optimizar peso de la imagen.
¿Te quedaste con dudas sobre estructurar tu build context o sobre el uso de EXPOSE? Comenta tu caso y lo revisamos juntos.
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.
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á
Aunque EXPOSE es principalmente informativo, sí tiene un efecto cuando se usa con-Po--publish-all: en ese caso, Docker publica automáticamente los puertos definidos conEXPOSE, 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.
Si queremos ser más específicos, también existe el archivo .dockerignore que nos permite ignorar directorios o archivos que estén en la misma carpeta del Dockerfile.
Esto puede ser útil si son archivos específicos y así evitamos que formen parte del BuildContext.
El Build Context en Docker te permite especificar desde dónde Docker accederá a los archivos para construir una imagen. Delimita qué archivos y carpetas Docker puede "tocar". Esto es crucial para incluir solo lo necesario y reducir el tamaño final de la imagen.
EXPOSE es informativo; -p publica el puerto.
Que pasa si por ejemplo existe una archivo .zip en el Build Context? Este tambien fomaria parte de mi imagen luego?
¡Hola, Micael! Buena pregunta.
Aquí hay una distinción clave: disponibilidad no es inclusión.
Cuando ejecutas docker build, el "Build Context" es simplemente el paquete de archivos que envías al motor de Docker para que trabaje. Si tienes un .zip ahí, el motor lo ve, pero eso no significa que termine dentro de tu imagen final.
Tu imagen solo contendrá lo que tú le digas explícitamente mediante las instrucciones COPY o ADD en tu Dockerfile. Si no haces referencia a ese archivo, el .zip se queda en el contexto pero nunca toca el sistema de archivos de tu contenedor.
Dicho esto, si ese archivo es pesado, lo mejor es usar un .dockerignore para ni siquiera enviarlo al daemon. ¿Te imaginas por qué querrías excluirlo aunque no lo vayas a copiar?
Se supone que el build context es un tema elemental que se debió dar en los fundamentos
