La imatge auroralibros/aurora-api:1.2.0 pesa 142 MB. No és cap desastre, però tampoc no està optimitzada: a dins hi viatja un compilador de C, les dependències de desenvolupament i fitxers que ningú no executa. En aquesta lliçó la poses a règim mesurant a cada pas, fins a una xifra concreta, sense perdre res de l'enduriment de la lliçó 05-03.

1. Per què importa la mida i què no s'ha de sacrificar
2. Mesurar primer: image ls i history
3. dive: explorar capa a capa
4. Elecció de la base, amb xifres
5. Construccions multietapa: el concepte
6. Multietapa aplicada a aurora-api
7. Etapes amb nom i --target
8. Imatge base comuna per a diverses imatges
9. Reduir capes i contingut
10. Esborrar un fitxer no redueix la mida (demostrat)
11. Ordenar per a la memòria cau
12. Verificació final i taula resum

En una plataforma amb cinc nodes i quinze desplegaments al mes, abaixar 40 MB per imatge són uns 3 GB menys de transferència mensual i desenes de segons menys a cada arrencada en fred.

I el que no se sacrifica per aprimar: el HEALTHCHECK, l'usuari sense privilegis, les etiquetes OCI de traçabilitat, la capacitat de diagnosticar un problema en producció i la reproductibilitat de la construcció. Una imatge de 40 MB que ningú no sap depurar a les tres de la matinada és un mal negoci.

El diagnòstic és immediat i sorprèn gairebé tothom la primera vegada: dels 142 MB, 115 MB són la imatge base. Les dependències són 21 MB i el codi propi, 3 MB. La palanca principal no és al teu codi: és en quina base tries i en què hi afegeixes a sobre.

Per comparar amb precisió fes servir la mida real (docker image inspect --format '{{.Size}}' | numfmt --to=iec) i no la que mostra el registre d'imatges, que està comprimida i sempre sembla menor.

docker history diu quant pesa cada capa; dive diu què hi ha a dins i quant se'n malbarata.

Tres troballes i tres decisions: la memòria cau d'npm no hauria de ser a la imatge final, node_modules/.cache és brossa de compilació, i .git no hauria d'haver entrat mai al context de construcció (falta una línia al .dockerignore).

L'efficiency score mesura quant contingut s'escriu en una capa i se sobreescriu o s'esborra en una altra; per sota del 95 % hi ha feina a fer. Per automatitzar-ho a CI, afegeix -e CI=true i --lowestEfficiency=0.95: dive acaba amb codi diferent de zero si no s'assoleix el llindar.

La contrapartida d'Alpine té nom: musl en lloc de glibc. Conseqüències reals:

• Els paquets npm amb binaris precompilats per a glibc poden no funcionar i haver-se de compilar en instal·lar-los (més lent, i exigeix build-base).
• Algunes càrregues intensives en DNS o en resolució de noms es comporten de manera diferent amb musl.
• Certes biblioteques científiques i d'aprenentatge automàtic no suporten musl.

aurora-api fa servir Express, pg i redis, cap amb dependències natives problemàtiques: Alpine és l'elecció correcta. Si un dia una dependència donés problemes, node:22-slim costa 95 MB més i els resol.

Una construcció multietapa fa servir diverses imatges base al mateix Dockerfile. Les etapes intermèdies compilen i preparen; l'etapa final copia només el resultat. Tota la resta —compiladors, memòries cau, dependències de desenvolupament, codi font— es queda fora de la imatge publicada.

Dues regles que resumeixen el mecanisme:

• Només l'última etapa (o la indicada amb --target) acaba a la imatge; les altres es descarten.
• COPY --from=<etapa> porta fitxers concrets d'una etapa anterior, i res més no hi viatja: ni les seves capes, ni el seu historial, ni els seus secrets.

Punt de partida (una sola etapa, 142 MB) i destinació:

142 MB → 121 MB: un 15 % menys amb un sol canvi estructural. D'on surten els 21 MB? De build-base (python3, make, g++), que s'instal·lava a la imatge final i ara viu i mor a l'etapa dependencies, i de la memòria cau d'npm.

Fixa't que no s'ha perdut res del que estava endurit: USER node, el HEALTHCHECK, les etiquetes OCI i l'ENTRYPOINT/CMD en forma exec continuen allà. Optimitzar no és retallar seguretat.

Les etapes amb nom no són només organització: són artefactes construïbles per separat.

La imatge de desenvolupament pesa 318 MB i està bé que sigui així: porta les devDependencies, el marc de proves i les eines de depuració. És exactament el target: desenvolupament que compose.override.yaml fa servir des de la lliçó 04-07, i ara veus d'on surt.

Un patró molt útil és una etapa de proves que fa fallar la construcció si les proves fallen:

BuildKit no executa aquella etapa en construir la de producció, perquè no forma part del seu graf de dependències (lliçó 05-05). Només s'executa si la demanes amb --target.

Quan publiques diversos serveis en Node, convé una base pròpia amb el que és compartit:

Avantatges: una sola actualització de seguretat es propaga a tots els serveis, la capa base es comparteix al disc i a la descàrrega entre ells, i les decisions comunes són en un sol lloc. Inconvenient: crees una dependència interna que cal mantenir i versionar. Compensa a partir de tres o quatre serveis.

El .dockerignore d'aurora-api després del que va revelar dive:

De 94 MB de directori a 812 kB de context. Això no només fa la construcció més ràpida: garanteix que .git i .env no es puguin colar en cap capa, cosa que és un assumpte de seguretat a més de mida.

El fitxer no existeix i la imatge continua pesant 113 MB. L'explicació és la de la lliçó 05-02: les capes són immutables i rm en una capa posterior només crea un whiteout que amaga el fitxer; els 105 MB continuen allà baix, es descarreguen a cada pull i s'emmagatzemen a cada node.

La correcció és unir creació i esborrat a la mateixa instrucció:

De 113 MB a 8,15 MB. La mateixa lògica, el mateix resultat funcional, un && de diferència. I és exactament el motiu de --virtual .build al Dockerfile de l'apartat 6: instal·lar, compilar i desinstal·lar dins d'un sol RUN.

Recordatori de la lliçó 02-02, ara combinat amb multietapa: les instruccions s'ordenen de menys a més canviant.

Amb multietapa l'efecte es multiplica: en tocar src/server.js, BuildKit reutilitza tota l'etapa dependencies —inclosa la instal·lació d'npm— i només refà les dues últimes capes de l'etapa final.

Tres segons davant dels quaranta i escaig d'una construcció neta. Optimitzar la mida i optimitzar la velocitat de construcció són, gairebé sempre, la mateixa feina.

Una imatge optimitzada que no funciona no val res. La comprovació és obligatòria:

I l'últim esglaó, si el teu context ho permet: canviar la base final a distroless.

142 MB → 102 MB: un 28 % menys. El preu, ja conegut de la lliçó 05-03: sense sh no hi ha docker exec ... sh i el HEALTHCHECK amb wget deixa de funcionar, així que la sonda passa a fer-se des de Compose o des de l'orquestrador.

Optimitzar sense mesurar. Sense docker history i dive, es retalla on no fa mal i es deixa intacta la capa de 100 MB.

Esborrar fitxers en un RUN posterior. El fitxer desapareix i l'espai no. Creació i esborrat, a la mateixa instrucció.

Copiar tot el projecte amb COPY . . sense .dockerignore. Hi entren .git, node_modules i, amb sort, algun .env.

Instal·lar eines de compilació a la imatge final. Compiladors en producció són pes i superfície d'atac. Van a l'etapa de dependències.

Sacrificar el HEALTHCHECK o l'USER per estalviar uns megues. L'intercanvi és pèssim: la seguretat i l'operabilitat valen més que 3 MB.

Perseguir el mínim absolut. Un binari a scratch que no pots depurar costa més car a la primera incidència del que va estalviar en un any de descàrregues.

Consell: integra el mesurament al flux de treball. Un pas de CI que compari la mida de la imatge amb la de la versió anterior i avisi si creix més d'un 10 % detecta la dependència inflada el dia que entra, no sis mesos després.

Exercici 1. Analitza auroralibros/aurora-api:1.2.0 amb history i amb dive: identifica la capa més gran, calcula quin percentatge del total representa la base, i troba com a mínim un malbaratament real que puguis eliminar amb .dockerignore.

Exercici 2. Converteix el Dockerfile d'aurora-api a multietapa amb tres etapes (dependencies, desenvolupament, produccio), mesura l'abans i el després, i demostra que la imatge final no conté el compilador que sí que és a l'etapa de dependències.

Exercici 3. Demostra que esborrar un fitxer en una capa posterior no redueix la mida i arregla-ho. Calcula l'estalvi exacte i explica què hauria passat si aquell fitxer hagués estat un fitxer de credencials.

Solució 1.

El 81 % de la imatge és la base. És la dada que reordena les prioritats: barallar-se pels 3 MB del codi propi és irrellevant mentre no es decideixi conscientment quina base es fa servir. Amb dive apareix el malbaratament concret:

.git dins d'una imatge de producció no és només 1,2 MB de pes: és l'historial complet del repositori viatjant al registre d'imatges, amb qualsevol secret que algú hagués fet servir en un commit i després esborrat. Es corregeix amb una línia al .dockerignore, i la comprovació és directa:

Solució 2.

L'etapa dependencies té els tres binaris de compilació; la final, cap. I tanmateix totes dues tenen els mateixos 64 paquets a node_modules: COPY --from=dependencies ha portat exactament el resultat de la feina i res de l'utillatge que la va produir.

Aquesta és la idea central de multietapa expressada de la manera més clara possible: el que necessites per construir no és el que necessites per executar. I el benefici no és només de mida; també és de seguretat, perquè un atacant amb execució de comandes a la imatge final no hi troba cap compilador amb què preparar la fase següent del seu atac.

Solució 3.

L'estalvi exacte són 104,85 MB, un 92,8 % del total, i el resultat funcional és idèntic: en totes dues imatges el fitxer no existeix. La diferència és si els 100 MB van arribar a formar part d'una capa consolidada. A mal, la capa A els va escriure i van quedar immutables; la capa B només hi va afegir un whiteout que els amaga. A be, el fitxer va néixer i va morir dins de la mateixa instrucció, així que quan BuildKit va consolidar la capa ja no hi era.

La pregunta sobre les credencials porta la demostració a la seva conclusió més incòmoda:

El fitxer no existeix i la contrasenya es recupera de la capa exportada amb una sola comanda. Si aquella imatge s'hagués publicat a Docker Hub, qualsevol podria extreure-la amb docker pull i docker save, sense necessitat d'executar el contenidor. Per això el mateix && que estalvia 105 MB és també un control de seguretat, i per això la solució correcta per als secrets de construcció no és un && sinó RUN --mount=type=secret, que veuràs a la lliçó següent.

aurora-api ha passat de 142 MB a 102 MB, un 28 % menys, sense perdre l'usuari sense privilegis, el HEALTHCHECK, les etiquetes OCI ni un sol endpoint: /salut, /llibres i /llibres/:id responen igual i el contenidor continua arribant a healthy. I, més important que la xifra, tens el mètode: mesurar primer. docker image ls per al total, docker image history per trobar la capa grassa —que va resultar ser la base, amb el 81 % del pes— i dive per veure el malbaratament real, que va destapar la memòria cau d'npm i un .git que mai no hauria d'haver entrat al context.

Saps triar la base amb criteri i no per costum, coneixent la contrapartida de musl davant de glibc i què costa cada esglaó entre node:22, -slim, -alpine, distroless i scratch. Domines les construccions multietapa: una etapa que instal·la i compila amb build-base, una de desenvolupament amb les devDependencies que alimenta el target: desenvolupament del teu compose.override.yaml, una etapa de proves que trenca la construcció si alguna cosa falla, i una de final que només rep node_modules i src/ mitjançant COPY --from —demostrat: tres compiladors a l'etapa intermèdia, zero a la publicada—. I saps construir cadascuna per separat amb --target, a més de compartir una imatge base pròpia entre diversos serveis.

Del costat del contingut: --no-cache, --no-install-recommends, --virtual amb el seu apk del, npm ci --omit=dev, npm cache clean i un .dockerignore que va reduir el context de 94 MB a 812 kB. I la demostració que més val la pena recordar: esborrar un fitxer en una capa posterior no redueix la mida —113 MB davant de 8,15 MB per un &&—, i aquest mateix mecanisme fa que una credencial escrita i esborrada continuï sent extraïble de la imatge publicada.

A la lliçó 05-05 entra en escena el constructor que ha estat fent tot això per sota: BuildKit, amb el seu graf de dependències i el seu paral·lelisme entre etapes, i Buildx amb els seus builders. Veuràs els muntatges a RUN —type=cache per no reinstal·lar npm a cada build, type=bind, type=tmpfs i sobretot type=secret, la resposta correcta al problema de credencials que acabes de demostrar—, la memòria cau remota compartida amb --cache-from i --cache-to, la compilació multiarquitectura per a amd64 i arm64 amb les seves manifest lists, i docker buildx bake per construir totes les imatges d'Aurora Libros d'una sola vegada.