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 Dockerfile
EXPOSE 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.
