Fa tres lliçons que construeixes. Cada docker build de les anteriors ha deixat capes al teu disc, i a hores d'ara la teva màquina acumula auroralibros/aurora-api en diverses versions, les bases node, postgres, redis, nginx i alpine, les imatges de laboratori dels exercicis i una memòria cau de BuildKit que no has mirat mai. Aquesta lliçó tracta d'administrar aquest magatzem: saber què tens, per què ocupa el que ocupa, com auditar de què està feta una imatge, com esborrar sense endur-te per davant el que necessites, d'on surten aquelles misterioses imatges <none>:<none> que apareixen build rere build, i com endur-te una imatge a una altra màquina quan no hi ha cap registre pel mig. És la lliçó menys vistosa del mòdul i la que més disgustos t'estalviarà: un docker system prune -a --volumes mal entès esborra en deu segons dades que van costar setmanes.

1. Llistar imatges: docker image ls i les seves opcions
2. Inspeccionar: docker image inspect i --format
3. Auditar com es va fer: docker image history
4. Esborrar imatges: docker image rm
5. Imatges dangling: les <none>:<none>
6. Neteja amb la família prune
7. Diagnòstic de l'espai: docker system df
8. Portar imatges sense registre: save/load i export/import
9. Rutina de manteniment recomanada

El punt de partida, amb la gramàtica docker <objecte> <acció> de la lliçó 01-04:

docker images és l'àlies curt i fa exactament el mateix.

Un avís fonamental sobre la columna SIZE, que ja vas intuir a la lliçó 01-05: les mides no se sumen. Les tres versions d'aurora-api diuen 167 MB cadascuna, però no ocupen 501 MB al disc. Comparteixen la base node:22-alpine i bona part de les seves capes; l'espai real el dirà docker system df a l'apartat 7.

El digest surt <none> perquè aquestes imatges es van construir en local i no s'han publicat mai: el digest del manifest l'assigna el registre en rebre el push. Així que les publiquis a la lliçó 02-06, aquella columna s'omplirà.

Només apareix la 1.1.0, perquè és l'única que porta les etiquetes OCI. Aquí es veu el rendiment pràctic de la feina de la lliçó anterior: les metadades no eren decoració, són un índex consultable.

Recuperant --format de la lliçó 01-04:

Camps disponibles: .ID, .Repository, .Tag, .Digest, .CreatedSince, .CreatedAt, .Size.

Sense la paraula table, la sortida és text pla, perfecte per a scripts:

I en JSON, per processar amb jq:

docker image inspect bolca totes les metadades d'una imatge en JSON. Sense filtre són centenars de línies:

La gràcia és extreure'n només el que necessites. La sintaxi de --format és la mateixa de la lliçó 01-04, i aquests són els camps que més faràs servir:

Aquesta és la comanda amb què audites que no hi ha cap secret dins d'una imatge abans de publicar-la. Converteix-la en un reflex.

Si això digués linux/amd64 i fossis en un Mac amb Apple Silicon, la imatge funcionaria per emulació, molt més lenta. És la primera comprovació davant d'un contenidor inexplicablement lent.

Una comanda, i ja saps exactament quin commit porta dins aquella imatge.

Pots inspeccionar-ne diverses alhora i comparar-les:

Aquí es veu la genealogia completa: Alpine aporta 1 capa, Node n'hi afegeix 3 més, i el teu Dockerfile les 3 restants (els dos COPY i el RUN).

docker image history reconstrueix la història de construcció d'una imatge capa a capa. És l'eina d'auditoria per excel·lència i ja la vas fer servir a la lliçó 02-01 per avaluar imatges alienes.

Com llegir-ho:

• Es llegeix de baix a dalt. L'última línia és la primera capa (el sistema de fitxers base d'Alpine); la primera línia és la instrucció més recent.
• <missing> no és un error. Només la capa superior té un ID propi; les intermèdies d'una imatge construïda amb BuildKit no l'exposen. És normal.
• La columna SIZE és la que importa. Allà es veu que el RUN npm ci aporta 24,7 MB i els dos COPY amb prou feines 52 kB i 44 kB junts. Totes les metadades —ENV, EXPOSE, USER, LABEL, HEALTHCHECK, ENTRYPOINT, CMD— pesen 0 B, exactament com es va anunciar a la lliçó anterior.
• La història inclou la de la imatge base. Les línies de "6 dies" són de node:22-alpine: veus com la van construir els seus mantenidors.

És l'ús més rendible de la comanda:

Quan una imatge pesa 900 MB i no saps per què, aquesta comanda et dona la resposta en un segon. Els sospitosos habituals: memòries cau de gestors de paquets sense netejar, eines de compilació que s'hi van quedar dins i fitxers temporals esborrats en una altra capa (amb l'efecte nul que vas demostrar a la lliçó 02-03).

Per defecte la columna CREATED BY es talla. Per auditar de debò, cal el text sencer:

Aquesta és la comanda amb què detectes en una imatge aliena un curl … | sh sospitós, la instal·lació d'una eina que no esperaves o, a la teva pròpia imatge abans de publicar-la, un --build-arg amb una contrasenya com el de la lliçó 02-04.

Una limitació honesta: history mostra les instruccions, no el contingut. Un fitxer copiat amb COPY no es veu aquí. Per a això, arrencar la imatge i mirar (docker run --rm imatge ls -la /app) o eines de tercers com dive (lliçó 07-04).

docker rmi és l'àlies curt. Fixa't en la sortida: Untagged i Deleted són dues coses diferents, i entendre'n la diferència és la clau de tot aquest apartat.

Quan dues etiquetes apunten a la mateixa imatge (el mateix IMAGE ID), esborrar-ne una no esborra la imatge:

Mateix IMAGE ID: és una imatge amb dos noms, no dues imatges de 167 MB. Ara esborra'n una:

Només Untagged, sense cap Deleted. S'ha tret el nom; les dades continuen sent-hi perquè 1.1.0 les continua referenciant. El Deleted només apareix quan desapareix l'última referència. Aquesta és la raó que de vegades esborris una imatge i no recuperis ni un byte de disc.

Esborrar per ID quan hi ha diverses etiquetes apuntant a aquella imatge falla:

Docker s'hi nega perquè no sap quin nom vols eliminar. O esborres cada etiqueta pel seu nom, o fas servir -f per eliminar-les totes de cop.

El més freqüent de tots:

El contenidor està aturat, no en execució, i tot i així bloqueja l'esborrat. Té tota la lògica: com vas aprendre a la lliçó 01-05, un contenidor aturat conserva la seva capa d'escriptura, que s'apila a sobre de les capes de la imatge. Esborrar la imatge deixaria aquella capa flotant sobre el no-res, i el contenidor no podria tornar a arrencar.

Les tres sortides possibles:

Quan és acceptable -f? Menys vegades de les que es fa servir:

El perill de -f sobre un contenidor en execució: la imatge queda "esborrada" del llistat però les seves capes continuen ocupant disc mentre el contenidor visqui, i el contenidor no podrà reiniciar-se quan s'aturi. Acabes amb un servei que funciona fins al primer reinici i després és irrecuperable, sense cap manera de reconstruir-lo llevat del registre. És un incident de producció clàssic.

El patró $(docker image ls -q …) combina -q (només ID) amb la substitució de comandes de l'intèrpret d'ordres. Abans d'executar un esborrat massiu, executa primer només la part interna per veure què destruiràs:

Tard o d'hora veuràs això:

Aquestes <none>:<none> són imatges dangling (penjants): imatges reals, completes i perfectament funcionals, que han perdut el nom.

La causa principal, amb diferència, és reconstruir amb la mateixa etiqueta:

A la segona build neix una imatge nova (contingut diferent, ID diferent) i l'etiqueta 1.1.0 es mou cap a ella. La imatge A no s'esborra: es queda sense nom. És exactament el model de la lliçó 02-01 —les etiquetes són punters mòbils a digests immutables—, vist des del costat local.

Comprova-ho:

Les altres dues fonts:

• Builds sense -t. docker build . produeix una imatge sense nom des del primer segon. És el motiu del consell de la lliçó 02-02: etiqueta sempre.
• Builds fallides que van deixar capes intermèdies.

Perquè s'acumulen en silenci. Un desenvolupador que reconstrueix vint vegades al dia amb la mateixa etiqueta genera vint imatges dangling diàries. La majoria comparteixen capes i no ocupen 167 MB cadascuna, però les capes pròpies (el COPY . . i de vegades el RUN npm ci) sí que són exclusives. En unes setmanes són uns quants gigabytes, i el missatge no space left on device arriba en el pitjor moment.

No són brossa absoluta: si en saps l'ID, les pots executar i fins i tot reetiquetar.

Això et treu del pas quan esborres per error l'etiqueta d'una imatge que encara no havies publicat. Però com a pràctica habitual, es netegen.

Quatre comandes, amb quatre radis de destrucció molt diferents. Aquesta taula és la que cal memoritzar:

Aquest és el que pots executar amb confiança: només s'endú imatges sense nom. Amb -f se salta la confirmació (útil en scripts) i amb --filter "until=168h" limita l'esborrat a les de més d'una setmana:

Llegeix bé l'avís: esborra totes les imatges que no tinguin un contenidor associat, no només les dangling. Si no tens contenidors creats —el normal després de netejar—, això s'endú node:22-alpine, postgres:16-alpine, redis:7-alpine, les teves aurora-api locals i tota la resta. No és catastròfic (es pot reconstruir i tornar a descarregar), però significa gigabytes de descàrrega i, si estàs sense connexió o a prop del límit de descàrregues de la lliçó 02-01, una mala estona.

La memòria cau de BuildKit és invisible a docker image ls i sol ser el més voluminós de la màquina:

Gairebé tres gigues que no apareixien en cap llistat d'imatges. Variants:

La contrapartida: la build següent de cada projecte anirà en fred. Recorda de la lliçó 02-02 que és allà on la memòria cau no ajuda.

L'avís llista exactament el que esborrarà. Llegeix-lo sempre: és la diferència entre netejar i perdre feina. El que s'endú per sorpresa sol ser un contenidor aturat que contenia dades a la seva capa d'escriptura, o una xarxa que havies creat a mà per a unes proves.

Aquesta és la línia que t'arruïna el dia: all volumes not used by at least one container.

Traduït a Aurora Libros: quan al mòdul 3 tinguis un volum amb el catàleg de PostgreSQL i hagis aturat i esborrat el contenidor d'aurora-db per recrear-lo, aquell volum queda temporalment sense contenidor associat. Un docker system prune -a --volumes en aquell moment esborra la base de dades sencera. Sense paperera, sense desfer, sense recuperació.

Regles d'ús:

• Mai en un servidor. Mai.
• En desenvolupament, només quan tinguis clar que no hi ha cap volum que t'importi.
• Abans d'executar-lo, mira quins volums hi ha:

• Si només vols espai, l'escala segura és: docker image prune → docker builder prune → docker system prune. Poques vegades cal arribar a l'últim esglaó.

Abans d'esborrar res, mesura.

Com llegir-ho:

Dues conclusions immediates d'aquest exemple:

1. Nou imatges ocupen 842 MB, no la suma de les seves columnes SIZE a docker image ls (que donaria més d'1,2 GB). La diferència són les capes compartides de la lliçó 01-05, comptades una sola vegada.
2. La memòria cau de build és de 2,85 GB, el 100 % recuperable, i és amb diferència el més gran. És el primer que cal netejar, i no apareixia en cap llistat d'imatges.

Les columnes SHARED SIZE i UNIQUE SIZE són les que ho aclareixen tot:

• node:22-alpine: 142 MB de mida, 142 MB compartits, 0 B únics. Esborrar-la no alliberaria res, perquè totes les seves capes les fan servir les teves imatges d'aurora-api.
• aurora-api:1.0.0: 167 MB, dels quals només 24,7 MB són exclusius. Això és el que guanyaries en esborrar-la.
• postgres:16-alpine: 278 MB amb 270 MB únics. Aquesta sí que és una bona candidata si no l'has de fer servir.

I mira l'última línia de volums: f3a9c2e1b8d7… amb 0 links és un volum anònim orfe, exactament el que anticipava la lliçó 02-04 en desaconsellar VOLUME al Dockerfile. Ocupa 61,7 MB i ningú no sap què conté.

De vegades cal portar una imatge a una altra màquina sense cap registre pel mig: un client amb la xarxa aïllada, un entorn sense sortida a Internet, una demostració en un portàtil sense connexió. Docker ofereix dues parelles de comandes que es confonen constantment i que no són intercanviables.

La regla: per moure una imatge, sempre save/load. export/import serveix per a una altra cosa.

De 168 MB a 62 MB: un 63 % menys, i això és el que viatja pel llapis de memòria o l'SCP. També es pot fer en un sol pas amb una canonada:

Mateix IMAGE ID, mateix ENTRYPOINT, mateix USER. La imatge ha arribat íntegra, amb totes les metadades que vas definir a la lliçó 02-04.

Desar diverses imatges en un sol fitxer, útil per endur-te la pila sencera d'Aurora Libros:

Un únic fitxer amb tot el necessari per aixecar la plataforma en una màquina sense Internet.

Treballa sobre contenidors, no imatges, i aplana el resultat:

Una sola capa i cap historial. Tota la genealogia ha desaparegut. I el més greu:

S'han perdut l'ENTRYPOINT, el CMD, l'ENV, l'USER i l'EXPOSE. La imatge importada és un sistema de fitxers sense instruccions. Caldria reposar-los a mà en executar:

Aleshores, per a què serveix? Per a dues coses legítimes:

1. Aplanar una imatge amb massa capes o amb un secret enterrat en una capa intermèdia que vols eliminar de debò. En aplanar, aquella capa desapareix. (La manera moderna i millor d'aconseguir-ho són les builds multietapa, lliçó 05-04.)
2. Extreure el sistema de fitxers d'un contenidor per analitzar-lo forensement o per construir una imatge base a partir d'un sistema existent.

Es poden reposar les metadades en importar, amb -c:

Funciona, però has hagut de reconstruir a mà el que save conservava tot sol. Queda clar quina és l'eina adequada per portar imatges.

Neteja:

Amb tot això, aquesta és una rutina raonable per a una màquina de desenvolupament.

Setmanal (segura, es pot automatitzar):

Esborra les dangling i la memòria cau de build de més d'una setmana, i mostra com queda l'espai. No toca res amb nom, ni contenidors, ni volums.

Mensual (revisió manual):

Aquí no s'automatitza res: es mira i es decideix. Els volums orfes s'han d'inspeccionar abans d'esborrar-los, perquè poden contenir dades.

Abans d'una build important:

Memòria cau neta i base actualitzada, com es va explicar a la lliçó 02-02.

Quan falta espai, l'escala segura:

En cinc passos ordenats de menor a major risc es recuperen gairebé sempre uns quants gigabytes sense arribar mai a docker system prune -a --volumes.

Un script de manteniment amb informe:

Fixa't en l'última secció: llista els volums orfes però no els esborra. Aquesta és la línia que separa un script de manteniment d'un script de destrucció de dades.

• Sumar la columna SIZE de docker image ls. No és espai al disc: les capes compartides es compten a cada fila. La dada real és a docker system df, i el desglossament a docker system df -v.
• Esborrar una etiqueta i esperar recuperar espai. Si la sortida només diu Untagged i no Deleted, no has alliberat res: la imatge té una altra referència.
• docker image rm -f sobre un contenidor en execució. La imatge "desapareix" però les seves capes continuen al disc i el contenidor no podrà reiniciar-se mai més. Atura el contenidor primer.
• docker system prune -a --volumes sense llegir l'avís. Esborra volums sense contenidor associat, i un volum de base de dades entre recreacions de contenidor està exactament en aquell estat. Mai en un servidor.
• Ignorar la memòria cau de BuildKit. No apareix a docker image ls i sol ser el més voluminós de la màquina. docker system df la delata.
• Confondre save/load amb export/import. export perd ENTRYPOINT, CMD, ENV, USER i l'historial, i la imatge importada dona no command specified. Per portar imatges, sempre save/load.
• Oblidar comprimir el .tar. Un gzip -9 retalla habitualment entre un 50 % i un 65 %.
• Consell: audita les variables abans de publicar. docker image inspect --format '{{range .Config.Env}}{{println .}}{{end}}' ha de ser un reflex abans de qualsevol docker push.
• Consell: fes servir docker image history … | sort -rh per caçar capes grosses. És el diagnòstic de "per què pesa tant aquesta imatge" en una sola comanda.
• Consell: etiqueta sempre amb -t. Cada build sense etiqueta és una imatge dangling des del primer segon.
• Consell: abans d'un esborrat massiu, executa només la part interna del $( … ) per veure què destruiràs.

1. Executa docker system df i anota el total i el percentatge recuperable de cada categoria.
2. Amb docker system df -v, identifica la imatge amb més UNIQUE SIZE i la que tingui UNIQUE SIZE de 0 B. Explica què significa cada cas i quant alliberaria esborrar cadascuna.
3. Localitza amb docker image history la capa més pesada d'auroralibros/aurora-api:1.1.0 i de postgres:16-alpine.
4. Comprova si tens volums orfes i esbrina, sense esborrar-los, de quina imatge van sortir.

1. Construeix auroralibros/aurora-api:experiment des del teu Dockerfile i anota l'IMAGE ID.
2. Crea una segona etiqueta auroralibros/aurora-api:copia apuntant a la mateixa imatge. Comprova que l'ID coincideix i que docker system df no ha crescut.
3. Esborra l'etiqueta copia. Surt Untagged, Deleted o tots dos? Per què?
4. Modifica server.js, reconstrueix amb la mateixa etiqueta experiment i comprova que apareix una imatge <none>:<none>. Explica d'on va sortir.
5. Recupera aquella imatge dangling reetiquetant-la com a auroralibros/aurora-api:rescatada i verifica que funciona.
6. Neteja tot el que has creat a l'exercici.

Simula un desplegament en un entorn aïllat:

1. Exporta en un únic fitxer auroralibros/aurora-api:1.1.0, postgres:16-alpine i redis:7-alpine.
2. Comprimeix-lo i anota la mida abans i després.
3. Esborra les tres imatges de la teva màquina (simulant la màquina de destinació en blanc).
4. Carrega-les des del fitxer i verifica que aurora-api conserva ENTRYPOINT, USER, ENV i l'HEALTHCHECK.
5. Repeteix el cicle amb export/import sobre un contenidor d'aurora-api i compara: mida del tar, nombre de capes de l'history i comportament en executar docker run sense arguments. Conclou quina parella faries servir i per què.

Solució a l'exercici 1

1. Total aproximat: 3,95 GB, dels quals 3,65 GB són recuperables. La memòria cau de build és el 72 % de tot i és 100 % recuperable: és l'objectiu prioritari.

2.

• Més UNIQUE SIZE: postgres:16-alpine, amb 270 MB únics dels seus 278 MB. Només comparteix amb les altres la capa base d'Alpine (8,17 MB). Esborrar-la alliberaria 270 MB reals.
• UNIQUE SIZE de 0 B: node:22-alpine. Els seus 142 MB estan íntegrament compartits amb les teves imatges d'aurora-api, que es van construir sobre ella. Esborrar-la no alliberaria ni un byte mentre existeixi alguna imatge derivada; només desapareixeria del llistat. És la demostració pràctica de les capes compartides de la lliçó 01-05.

3.

A aurora-api, el npm ci amb 24,7 MB és el contribuent propi més gran: són les dependències de producció. A postgres, els 248 MB de la compilació de PostgreSQL n'expliquen la mida per si sols.

4.

El contingut en delata l'origen: és un volum anònim creat per la imatge de PostgreSQL, que declara VOLUME /var/lib/postgresql/data al seu Dockerfile. És exactament l'escenari que la lliçó 02-04 donava com a raó per no fer servir VOLUME. No l'esborris sense comprovar-ne el contingut: podria ser una base de dades amb feina a dins.

Solució a l'exercici 2

Mateix ID i el mateix espai total. docker image tag només crea una referència; no copia ni un sol byte. És la demostració local del que veuràs al registre a la lliçó 02-06.

Només Untagged. No hi ha Deleted perquè l'etiqueta experiment continua apuntant a aquella imatge: les dades continuen referenciades i l'esborrat es limita a eliminar el nom.

L'ID 4e9c7d2a8f31 és el mateix del pas 1: la imatge original no s'ha esborrat, ha perdut el nom. La build nova va produir una imatge diferent i l'etiqueta experiment s'hi va moure. Les etiquetes són punters, no propietàries.

Recuperada i funcional, i ja no figura com a dangling perquè torna a tenir nom. Fixa't que --version va funcionar gràcies a l'ENTRYPOINT ["node"] de la lliçó 02-04.

Solució a l'exercici 3

De 481 MB a 173 MB: un 64 % menys. La compressió val la pena sempre, sobretot si el fitxer viatja per SCP o per un llapis de memòria.

Absolutament tot intacte: entrypoint, cmd, usuari, variables, healthcheck i fins i tot les etiquetes OCI amb el hash del commit.

Taula comparativa final:

Conclusió: per portar imatges, save/load, sense discussió. El petit estalvi de mida d'export no compensa perdre tota la configuració d'execució, el healthcheck i la traçabilitat que va costar una lliçó sencera construir. export/import és una eina per aplanar sistemes de fitxers, no per moure imatges.

Neteja:

Ja saps administrar el teu magatzem d'imatges. Llistes i filtres amb docker image ls, els seus --filter (inclòs el filtratge per les etiquetes OCI que vas afegir a 02-04) i les seves plantilles Go. Extreus qualsevol metadada concreta amb docker image inspect --format, i tens un reflex nou que convé conservar: auditar les variables d'entorn abans de publicar qualsevol imatge. Amb docker image history reconstrueixes com es va fer una imatge, capa a capa, i localitzes en una sola comanda la que es va menjar els megues —a aurora-api, el npm ci amb 24,7 MB; a postgres, els 248 MB de la seva compilació—.

Saps esborrar entenent el que passa: Untagged treu un nom i Deleted destrueix dades, i només apareix quan cau l'última referència. Saps per què un contenidor aturat bloqueja l'esborrat de la seva imatge (conserva la capa d'escriptura apilada a sobre) i quan -f és acceptable i quan és una manera elegant de trencar un servei al pròxim reinici. Entens d'on surten les <none>:<none>: reconstruir amb la mateixa etiqueta mou el punter i deixa òrfena la imatge anterior, que continua al disc i fins i tot es pot rescatar reetiquetant-la.

Domines l'escala de neteja, de menor a major risc —image prune, builder prune, system prune— amb una advertència gravada a foc sobre l'últim esglaó: docker system prune -a --volumes esborra volums sense contenidor associat, i un volum de base de dades entre recreacions està exactament en aquell estat. Mesures abans de tocar res amb docker system df i la seva versió -v, que revela el que cap llistat d'imatges mostra: la memòria cau de BuildKit ocupant gigabytes, les capes compartides comptades una sola vegada i les columnes SHARED/UNIQUE que diuen quant alliberaries de debò en esborrar cada imatge. I saps endur-te una imatge a una màquina aïllada amb docker save/load, conservant entrypoint, usuari, healthcheck i etiquetes OCI, davant d'export/import, que aplana el sistema de fitxers i ho perd tot.

La teva imatge està construïda, és professional i saps mantenir-la. Li falta l'única cosa que justificava tot el mòdul: sortir de la teva màquina. A l'última lliçó, Etiquetatge i Publicació d'Imatges, tancaràs el cicle. Veuràs que docker image tag no copia res sinó que crea referències, decidiràs una estratègia d'etiquetatge seriosa —versionatge semàntic amb etiquetes mòbils i fixes, per SHA de commit, per branca, per entorn— i publicaràs auroralibros/aurora-api a Docker Hub i a GitHub Container Registry, llegint la sortida del push, verificant el resultat amb docker manifest inspect i entenent per què en producció es desplega per digest i mai per latest.