A la lliçó anterior vas construir auroralibros/aurora-api:0.1.0 amb un Dockerfile que se't va donar fet i se't va explicar per sobre. Funciona, arrenca l'API dins d'un contenidor i respon a curl. Però el vas escriure gairebé a cegues: saps què fa cada línia, no per què està escrita exactament així. Aquesta lliçó salda aquell deute. Recorreràs el llenguatge del Dockerfile instrucció per instrucció, amb el nivell de detall que a 02-02 va quedar pendent: per què WORKDIR és millor que RUN cd, en què es diferencien COPY i ADD i per què gairebé sempre guanya COPY, què signifiquen exactament les dues formes de RUN i de CMD, per què encadenar comandes amb && produeix imatges més petites, per què EXPOSE no exposa res, i què li passa al teu contenidor quan el pares segons com hagis escrit el CMD. Al final construiràs el Dockerfile definitiu d'aurora-api, comentat línia a línia i amb cada decisió justificada.

1. Estructura d'un Dockerfile, comentaris i la directiva # syntax
2. Taula resum de les instruccions bàsiques
3. FROM: d'on parteixes
4. WORKDIR: on treballes
5. COPY: què portes del context
6. COPY davant d'ADD
7. RUN: què executes durant la construcció
8. ENV: configuració que sobreviu a la construcció
9. EXPOSE: documentació, no publicació
10. CMD: quin procés arrenca el contenidor
11. El Dockerfile definitiu d'aurora-api

Un Dockerfile és un fitxer de text pla, sense extensió, amb una instrucció per línia:

Regles de sintaxi:

• Les instruccions s'escriuen en MAJÚSCULES per convenció. from node:22-alpine funciona igual, però ningú no ho escriu així: en majúscules es distingeix d'un cop d'ull la instrucció dels seus arguments.
• Una instrucció per línia. Per partir una línia llarga es fa servir la barra invertida \ al final, sense res després (ni tan sols un espai: un espai després de la barra n'inverteix l'efecte i produeix errors desconcertants).
• Les línies que comencen per # són comentaris, llevat de les directives de l'apartat següent. Com vas comprovar a l'exercici 2 de la lliçó 02-02, els comentaris no afecten la memòria cau.
• L'ordre importa, i no només per la memòria cau: cada instrucció s'executa sobre l'estat que va deixar l'anterior.
• Les línies buides s'ignoren. Fes-les servir per agrupar blocs lògics; un Dockerfile ben espaiat es llegeix moltíssim millor.

La primera línia del fitxer mereix un apartat propi:

No és un comentari: és una directiva de l'intèrpret. Li diu a BuildKit quina versió del frontend de Dockerfile ha de fer servir per interpretar la resta del fitxer. BuildKit descarrega aquella imatge del registre i la fa servir com a analitzador sintàctic.

Per què convé posar-la sempre:

• Et dona les funcionalitats més recents sense actualitzar Docker. docker/dockerfile:1 és una etiqueta mòbil que apunta a l'última versió estable de la sèrie 1. Coses com COPY --link, els muntatges de memòria cau o els secrets de build (lliçó 05-05) en depenen.
• Fa el fitxer portable. El mateix Dockerfile s'interpreta igual al teu portàtil i en un agent de CI amb una altra versió de Docker.
• És compatible cap enrere. La sèrie 1 garanteix que no trencarà els Dockerfiles existents.

Les variants que veuràs:

Ha de ser la primera línia del fitxer (abans de qualsevol instrucció, fins i tot abans d'altres comentaris) perquè faci efecte.

Aquestes són les instruccions que cobreix aquesta lliçó, amb l'essencial de cadascuna:

La columna "Crea capa?" explica una observació de la lliçó 01-05: no totes les instruccions engreixen la imatge. COPY, ADD i RUN modifiquen el sistema de fitxers i generen capes amb contingut real; les altres només escriuen metadades al manifest, i la seva capa pesa zero bytes.

La columna "Quan actua?" és la que evita més confusió. RUN s'executa en construir i el seu resultat queda congelat; CMD no s'executa en construir en absolut, només descriu què farà el contenidor en arrencar. Confondre-les és l'error conceptual número u de qui comença.

Hi ha més instruccions —ARG, ENTRYPOINT, USER, LABEL, HEALTHCHECK, VOLUME, STOPSIGNAL, ONBUILD, SHELL—, i totes es veuen a la lliçó següent, la 02-04.

FROM és obligatòria i ha de ser la primera instrucció (llevat de directives i comentaris). Estableix el sistema de fitxers i les metadades de partida: tot el que vingui després es construeix a sobre d'aquelles capes.

Sintaxi completa:

Formes que veuràs, aplicades a Aurora Libros:

El compromís entre reproductibilitat i manteniment és real i no té una resposta única:

Aurora Libros fa servir node:22-alpine, decidit a la lliçó 01-07 per tres motius que ara pots justificar del tot: compleix l'engines: node >=22.0.0 del package.json, és imatge oficial (espai library/, primer criteri de confiança de la lliçó 02-01) i pesa ~142 MB davant dels ~1,1 GB de node:22. La contrapartida és que Alpine fa servir musl en lloc de glibc com a biblioteca C; les tres dependències del projecte (express, pg, redis) són JavaScript pur o porten binaris compatibles, així que no suposa cap problema.

La clàusula AS <nom> dona nom a una etapa de construcció. Serveix per a les builds multietapa, la tècnica que permet compilar en una imatge i endur-se'n només el resultat a una altra molt més petita. S'estudia a la lliçó 05-04; menciona-la mentalment i continua.

WORKDIR fixa el directori de treball per a totes les instruccions posteriors que el facin servir: RUN, COPY, ADD i CMD. Si no existeix, el crea, inclosos els directoris intermedis.

És la pregunta obligada. Compara:

En el primer cas, npm ci s'executa a /, no a /app, i falla amb ENOENT: no such file or directory, open '/package.json'. La raó és fonamental: cada RUN s'executa en un contenidor temporal nou. El cd canvia el directori de l'intèrpret d'ordres d'aquell contenidor efímer, que mor així que acaba la instrucció; el RUN següent arrenca de zero, al directori de treball heretat de la imatge.

L'única manera que cd serveixi és encadenar-lo dins del mateix RUN:

Tot i així, WORKDIR guanya per quatre raons:

1. Persisteix en temps d'execució. És el directori on entres amb docker exec -it aurora-api sh i on s'executa el CMD. Un cd dins d'un RUN no deixa rastre.
2. Crea el directori si no existeix, sense necessitat de mkdir -p.
3. És una metadada visible. docker image inspect et diu quin és; un cd enterrat en un RUN s'ha d'anar a buscar.
4. Es llegeix millor. Declara la intenció en lloc d'amagar-la dins d'una cadena de comandes.

Detalls addicionals:

Fes servir sempre rutes absolutes. Les relatives encadenades obliguen a portar el compte mental d'on ets i són una font clàssica d'errors en Dockerfiles llargs.

Per a Aurora Libros, /app és la convenció habitual en imatges de Node. Qualsevol ruta serviria (/srv/aurora, /usr/src/app), però /app és curta, inequívoca i no col·lisiona amb el sistema de fitxers d'Alpine.

COPY porta fitxers i directoris des del context de construcció fins al sistema de fitxers de la imatge.

Regles que cal tenir clares:

• L'origen és sempre relatiu a l'arrel del context, mai al teu directori actual ni a la ubicació del Dockerfile. I mai no pot sortir del context: és la restricció que va provocar l'error "/db/init.sql": not found de la lliçó 02-02.
• La destinació és relativa al WORKDIR si no és absoluta. Amb WORKDIR /app, la destinació ./ significa /app/.
• Si la destinació acaba en /, es tracta com a directori; si no, i hi ha un sol origen, s'interpreta com el nom del fitxer de destinació. Posar sempre la barra final evita sorpreses.
• Amb diversos orígens, la destinació ha de ser un directori i acabar en /.
• COPY copia el contingut d'un directori, no el directori. COPY web/ /public/ deixa el contingut de web/ directament a /public/, no a /public/web/. És la font número u de rutes que "no apareixen" dins de la imatge.

Exemples amb Aurora Libros:

Sobre COPY package*.json ./: el comodí cobreix package.json i package-lock.json d'una sola vegada. Té un avantatge pràctic sobre anomenar-los per separat: no falla si package-lock.json no existeix, perquè el patró simplement coincideix amb menys fitxers. En canvi, COPY package.json package-lock.json ./ dona error si falta el lock. Totes dues formes són defensables: l'explícita detecta abans l'oblit del lock (que trencaria el npm ci), la del comodí és més tolerant. Aurora Libros farà servir la del comodí, que és la convenció més estesa a l'ecosistema Node.

Per defecte, tot el que es copia pertany a root:root. --chown canvia el propietari en la mateixa operació:

La imatge node:22-alpine ja inclou un usuari node sense privilegis. Copiar directament amb la seva propietat evita un RUN chown -R node:node /app posterior, que duplicaria la mida d'aquella capa: canviar els permisos d'un fitxer el marca com a modificat i el copy-on-write de la lliçó 01-05 obliga a escriure una còpia sencera a la capa nova. Un chown recursiu sobre node_modules pot afegir desenes de megues a la imatge.

--chmod fa el mateix amb els permisos:

L'ús d'USER per executar el contenidor sense privilegis es veu a la lliçó 02-04, i el perquè en profunditat, a la 05-03.

ADD existeix des del primer dia de Docker i fa tot el que fa COPY, més dues coses extra. Precisament per això convé evitar-la.

El problema d'ADD és que el seu comportament depèn del que li passis:

Tres comportaments diferents amb la mateixa instrucció. Qui llegeix el Dockerfile ha de saber de memòria quins formats es descomprimeixen per predir-ne el resultat. COPY sempre fa exactament el mateix: copiar.

I el cas de la URL és pitjor:

Quatre problemes acumulats: el .tar.gz queda per sempre a la capa de l'ADD encara que després l'esborris (copy-on-write, lliçó 01-05), no pots verificar la suma de comprovació abans de fer-lo servir, ADD no descomprimeix el que ve d'una URL (només el local), i no controles capçaleres ni autenticació. La forma correcta, tot en un únic RUN:

Aquí sí que verifiques el hash, i l'esborrat passa dins de la mateixa capa, així que el fitxer temporal no engreixa la imatge.

La regla pràctica: fes servir COPY sempre. L'únic cas on ADD aporta alguna cosa genuïna és descomprimir un tarball local del context, que estalvia haver de tenir tar a la imatge:

Al Dockerfile d'aurora-api no apareix cap ADD: no hi ha tarballs ni descàrregues.

RUN executa una comanda en el moment de construir la imatge, dins d'un contenidor temporal basat en les capes anteriors, i congela el sistema de fitxers resultant en una capa nova. És la instrucció que instal·la paquets, compila, genera fitxers… i la que més pes afegeix.

Per a RUN, la forma shell és l'habitual, perquè gairebé sempre vols encadenar comandes o expandir variables. La forma exec només cal en imatges sense intèrpret d'ordres (scratch, distroless) o quan un argument conté caràcters que l'intèrpret interpretaria malament.

Compte amb les cometes: la forma exec és JSON, així que exigeix cometes dobles. RUN ['npm', 'ci'] amb cometes simples no és JSON vàlid i BuildKit el tractarà com a forma shell, amb resultats desconcertants.

Aquesta és la part que de debò importa. Cada RUN crea una capa. Compara:

Dos problemes a la versió dolenta, i el segon és el greu:

1. Quatre capes on n'hi hauria prou amb una. Més metadades, més entrades al manifest, més lentitud en muntar la imatge.
2. El rm -rf del final no allibera res. Recorda de la lliçó 01-05: les capes són diffs i només s'apilen. Esborrar un fitxer a la capa 4 no l'elimina de la capa 2; només escriu un marcador d'esborrat que l'oculta. El fitxer continua viatjant dins de la imatge, ocupant el seu espai a cada descàrrega.

Comprova-ho tu mateix:

48 MB de diferència per moure un rm d'una línia a una altra. El fitxer esborrat "existeix" igualment dins de la imatge mal, invisible però descarregable.

D'aquí les tres regles d'or de RUN:

1. Agrupa les operacions relacionades en un sol RUN amb && i \.
2. Neteja a la mateixa capa on embrutes. Memòries cau de gestors de paquets, fitxers temporals, codi font que ja has compilat.
3. Però no ho agrupis tot. Si fiques en un únic RUN la instal·lació de dependències i l'arrencada de l'aplicació, perds granularitat de memòria cau. L'equilibri: un RUN per propòsit.

Un avís sobre Debian: apt-get update i apt-get install han d'anar sempre al mateix RUN. Si els separes, la memòria cau pot reutilitzar un update de fa setmanes mentre executa un install nou, i acabaràs instal·lant versions que ja no són als repositoris. És el clàssic error conegut com a cache busting d'apt.

Desmenuçat:

• npm ci en lloc de npm install. ci significa clean install: esborra node_modules si existeix i instal·la exactament les versions fixades a package-lock.json, sense resoldre rangs. Si el lock i el package.json no concorden, falla en lloc d'improvisar. Això és justament el que vols en una imatge: dues builds del mateix commit produeixen els mateixos bytes. npm install, en canvi, pot resoldre ^4.21.2 com a 4.21.2 avui i com a 4.22.0 el mes que ve, produint imatges diferents del mateix codi.
• --omit=dev exclou les devDependencies. A Aurora Libros avui no n'hi ha cap, però així que entrin linters o frameworks de test, aquesta opció evitarà que viatgin a producció. Substitueix l'antiga --production, ara desaconsellada.
• npm cache clean --force esborra la memòria cau que npm deixa a ~/.npm, que pot voltar els 50 MB. Va al mateix RUN per tot l'explicat més amunt: en un RUN a part no estalviaria ni un sol byte.

ENV defineix variables d'entorn que existeixen durant la resta de la construcció i també dins del contenidor en execució. Aquesta doble vida és el seu tret distintiu, i és el que la diferencia d'ARG (lliçó 02-04).

Sintaxi:

Fes servir sempre la forma amb =. L'antiga és ambigua amb valors que contenen espais i està en desús.

Les variables definides es poden fer servir en instruccions posteriors:

I persisteixen en execució. Comprova-ho amb la imatge que ja tens:

L'important és que són valors per defecte sobreescrivibles en arrencar el contenidor:

Aquell -e té prioritat sobre l'ENV de la imatge. És exactament el mecanisme que fa que el server.js de la lliçó 01-07 —que llegeix tota la seva configuració de process.env— serveixi sense canvis al teu portàtil i en producció.

L'última fila és la regla que arrossegues des de la lliçó 01-07 i que ara pots demostrar. Si algú escrivís ENV DB_PASSWORD=superSecreta2026, qualsevol persona amb accés a la imatge la veuria:

Aquí hi ha tot, en clar, sense ni tan sols haver d'arrencar el contenidor. I publicant la imatge al repositori públic auroralibros/aurora-api, a Internet.

NODE_ENV=production mereix un comentari perquè a Node no és decoratiu: Express desactiva vistes de depuració i posa les plantilles a la memòria cau, moltes biblioteques redueixen el registre i npm install ometria les devDependencies. És un canvi de comportament real, no una etiqueta.

Aquí hi ha el parany que atrapa tothom. Llegint "expose" qualsevol entén "obre aquest port a l'exterior". EXPOSE no obre res, no publica res i no canvia el comportament de la xarxa. És exclusivament documentació en forma de metadada.

El que sí que fa:

• Deixa constància a les metadades de la imatge de quin port fa servir el servei, perquè qui l'executi ho sàpiga sense llegir el codi.
• Apareix a docker image inspect i a la columna PORTS de docker ps.
• Habilita l'opció docker run -P (majúscula), que publica tots els ports declarats amb EXPOSE en ports aleatoris alts de l'amfitrió.
• Docker Compose i alguns orquestradors el llegeixen com a pista.

El que no fa: publicar el port. Això continua sent feina exclusiva de -p a docker run, tal com vas aprendre a la lliçó 01-06.

Demostra-ho. La teva imatge 0.1.0 té EXPOSE 3000. Arrenca-la sense -p:

Fixa't en la columna PORTS: hi diu 3000/tcp, sense cap fletxa ->. Això significa "el contenidor declara aquest port", no "està publicat". Comprova-ho:

Ara amb -P majúscula, que sí que publica el que està declarat:

Ara sí que hi ha fletxa: el port 3000 del contenidor està publicat al 32768 de l'amfitrió, triat a l'atzar. Neteja:

Aleshores, per què molestar-se a posar EXPOSE? Per tres raons sòlides:

1. Documenta la interfície de la imatge. Qui la rebi sap quin port mapar sense llegir server.js.
2. És el contracte amb l'orquestrador. Compose (mòdul 4), Swarm i Kubernetes (mòdul 6) el fan servir com a referència.
3. Costa zero. És una metadada: no afegeix ni un sol byte a la imatge.

Sintaxi completa:

CMD defineix la comanda per defecte que s'executa en arrencar un contenidor a partir de la imatge. No s'executa durant la construcció: només es desa com a metadada.

I hi ha una regla que governa tota la resta, ja vista a la lliçó 01-06: el contenidor viu mentre visqui el seu procés principal. Quan el procés del CMD acaba, el contenidor s'atura. Per això CMD ["node", "server.js"] manté el contenidor viu (el servidor no acaba) i CMD ["echo", "hola"] produeix un contenidor que mor a l'instant.

Semblen equivalents, i en condicions normals ho són. La diferència apareix en aturar el contenidor, i és prou important com per veure-la amb detall.

Amb la forma exec, Docker executa node server.js directament. El procés node és el PID 1 dins del contenidor.

Amb la forma shell, Docker executa /bin/sh -c "node server.js". El PID 1 és sh, i node és un procés fill:

Quan executes docker stop, Docker envia SIGTERM al PID 1 i espera 10 segons abans d'enviar SIGKILL. Amb la forma exec, node rep el SIGTERM i pot tancar connexions, buidar memòries intermèdies i acabar. Amb la forma shell, el SIGTERM el rep sh, que no el reenvia als seus fills: node no se n'assabenta, continua treballant, i als 10 segons el mata un SIGKILL que no admet neteja. Peticions tallades per la meitat i transaccions a mig fer.

Mesura-ho:

0,3 segons davant de 10,2. Deu segons de diferència per uns claudàtors, multiplicats per cada contenidor a cada desplegament. En un desplegament continu amb vint rèpliques (mòdul 6), aquesta diferència és la que separa un rollout net d'un amb errors per als usuaris.

Neteja:

Regla: fes servir sempre la forma exec, amb claudàtors i cometes dobles. És JSON: les cometes simples no valen.

• Només l'últim compta. Si escrius diversos CMD, els anteriors es descarten sense avís.
• Se sobreescriu des de la línia de comandes. Tot el que posis després del nom de la imatge reemplaça el CMD:

No ha arrencat el servidor: has substituït el CMD per node --version. Aquesta flexibilitat és útil per depurar (docker run --rm -it lasevaimatge sh et dona un intèrpret d'ordres dins de la imatge) i és la base del patró ENTRYPOINT + CMD de la lliçó 02-04.

• Si la imatge base té un ENTRYPOINT, el CMD es converteix en els seus arguments. És justament el tema de 02-04.
• No facis servir CMD per a diversos processos. CMD ["sh", "-c", "node server.js & nginx"] és un antipatró: un contenidor, un procés. Aurora Libros té quatre serveis perquè tindrà quatre contenidors.

Ja pots justificar cada línia. Aquest és el Dockerfile final del mòdul, que substitueix el mínim de la lliçó 02-02. Desa'l a ~/aurora-libros/api/Dockerfile:

Construeix la versió 1.0.0, que és la que acompanya el version del package.json:

Canvia el codi i reconstrueix, que és el que faràs cinquanta vegades al dia:

1,2 segons, amb el npm ci intacte a la memòria cau. L'ordre de les instruccions —dependències a dalt, codi a baix— fa exactament el que es va dissenyar.

Verifica la imatge acabada:

Totes les metadades que has anat declarant hi són, llegibles. I cap credencial entre elles, com marca la regla del projecte. Última comprovació funcional:

Igual que a 02-02: el servei viu i respon; les dependències continuen sense existir, i això és el mòdul 3.

• RUN cd /app esperant que persisteixi. Cada RUN corre en un contenidor temporal diferent. Fes servir WORKDIR.
• CMD en forma shell. Deu segons extra a cada aturada i senyals que no arriben mai al teu procés. Fes servir sempre CMD ["executable", "arg"] amb cometes dobles: és JSON, no Python.
• Creure que EXPOSE publica el port. No publica res. EXPOSE documenta; -p publica. Si el teu servei "no respon" i a docker ps no veus la fletxa -> a PORTS, aquest és el problema.
• Netejar en un RUN diferent del que embruta. L'esborrat no allibera res: la capa inferior conserva els fitxers. Encadena amb && a la mateixa instrucció.
• apt-get update i apt-get install en RUN separats. La memòria cau reutilitza un índex vell i l'install falla o instal·la versions obsoletes. Sempre junts.
• npm install en lloc de npm ci. Trenca la reproductibilitat: el mateix commit pot produir imatges diferents. I no oblidis --omit=dev.
• ADD per costum. El seu comportament depèn del tipus de fitxer i amaga descàrregues remotes sense verificar. Fes servir COPY llevat que necessitis descomprimir un tarball local.
• Secrets a ENV. Queden a les metadades, visibles amb docker image inspect sense ni tan sols arrencar el contenidor, i viatgen amb la imatge allà on vagi. Mai.
• COPY . . sense .dockerignore. Ja ho vas veure a 02-02: context inflat, memòria cau trencada i risc de filtrar un .env.
• Consell: comenta el per què, no el què. # Instal·la dependències sobra: es veu. # El cache clean va aquí perquè alliberi espai de debò és el que agrairà qui ho llegeixi d'aquí a sis mesos.
• Consell: llegeix Dockerfiles aliens. Els de les imatges oficials són a GitHub (lliçó 02-01) i són una escola excel·lent.

Construeix dues imatges basades en node:22-alpine que instal·lin el paquet git amb apk:

• Versió A: apk add git en un RUN i rm -rf /var/cache/apk/* en un altre RUN posterior.
• Versió B: tot encadenat amb && en un únic RUN, fent servir apk add --no-cache.

Compara les mides amb docker image ls i fes servir docker image history per localitzar la capa culpable de la diferència. Explica el resultat en termes de capes i copy-on-write.

1. Escriu dos Dockerfiles idèntics llevat del CMD: un en forma exec i un altre en forma shell, tots dos arrencant node server.js des de la imatge d'Aurora Libros.
2. Arrenca un contenidor de cadascun.
3. Amb docker exec <contenidor> ps -o pid,comm, comprova quin procés és el PID 1 en cada cas.
4. Cronometra docker stop en tots dos amb time.
5. Explica per què la diferència és d'exactament uns 10 segons i no d'un valor arbitrari, i quina opció de docker stop permetria canviar aquesta espera.

Aquest Dockerfile de l'API d'Aurora Libros té set problemes relacionats amb el que s'ha vist. Identifica'ls, explica la conseqüència de cadascun i escriu la versió corregida.

Solució a l'exercici 1

Quatre megues de diferència (amb paquets més grans, la diferència arriba a desenes o centenars). Localitza la capa culpable:

La lectura és concloent: la capa del rm -rf pesa 0 B. No ha alliberat res. Només ha escrit marcadors d'esborrat (whiteouts) que oculten els fitxers de la capa inferior, però aquella capa de 19,2 MB continua a la imatge i es descarrega sencera a cada docker pull.

A la versió B, --no-cache fa que apk no escrigui mai l'índex al disc, així que no hi ha res a esborrar. És l'aplicació directa del copy-on-write de la lliçó 01-05: una capa només pot afegir contingut o ocultar-lo, mai reduir la mida de les capes anteriors. D'aquí la regla: embruta i neteja a la mateixa instrucció.

Solució a l'exercici 2

3. Els processos:

Confirmat: en la forma exec node és el PID 1; en la forma shell el PID 1 és sh i node és el seu fill amb PID 7.

4. Els temps:

5. La diferència és de ~10 segons exactes perquè aquest és el valor del temporitzador de gràcia de docker stop: envia SIGTERM al PID 1, espera 10 segons i, si el contenidor continua viu, envia SIGKILL.

• En la forma exec, node rep el SIGTERM. Encara que aquest server.js no instal·li un gestor explícit, el comportament per defecte de Node davant de SIGTERM és acabar immediatament: 0,3 s.
• En la forma shell, sh rep el SIGTERM i no el reenvia als seus fills (un intèrpret d'ordres POSIX mínim no fa reenviament de senyals). node no se n'assabenta mai. S'esgoten els 10 segons i arriba el SIGKILL, que el procés no pot capturar: tancament abrupte, connexions tallades, sense oportunitat de buidar memòries intermèdies ni tancar el pool de PostgreSQL.

El termini es pot ajustar amb docker stop -t <segons>:

Abaixar el termini no resol res: el procés continua sense rebre el senyal. La solució és la forma exec, o un ENTRYPOINT amb un script que faci servir exec "$@" (lliçó 02-04). Neteja:

Solució a l'exercici 3

Els set problemes:

Un vuitè detall menor: ENV NODE_ENV production fa servir la sintaxi antiga sense =, desaconsellada per ambigua.

Versió corregida:

La contrasenya s'injecta en executar, mai en construir:

I al mòdul 4 ni tan sols anirà a la línia de comandes, sinó en un fitxer .env fora del control de versions (lliçó 04-05) o en un secret gestionat (lliçó 05-03).

Ja domines el llenguatge del Dockerfile. Saps que la directiva # syntax=docker/dockerfile:1 et dona l'intèrpret més recent sense actualitzar Docker, i que de les vuit instruccions bàsiques només COPY, ADD i RUN engreixen la imatge: les altres escriuen metadades que no pesen res. FROM fixa el punt de partida i el compromís entre reproductibilitat i pedaços automàtics. WORKDIR substitueix un RUN cd que no funcionaria mai, perquè cada RUN viu en un contenidor temporal diferent, i a més persisteix en execució. COPY resol les seves rutes contra el context i copia el contingut dels directoris; ADD hi afegeix descompressió i descàrregues amb un comportament variable que la fa pitjor opció llevat que sigui per a tarballs locals.

Amb RUN has vist la regla més rendible de totes: neteja a la mateixa capa on embrutes, perquè una capa només pot afegir o ocultar, mai aprimar les anteriors —48 MB de diferència a la demostració amb python3—. Amb ENV has distingit el que és un valor per defecte legítim (NODE_ENV, PORT) del que mai no ha d'entrar en una imatge (DB_PASSWORD), i ho has comprovat llegint les metadades amb docker image inspect. Amb EXPOSE has desmuntat el parany del nom: documenta, no publica, i la prova és l'absència de fletxa -> a docker ps. I amb CMD has mesurat en carn pròpia que la forma exec i la forma shell no són estils alternatius: són 0,3 segons davant de 10,2 en aturar el contenidor, perquè el PID 1 és node o és sh, i sh no reenvia SIGTERM.

El resultat és auroralibros/aurora-api:1.0.0: 167 MB, comentada línia a línia, amb cada decisió justificada, que es reconstrueix en 1,2 segons després d'un canvi de codi i que no porta ni un sol secret a dins. És un Dockerfile que funciona.

A la lliçó següent, Instruccions Avançades del Dockerfile, el convertiràs en un de professional. Aprendràs a parametritzar la versió base amb ARG i a distingir-lo d'ENV, a separar l'executable fix dels seus arguments amb ENTRYPOINT i CMD combinats, a deixar d'executar l'API com a root amb USER, a descriure la imatge amb etiquetes OCI mitjançant LABEL, i a fer que Docker vigili pel seu compte l'endpoint /salut amb HEALTHCHECK perquè docker ps mostri healthy o unhealthy. Aquest és el salt entre una imatge que arrenca i una imatge que pots posar en producció sense envermellir.