En la lección anterior aprendiste de dónde vienen las imágenes: un registro, un repositorio, una etiqueta que apunta a un digest. Y reservaste la dirección donde vivirá la tuya, auroralibros/aurora-api. Ahora toca fabricarla. Esta lección trata del proceso de construcción en sí: qué hace docker build desde que pulsas Enter, qué es ese punto final que todo el mundo copia sin saber qué significa, por qué una carpeta con node_modules dentro puede convertir una build de dos segundos en una de dos minutos, y cómo la caché de capas de BuildKit premia o castiga el orden en que escribes las instrucciones. No vas a estudiar todavía el Dockerfile instrucción por instrucción —eso es la lección siguiente—, sino la máquina que lo interpreta. Al terminar tendrás auroralibros/aurora-api:0.1.0 construida, corriendo en un contenedor y respondiendo a un curl.

1. Qué hace docker build realmente
2. Anatomía del comando y el punto final
3. El contexto de construcción
4. El fichero .dockerignore
5. Dockerfiles con otro nombre o ruta: la opción -f
6. La caché de capas de BuildKit
7. Dependencias antes que código: ineficiente frente a eficiente
8. --no-cache y --pull: cuándo desconfiar de la caché
9. Leer la salida de BuildKit
10. De cero a imagen: auroralibros/aurora-api:0.1.0

Recuerda la arquitectura cliente-servidor de la lección 01-03: el cliente docker no hace el trabajo, se lo pide al demonio. La construcción de imágenes sigue ese mismo esquema, con un actor más. Desde Docker Engine 23, el constructor por defecto es BuildKit, un motor de construcción independiente y mucho más capaz que el clásico.

Tres consecuencias prácticas de este diagrama que conviene interiorizar antes de seguir:

1. La build no ocurre en tu directorio de trabajo. Ocurre en el constructor, que puede estar en otra máquina. Por eso hay que enviarle los ficheros: es el contexto del apartado 3.
2. BuildKit construye un grafo, no una lista. No ejecuta las instrucciones ciegamente de arriba abajo: calcula qué pasos dependen de cuáles y salta los que ya tiene resueltos. De ahí la potencia de la caché.
3. La imagen resultante se queda en tu almacén local. docker build no publica nada en ningún registro; eso es docker push, y llega en la lección 02-06.

Te encontrarás las dos formas y conviene aclararlas ya:

Para todo lo de este módulo son equivalentes: docker build es más corto y es lo que usarás. Las capacidades exclusivas de buildx —construir para varias arquitecturas a la vez, montajes de caché, secretos de build— se ven en la lección 05-05. Puedes comprobar qué constructor estás usando:

El asterisco marca el constructor activo. BUILDKIT v0.19.0 confirma que BuildKit está en marcha; si esa columna estuviera vacía, estarías con el constructor antiguo y no verías nada de lo que se describe en esta lección.

La forma canónica es:

Desmenuzada:

El punto final es la parte que más confusión genera. No significa "construye aquí" ni "usa el Dockerfile de este directorio", aunque por defecto produzca ambos efectos. Significa: el contexto de construcción es el directorio actual. Es decir, "envía al constructor todo lo que hay en . (menos lo ignorado), porque las instrucciones COPY van a buscar sus ficheros ahí dentro".

Se ve mejor con variantes:

La última forma es reveladora: el contexto ni siquiera tiene que estar en tu máquina. BuildKit puede clonar un repositorio y construir desde ahí. Eso demuestra que el contexto es un concepto abstracto ("el conjunto de ficheros disponibles para la build"), no "la carpeta donde estás".

Otras opciones de docker build que usarás en este módulo:

Antes de ejecutar ninguna instrucción, el cliente empaqueta el contexto y se lo envía al constructor. Esto es importante porque todo lo que hay en ese directorio viaja, lo uses o no en algún COPY.

Comprueba el tamaño de tu contexto antes de construir. Es un hábito que vale su peso en oro:

Veintitrés megas para un server.js de 100 líneas y un package.json. ¿De dónde salen?

Ahí está: node_modules, generado cuando hiciste npm install en la lección 01-07. Y esos 23 MB no aportan nada a la imagen, porque las dependencias se instalarán dentro de ella con npm ci.

Consecuencias de un contexto grande:

• La build es más lenta, y el retraso está antes de la primera instrucción: el cliente debe leer, comprimir y transmitir todos esos ficheros. En un proyecto con .git de 500 MB, esto son varios segundos en cada build.
• Riesgo de filtración. Un COPY . . descuidado mete en la imagen todo lo que haya en el contexto, incluidos ficheros .env, claves SSH o volcados de base de datos. Es un incidente de seguridad real, no teórico.
• Rompe la caché. Como verás en el apartado 6, la caché de un COPY . . se invalida si cualquier fichero del contexto cambia. Con node_modules dentro, un npm install local invalida la build entera.

Este error lo vas a cometer, así que mejor entenderlo ahora. Supón que desde ~/aurora-libros/api intentas copiar el init.sql que está en ~/aurora-libros/db/:

El mensaje despista porque habla de "not found", pero el fichero existe perfectamente en tu disco. Lo que ocurre es que no existe en el contexto: como el contexto es . (o sea, api/), el constructor solo ha recibido lo que hay dentro de api/, y ../db/ está fuera. Las rutas de origen de COPY son siempre relativas a la raíz del contexto y jamás pueden salir de él. Es una restricción de seguridad deliberada: si no fuera así, cualquier Dockerfile podría copiar /etc/shadow o ~/.ssh/id_rsa de la máquina que construye.

Las dos soluciones legítimas:

Para Aurora Libros elegiremos la opción de contexto reducido: la imagen de la API no necesita init.sql, que es cosa del contenedor de PostgreSQL (módulo 3). Cada imagen lleva solo lo suyo.

En la lección 01-07 quedó anunciado: la imagen de la API tendrá un .dockerignore que excluya node_modules/, .git/ y .env. Es el momento de escribirlo.

.dockerignore es un fichero de texto en la raíz del contexto que le dice al cliente qué no debe enviar al constructor. Su sintaxis recuerda a .gitignore, pero tiene reglas propias:

Dos diferencias con .gitignore que causan sorpresas:

• node_modules no es recursivo por sí solo, a diferencia de Git. Si tienes subproyectos con sus propias dependencias, necesitas **/node_modules.
• El orden importa cuando usas !: la última regla que coincide es la que manda.

Crea ~/aurora-libros/api/.dockerignore:

Justificación de las entradas menos evidentes:

• node_modules: la razón principal. Además del tamaño, copiar el node_modules de tu máquina puede meter binarios compilados para tu sistema operativo y arquitectura que no funcionen dentro de una imagen Alpine (es exactamente el aviso del ejercicio 3 de 01-07).
• .env: la regla innegociable del proyecto. Las credenciales no entran en la imagen. Un .dockerignore que lo excluya es la primera línea de defensa frente a un COPY . . descuidado.
• Dockerfile: no hace falta dentro de la imagen. Excluirlo tiene un efecto secundario muy útil: editar el Dockerfile ya no invalida la caché del COPY . ..
• README.md, test/: no se ejecutan en producción, y cada byte que no entra es un byte que no se descarga en cada despliegue.

La forma limpia de comprobar el efecto es con --progress=plain, que muestra la línea de transferencia del contexto. Primero, sin .dockerignore:

Ahora con él:

De 23,41 MB a 47,83 kB: una reducción de más del 99 %, y el tiempo de transferencia baja de 1,8 segundos a prácticamente cero. En un proyecto real con .git voluminoso, artefactos de compilación y capturas de pantalla, la diferencia se mide en cientos de megas y decenas de segundos en cada build.

Por defecto, docker build busca un fichero llamado exactamente Dockerfile en la raíz del contexto. -f rompe ese acoplamiento:

Puntos clave:

• -f y el contexto son independientes. Puedes tener el Dockerfile en cualquier sitio y el contexto en otro. Lo que nunca cambia es que las rutas de COPY se resuelven contra el contexto, no contra la ubicación del Dockerfile. Es la confusión número uno con -f.
• La ruta de -f sí es relativa a tu directorio actual, no al contexto.
• El caso de uso más común es tener variantes: Dockerfile para producción y Dockerfile.dev con herramientas de desarrollo. Aurora Libros usará un único Dockerfile; las diferencias entre entornos se resolverán con Compose (lección 04-06), que es un enfoque más limpio.

Aquí está la diferencia entre esperar noventa segundos en cada cambio de código o esperar dos. Recuerda de la lección 01-05 que una imagen es una pila de capas. Durante la construcción, cada instrucción del Dockerfile que modifica el sistema de archivos produce una capa, y BuildKit intenta reutilizar las que ya tiene.

Para cada instrucción, BuildKit calcula una clave de caché a partir de:

1. La clave de la capa anterior (por eso el orden lo es todo).
2. El texto literal de la instrucción. Cambiar un espacio o un comentario dentro de un RUN la invalida.
3. Para COPY y ADD, además, el checksum del contenido de los ficheros copiados (no la fecha de modificación: si tocas un fichero sin cambiar su contenido, la caché aguanta).

Si esa clave existe en la caché local, marca el paso como CACHED y no ejecuta nada. Si no existe, ejecuta el paso y todos los posteriores, sin excepción.

Esta es la propiedad que gobierna el diseño de todo Dockerfile:

Si cambias una línea de server.js, se invalida el COPY . . (paso E) y, en cascada, todo lo que viene después. Pero los pasos A–D siguen cacheados, incluido el npm ci de 45 segundos. Resultado: la build tarda un par de segundos.

Ahora invierte el orden —copia el código antes de instalar dependencias— y el mismo cambio en server.js invalida el COPY . ., que ahora está antes del npm ci. Consecuencia: el npm ci se vuelve a ejecutar entero. Cuarenta y cinco segundos, en cada cambio de una coma.

De ahí la regla de oro: ordena las instrucciones de menos a más volátil. Lo que casi nunca cambia (la imagen base, la instalación de paquetes del sistema, las dependencias) va arriba; lo que cambias cincuenta veces al día (tu código) va abajo.

Vamos a medirlo, porque el número convence más que la explicación.

Parece razonable: copio el proyecto y luego instalo. Y funciona. El problema es que COPY . . incluye server.js, así que cualquier cambio en el código invalida esa capa y, con ella, el npm ci.

La diferencia es un COPY partido en dos. Primero se copian solo los manifiestos de dependencias, se instalan, y después se copia el resto del código. Como package.json y package-lock.json cambian rara vez, el npm ci queda cacheado casi siempre.

Guarda cada versión en su fichero y cronometra el ciclo realista: primera build en frío, y segunda build tras tocar el código.

Resultados típicos en una máquina de desarrollo:

Lee la tabla con atención, porque contiene los tres mensajes de la lección:

• En frío son iguales (la eficiente incluso un pelín más lenta, por tener un COPY más). La caché no acelera la primera vez.
• Tras un cambio de código, la diferencia es de 33×. Multiplícalo por cincuenta builds al día y por cada persona del equipo de Aurora Libros: son horas.
• Tras cambiar las dependencias, vuelven a igualarse, y es lo correcto: si package.json cambia, hay que reinstalar. La caché no está mintiendo, está haciendo su trabajo.

Un matiz sobre npm ci que justifica su uso frente a npm install, y que en la lección 02-03 se retoma: npm ci borra node_modules e instala exactamente las versiones fijadas en package-lock.json, fallando si el lock y el package.json no concuerdan. npm install puede resolver versiones distintas según cuándo se ejecute, lo que rompe la reproducibilidad. En una imagen, siempre npm ci.

La caché es una optimización basada en una suposición: que la misma instrucción con las mismas entradas produce el mismo resultado. A veces esa suposición es falsa.

Cuándo usar cada una:

El caso de --pull merece una explicación aparte, porque es sutil. Si tu Dockerfile dice FROM node:22-alpine y ya tienes esa etiqueta descargada, BuildKit la usa sin comprobar si ha cambiado en el registro. Pero 22-alpine es una etiqueta móvil (lección 02-01): Node publica parches y esa etiqueta pasa a apuntar a otro digest. Sin --pull, puedes estar construyendo durante meses sobre una base con vulnerabilidades ya corregidas aguas arriba. Por eso --pull es prácticamente obligatorio en los pipelines de construcción (lección 06-02).

Y un aviso: --no-cache no borra la caché existente, solo la ignora en esa build. Para liberar el espacio que ocupa realmente hay un comando específico, docker builder prune, que verás en la lección 02-05.

BuildKit imprime una interfaz dinámica que se reescribe en el sitio. Aprender a leerla es aprender a diagnosticar builds.

Clave de lectura, línea a línea:

El diagnóstico se hace mirando dónde deja de aparecer CACHED. Ese es el punto de invalidación, y todo lo que hay debajo se ha reejecutado. Si el primer paso no cacheado es antes de lo que esperabas, tienes un problema de orden de instrucciones o un fichero volátil colándose en un COPY.

La interfaz dinámica es cómoda pero oculta la salida de los comandos: no ves lo que imprime npm ci. Cuando algo falla, necesitas verlo todo:

El formato es #<paso> <segundos desde el inicio del paso> <línea de salida>. Esos tiempos relativos son oro puro para saber qué parte de un RUN largo es la lenta. Tres usos habituales de --progress=plain:

• Ver por qué falla un RUN (el mensaje de error completo del comando).
• Medir el tamaño del contexto, como hiciste en el apartado 4.
• Guardar un registro completo en CI, donde la interfaz dinámica produce basura ilegible.

Es el momento de juntarlo todo. Vas a construir la primera imagen de Aurora Libros con un Dockerfile mínimo, presentado entero. Aquí solo se explica por encima qué hace cada instrucción; el detalle completo, las alternativas y las decisiones finas son la lección 02-03.

Crea ~/aurora-libros/api/Dockerfile:

Un vistazo rápido a cada instrucción, sin entrar en profundidad:

• # syntax=docker/dockerfile:1: elige el intérprete de Dockerfile más reciente de la serie 1.
• FROM: de qué imagen se parte.
• WORKDIR: fija el directorio de trabajo dentro de la imagen y lo crea si no existe.
• COPY: trae ficheros del contexto a la imagen. Está partido en dos por lo del apartado 7.
• RUN: ejecuta un comando durante la construcción y congela el resultado en una capa.
• ENV: define variables de entorno que persisten en ejecución.
• EXPOSE: documentación. No publica el puerto; eso sigue siendo cosa de -p (lección 01-06).
• CMD: qué proceso arranca el contenedor.

Si te preguntas por qué npm ci y no npm install, por qué esa forma de CMD con corchetes, o por qué EXPOSE no hace lo que su nombre sugiere: todo eso es exactamente el contenido de la lección 02-03.

Comprueba el resultado:

167 MB, de los cuales unos 142 son la base node:22-alpine que ya conocías. Tu aplicación y sus dependencias aportan unos 25 MB.

Todo CACHED, 0,4 segundos. De 13,7 s a 0,4 s sin cambiar nada.

Comandos ya conocidos de 01-06: -d en segundo plano, --name para poder referirte a él, -p 3000:3000 para publicar el puerto. Mira los registros:

La API ha arrancado dentro de un contenedor, sin que hayas instalado Node en tu máquina. Pruébala:

El endpoint responde (HTTP 503), que es lo que queríamos comprobar: el proceso vive, Express escucha y la ruta funciona. Pero db y cache están en ko con los mismos ECONNREFUSED de la lección 01-07, y ahora por una razón nueva y muy instructiva: localhost dentro del contenedor es el propio contenedor, no tu máquina. Ahí dentro no hay ningún PostgreSQL ni ningún Redis escuchando, y por eso la conexión se rechaza. Aunque tuvieras los servicios corriendo en tu portátil, el contenedor no los vería con esa configuración.

Y /libros, que sí necesita la base de datos:

Exactamente lo esperado. Este fallo no es un error tuyo: es el siguiente problema del curso. Conectar contenedores entre sí mediante redes propias, para que DB_HOST=aurora-db signifique algo, es el contenido de la lección 03-05; y darle a PostgreSQL un volumen donde guardar el catálogo, el de la 03-06.

Limpia antes de seguir:

La imagen se queda en tu almacén local para las lecciones siguientes. Un balance de lo conseguido: de los quince pasos manuales de la lección 01-07, los pasos 2, 3, 4 y 5 (descubrir la versión de Node, instalar nvm, instalar Node 22, ejecutar npm install) han desaparecido. Cualquiera con Docker puede ejecutar tu API sin instalar nada relacionado con Node.

• Creer que el punto final significa "aquí está el Dockerfile". Significa "este es el contexto". Son cosas separadas, y -f lo demuestra. En cuanto lo interiorizas, la mitad de los errores de COPY desaparecen.
• COPY ../algo desde fuera del contexto. Nunca funcionará, por diseño. Amplía el contexto y usa -f, o reorganiza los ficheros. Si te ves peleando con esto, casi siempre es señal de que la imagen está intentando llevar dentro algo que no le corresponde.
• Olvidar el .dockerignore. Contexto lento, imágenes hinchadas, caché que se invalida sola y riesgo real de filtrar un .env. Escríbelo antes del primer docker build, no después.
• COPY . . antes de instalar dependencias. Es el error de rendimiento más caro y más frecuente. Dependencias arriba, código abajo.
• Confiar en que la caché "detecta" cambios remotos. Un RUN apk add curl cacheado seguirá instalando la versión de hace tres meses aunque hoy haya una nueva. Para builds de release, --pull y, si procede, --no-cache.
• Reconstruir con --no-cache "por si acaso" en desarrollo. Tiras a la basura la ventaja del apartado 7. Úsalo cuando tengas un motivo concreto.
• Pensar que docker build sube la imagen. No sube nada. La imagen queda en tu máquina hasta que hagas docker push (lección 02-06).
• Consejo: vigila la línea transferring context. Si crece con el tiempo, es que algo nuevo se está colando en el contexto. Es el chivato más barato que tienes.
• Consejo: etiqueta desde el primer momento. Una build sin -t produce una imagen <none>:<none> que solo puedes referenciar por ID y que se convierte en basura acumulada (imágenes dangling, lección 02-05).

Partiendo de ~/aurora-libros/api con node_modules instalado:

1. Renombra temporalmente el .dockerignore y construye con --no-cache --progress=plain, anotando la línea transferring context.
2. Restaura el .dockerignore y repite la medición.
3. Calcula el porcentaje de reducción.
4. Añade al proyecto un fichero .env con una contraseña ficticia y una carpeta capturas/ con 5 MB de datos falsos. Sin tocar el .dockerignore, comprueba si entran en el contexto y razona qué habría pasado con un COPY . . si el .dockerignore no existiera.

Pista para generar datos falsos: dd if=/dev/urandom of=capturas/dump.bin bs=1M count=5.

Con el Dockerfile del apartado 10 ya construido:

1. Reconstruye sin cambiar nada y comprueba que todos los pasos salen CACHED.
2. Modifica una línea de server.js y reconstruye. ¿Qué pasos siguen cacheados y cuál es el primero que se reejecuta? ¿Cuánto tarda?
3. Añade una dependencia al package.json (por ejemplo "dotenv": "^16.4.7"), regenera el lock con npm install --package-lock-only y reconstruye. ¿Cuántos pasos se reejecutan ahora? ¿Cuánto tarda?
4. Cambia un comentario dentro del Dockerfile, en la línea inmediatamente anterior al RUN npm ci. Reconstruye. ¿Se mantiene la caché del RUN? Explica el resultado.

Este Dockerfile tiene cuatro problemas relacionados con lo visto en la lección. Localízalos, explica el síntoma de cada uno y escribe la versión corregida.

Solución al ejercicio 1

3. Reducción: (23 410 − 48) / 23 410 ≈ 99,8 %. El tiempo de transferencia pasa de ~1,9 s a un valor no medible. En una jornada con cincuenta builds, son casi dos minutos de espera pura recuperados, y en un pipeline de CI el ahorro se multiplica por cada ejecución.

4. Con los ficheros nuevos:

El contexto crece 5 MB: capturas/ entra porque no está en el .dockerignore. En cambio .env no entra, porque sí está excluido. Compruébalo mirando dentro de la imagen:

No hay .env y sí hay capturas/. Las dos lecciones:

• Sin .dockerignore, ese .env con superSecreta2026 habría acabado dentro de la imagen y, al publicarla en el repositorio público del apartado 10 de la lección anterior, en Internet. Y no bastaría con borrarlo en una capa posterior: como aprendiste en 01-05, la capa inferior conserva el fichero y docker image history delata la operación.
• El .dockerignore hay que mantenerlo. Ha protegido lo que se le pidió proteger, pero capturas/ es nuevo y nadie lo añadió. Añade capturas/ al fichero y vuelve a medir.

Solución al ejercicio 2

1. Sin cambios: [+] Building 0.4s, todos los pasos CACHED. La build es prácticamente instantánea porque BuildKit solo verifica claves de caché.

2. Tras tocar server.js:

Solo se reejecuta el COPY . ., porque el checksum del contexto ha cambiado. El RUN npm ci sigue cacheado, que es justo el objetivo del diseño. Poco más de un segundo.

3. Tras cambiar package.json y el lock:

Se invalida desde el paso 3, y en cascada el npm ci y el COPY . .. Diez segundos. Y es lo correcto: has cambiado las dependencias, así que hay que reinstalarlas. La caché no falla, funciona exactamente como debe.

4. Cambiar un comentario inmediatamente anterior al RUN:

La caché se mantiene. La clave de caché se calcula sobre el texto de la instrucción, y los comentarios no son instrucciones: el intérprete los descarta antes de calcular nada. En cambio, si modificas el texto del propio RUN —aunque solo sea añadir un espacio o reordenar dos opciones equivalentes—, la caché sí se invalida, porque la comparación es textual, no semántica. Es la razón de que reformatear un RUN largo "para que quede más bonito" dispare una build completa.

Solución al ejercicio 3

Los cuatro problemas:

1. COPY . . antes de WORKDIR. Sin WORKDIR definido, el directorio de trabajo es /, así que los ficheros aterrizan en la raíz del sistema de archivos, mezclados con /bin, /etc y /usr. Luego el WORKDIR /app del final crea un /app vacío, y el CMD falla con Cannot find module '/app/server.js'.
2. COPY ../db/init.sql apunta fuera del contexto: error de build inmediato ("/db/init.sql": not found). Además, ese fichero no pertenece a la imagen de la API: es la inicialización de PostgreSQL y se resolverá en el módulo 3.
3. COPY . . antes de instalar dependencias. Invalidación en cascada: cada cambio en server.js fuerza la reinstalación completa de dependencias.
4. npm install en lugar de npm ci --omit=dev. npm install puede resolver versiones distintas de las fijadas en package-lock.json, con lo que dos builds del mismo código pueden producir imágenes diferentes, e instala también las dependencias de desarrollo, que engordan la imagen sin aportar nada en ejecución.

Versión corregida:

Verifica que ahora los ficheros están donde deben:

Ya sabes fabricar imágenes. docker build no ejecuta nada en tu carpeta: empaqueta el contexto de construcción y se lo envía a BuildKit, que interpreta el Dockerfile como un grafo de pasos y produce capas. Ese punto final del comando es el contexto, no el Dockerfile, y de ahí se derivan tanto el error de COPY fuera del contexto como la necesidad del .dockerignore, que en Aurora Libros ha recortado el envío de 23,41 MB a 47,83 kB y, de paso, ha impedido que un .env con credenciales acabe dentro de la imagen. La opción -f desacopla la ubicación del Dockerfile del contexto, pero las rutas de COPY siguen resolviéndose siempre contra este último.

Has visto también la pieza que más tiempo te va a ahorrar en tu vida diaria: la caché de capas. BuildKit calcula una clave por instrucción a partir de la capa anterior, del texto de la instrucción y del contenido de los ficheros copiados; si esa clave existe, el paso sale CACHED en cero segundos, y si no, se reejecuta ese paso y todos los siguientes. De esa invalidación en cascada nace la regla de oro de ordenar de menos a más volátil, que has medido: 46,7 s frente a 1,4 s ante un simple cambio de código, treinta y tres veces más rápido solo por partir un COPY en dos. Y sabes cuándo desconfiar de la caché con --no-cache y --pull, y cómo leer la salida de BuildKit para localizar el punto exacto en que dejó de haber CACHED.

Lo más importante: auroralibros/aurora-api:0.1.0 existe. Son 167 MB que arrancan Express en un contenedor y responden a curl http://localhost:3000/salud en una máquina donde no hay Node instalado. Cuatro de los quince pasos de onboarding han caído de golpe. Que /libros devuelva ECONNREFUSED no es un fallo: es el siguiente problema del temario, y se resolverá cuando conectes contenedores en red en el módulo 3.

Ahora bien, ese Dockerfile lo has escrito casi a ciegas: sabes qué hace cada línea a grandes rasgos, pero no por qué está escrita así. Por qué npm ci y no npm install, por qué el CMD lleva corchetes y comillas, por qué EXPOSE no expone nada, cuándo usar ADD en lugar de COPY y por qué encadenar comandos con && produce imágenes más pequeñas. Todo eso es la próxima lección, Conceptos Básicos de Dockerfile, donde recorrerás el lenguaje instrucción por instrucción y terminarás con el Dockerfile definitivo de aurora-api, comentado línea a línea y justificado decisión a decisión.