La plataforma funciona. curl http://localhost:3000/llibres retorna els vuit títols i la web carrega al navegador. Però hi ha una esquerda als fonaments amb la qual ja has ensopegat dues vegades sense donar-li importància: cada vegada que recrees aurora-db, el catàleg desapareix i has de tornar a carregar init.sql a mà amb docker cp. En una màquina de desenvolupament això és una molèstia. Al servidor on viu el catàleg real d'una llibreria, és una catàstrofe.

Aquesta lliçó resol el segon gran problema dels contenidors, després de la xarxa: les dades. Demostraràs la pèrdua amb un experiment que fa una mica de por, coneixeràs els tres tipus de muntatge que ofereix Docker i quan fer servir cadascun, entendràs on viuen de debò els volums i per què no els has de tocar a mà, i donaràs a PostgreSQL un volum amb nom perquè el catàleg d'Aurora Libros sobrevisqui a la destrucció del seu contenidor. Al final repetiràs l'experiment del principi i el resultat serà el contrari.

1. El problema, demostrat
2. Els tres tipus de muntatge
3. Volums gestionats per Docker
4. Volums anònims i el problema dels orfes
5. Bind mounts: fitxers de la teva màquina dins del contenidor
6. -v enfront de --mount
7. Muntatges de només lectura
8. tmpfs: dades en memòria
9. Pràctica: aurora-dades i la prova de destrucció
10. Còpies de seguretat i restauració
11. Bones pràctiques

Comencem per mirar el desastre a la cara. Afegeix un llibre nou al catàleg:

Nou llibres. L'API els serveix. Ara simula el que passa en qualsevol operació normal: actualitzar la imatge de PostgreSQL, canviar una variable d'entorn, afegir un límit de memòria... tot això obliga a recrear el contenidor, com saps des de la lliçó 03-01.

No és que falti El Aleph: és que ja no existeix la taula. Tot el catàleg d'Aurora Libros s'ha evaporat. I l'API, coherent:

Això no és una fallada de Docker: és el seu disseny, i ja el coneixies des de la lliçó 01-05. Un contenidor escriu en una capa d'escriptura que neix amb ell i mor amb ell. Les nou files eren en un volum anònim que Docker va crear automàticament —ho vas descobrir a l'exercici 2 de la lliçó 03-03— i que en recrear el contenidor va ser substituït per un altre nou i buit.

La solució és treure les dades del contenidor. Anem-hi.

Docker ofereix tres maneres que una ruta dins del contenidor apunti a alguna cosa que no és a la seva capa d'escriptura:

La regla de decisió, en una frase: si les dades importen i les gestiona l'aplicació, un volum; si el fitxer és teu i el vols editar des del teu editor, un bind mount; si no ha de tocar el disc mai, tmpfs.

Aquest segon nom il·legible és un volum anònim orfe, resta d'algun dels aurora-db que has esborrat. Hi tornarem.

Mountpoint és la ruta al host. I aquí va l'avís més important de l'apartat:

No hi entris a tocar fitxers. Aquesta ruta és propietat del dimoni de Docker: pertany a root, els seus permisos i el seu context de seguretat els gestiona Docker, i a Docker Desktop (macOS i Windows) ni tan sols existeix a la teva màquina, sinó dins d'una màquina virtual Linux a la qual no tens accés directe. Escriure-hi a mà és una manera excel·lent de corrompre una base de dades.

La manera correcta de mirar dins d'un volum és amb un contenidor:

Buit, acabat de crear. Aquest patró —un contenidor efímer d'Alpine que munta el volum— és la navalla suïssa per inspeccionar, copiar i restaurar volums, i el faràs servir a l'apartat 10.

Igual que amb els contenidors, etiquetar permet netejar de manera selectiva:

Un volum anònim és el que Docker crea pel seu compte, sense que li ho demanis, en dues situacions:

1. Quan la imatge declara VOLUME /ruta al seu Dockerfile (ho fan postgres, redis, mysql, mongo…).
2. Quan muntes amb -v /ruta indicant només la destinació, sense origen.

Aquest nom de 64 caràcters és el volum anònim. I aquí hi ha el seu problema:

El volum hi continua sent, orfe. Sense contenidor que el faci servir, amb un nom que ningú no pot recordar, i ocupant disc indefinidament. Cada postgres que has esborrat en aquest mòdul en va deixar enrere un, amb les seves dades a dins, irrecuperables a la pràctica.

Neteja els orfes ara, comprovant abans què t'enduràs per davant:

Compte amb aquesta comanda: docker volume prune esborra dades de debò i no hi ha paperera. Un volum "sense fer servir" pot ser el d'una base de dades el contenidor de la qual està simplement aturat. Des de Docker 23, prune només toca els anònims per defecte; per incloure els que tenen nom cal --all, cosa que és una xarxa de seguretat que convé no desactivar a la lleugera.

Un bind mount connecta una ruta concreta del teu host amb una ruta del contenidor. Ja el vas fer servir a la lliçó 01-06 amb el teu index.html.

És el mateix fitxer vist des de dos llocs: els canvis van en les dues direccions i en temps real. Aquest és el seu superpoder per a desenvolupament —edites al teu IDE i el contenidor ho veu a l'instant— i el seu perill en producció.

Regles i paranys:

Aquest és el mal de cap clàssic dels bind mounts:

En aquest cas funciona per casualitat: el teu usuari del host té UID 1000 i l'usuari node de la imatge també. Però prova amb un usuari diferent:

El nucli compara números, no noms. Dins del contenidor no existeix cap "usuari del host": només hi ha UID i GID, i els permisos del fitxer són els que tingui a la teva màquina. Les tres solucions habituals:

I d'aquí surt una regla que convé memoritzar: els bind mounts són per a desenvolupament i per a fitxers de configuració; les dades de producció van en volums.

Docker ofereix dues sintaxis per al mateix:

Aquest "si l'origen no existeix" és la diferència pràctica més important. Amb -v, un error de teclat a la ruta et deixa un directori buit i un contenidor que arrenca sense les seves dades; amb --mount, obtens un error clar i el contenidor no arrenca.

Taula d'equivalències per tenir-la a mà:

src i source són sinònims, igual que dst, destination i target.

Un fitxer de configuració no té per què ser escrivible pel contenidor. Marcar-lo com a només lectura és una defensa barata i eficaç:

El nucli ho impedeix, no Docker. És el mateix mecanisme que vas fer servir amb index.html i nginx.conf a la lliçó anterior. Fes-lo servir sempre que muntis:

• Fitxers de configuració (nginx.conf, redis.conf, postgresql.conf).
• Scripts d'inicialització (init.sql).
• Certificats i claus públiques.
• Contingut estàtic que l'aplicació no ha de modificar.

Un muntatge tmpfs crea un sistema de fitxers a la RAM del host. Res no toca el disc i tot desapareix en aturar el contenidor:

Casos d'ús reals: secrets desencriptats en temps d'execució, fitxers de sessió, directoris temporals d'aplicacions que s'executen amb el sistema de fitxers arrel en només lectura, i qualsevol dada que per normativa no hagi de quedar escrita en disc. Només funciona a Linux.

És el moment d'arreglar aurora-db d'una vegada.

La segona fila fa servir una convenció de la imatge oficial de PostgreSQL: tot el que hi hagi a /docker-entrypoint-initdb.d/ (fitxers .sql, .sql.gz o .sh) s'executa automàticament, en ordre alfabètic, la primera vegada que s'inicialitza la base de dades. És exactament la feina que fa dues lliçons que fas a mà amb docker cp.

El chmod 644 no és decoratiu: el procés de PostgreSQL corre com l'usuari postgres (UID 70), i si el fitxer només fos llegible pel teu usuari, l'script no es podria executar. És el xoc d'UID de l'apartat 5, aplicat.

Comprova què ha passat a l'arrencada:

Els vuit llibres s'han carregat sols. Sense docker cp, sense psql -f, sense recordar-se de res.

Verifica els muntatges:

Un volum escrivible per a les dades i un bind mount de només lectura per a l'script. Exactament el pla.

Afegeix un altre cop El Aleph:

I ara, destrueix el contenidor. Sense por:

El contenidor ja no existeix. El volum hi continua sent. Recrea'l amb exactament la mateixa comanda d'abans:

El Aleph hi continua sent. Has esborrat el contenidor de la base de dades per complet i el catàleg ha sobreviscut intacte, amb els seus nou llibres. Compara-ho amb l'apartat 1 d'aquesta mateixa lliçó, on el mateix experiment va destruir fins i tot la taula.

I hi ha un detall als registres que mereix una mirada:

L'init.sql no s'ha tornat a executar. La imatge detecta que el directori de dades ja conté una base de dades i se salta la inicialització. Això és exactament el que vols: si s'executés sempre, el CREATE TABLE IF NOT EXISTS no faria mal, però un script menys curós podria esborrar dades reals a cada arrencada. I la conseqüència pràctica: si canvies init.sql, no n'hi haurà prou amb reiniciar; hauràs d'esborrar el volum perquè es torni a inicialitzar des de zero.

(No ho executis ara: ho necessites per a la lliçó següent.)

El contenidor de Nginx que vas crear a la lliçó anterior ja fa servir bind mounts; ara pots llegir aquella comanda amb altres ulls:

Bind mounts de només lectura per a dos fitxers que viuen al teu repositori de Git. Edita index.html al teu editor, recarrega el navegador, i el canvi hi és sense reconstruir cap imatge: aquest és el flux de desenvolupament que es converteix en el protagonista de la lliçó 04-07.

Un volum que no es copia és un volum que es perdrà. Hi ha dues estratègies i serveixen per a coses diferents.

El patró universal: un contenidor efímer que munta el volum i un directori del host, i executa tar.

Què fa cada part:

La restauració és l'operació inversa:

El ..?* del rm és per incloure els fitxers ocults; sense ell quedarien restes de la instal·lació anterior barrejades amb la còpia.

Per a una base de dades, gairebé sempre és millor una còpia lògica: un fitxer SQL amb l'esquema i les dades.

I la restauració, amb -i perquè psql llegeixi de l'entrada estàndard:

Comparació de les dues estratègies:

La regla: fes servir l'eina nativa del servei si en té (pg_dump, mysqldump, redis-cli BGSAVE), i el truc del contenidor amb tar per a tota la resta.

Estat actual de l'emmagatzematge d'Aurora Libros:

Un sol volum, amb nom, i 0 B recuperables: ni un orfe. Aquest és l'objectiu.

El que aquesta lliçó no cobreix i on es veu: els storage drivers del dimoni (overlay2 i companyia), els drivers de volum per a NFS, SMB o emmagatzematge al núvol, i les opcions avançades de rendiment s'estudien a la lliçó 05-02. Com es declaren els volums en un fitxer compose.yaml, a la lliçó 04-02.

• Confiar en la capa d'escriptura per a dades que importen. Mor amb el contenidor, i recrear un contenidor és una operació rutinària.
• Fer servir volums anònims sense saber-ho. Tota imatge amb VOLUME al seu Dockerfile en crea un. Si no li poses nom, les teves dades depenen d'un hash que ningú no recorda.
• Executar docker volume prune sense mirar. Esborra dades reals sense confirmació per segona vegada i sense paperera. Llista abans amb docker volume ls -f dangling=true.
• Escriure a mà a /var/lib/docker/volumes/.... Permisos incorrectes, corrupció, i a Docker Desktop ni tan sols existeix aquella ruta.
• Rutes relatives en un bind mount. Fes servir rutes absolutes o $(pwd); amb -v, una ruta mal escrita es converteix en un directori buit creat com a root.
• Muntar un directori buit sobre un que tenia contingut. El muntatge amaga el de la imatge: Nginx retornarà 403 i PostgreSQL es reinicialitzarà.
• Esperar que init.sql s'executi a cada arrencada. Només corre quan el directori de dades està buit. Si el canvies, esborra el volum.
• Copiar un volum de base de dades en calent amb tar. Pot sortir corrupte. Atura el contenidor, o fes servir pg_dump.
• Consell: escriu el docker run dels teus serveis amb dades en un fitxer de notes. És llarg i cal reproduir-lo exactament per no perdre el volum... fins al mòdul 4, on això es resol del tot.
• Consell: anomena les còpies amb la data i automatitza'n la rotació. I restaura almenys una vegada, per saber que funciona.

Crea un contenidor d'alpine:3.20 anomenat tres-muntatges amb sleep 600 i tres muntatges alhora: un volum amb nom prova-vol a /vol, un bind mount de ~/aurora-libros/proves a /bind, i un tmpfs de 8 MB a /mem. Escriu un fitxer diferent a cada ruta. Després:

1. Reinicia el contenidor amb docker restart i comprova quins dels tres fitxers hi continuen.
2. Esborra'l amb docker rm -f (sense -v), crea'n un de nou amb els mateixos muntatges i comprova de nou els tres.
3. Explica els resultats i digues quin muntatge faries servir per a: el catàleg de llibres, el nginx.conf, i un token de sessió que no ha de tocar el disc.

Redis desa la seva instantània a /data, que la imatge oficial declara com a VOLUME i per tant avui és un volum anònim. Arregla-ho:

1. Comprova amb docker inspect que l'aurora-cache actual fa servir un volum anònim.
2. Recrea'l amb un volum amb nom aurora-cache-dades i activant la persistència amb la comanda redis-server --appendonly yes.
3. Escriu una clau, força un desament, destrueix el contenidor i recrea'l. Comprova si la clau sobreviu.
4. Respon: té sentit persistir una memòria cau? Argumenta a favor i en contra.

Amb la plataforma funcionant i els nou llibres al seu lloc:

1. Fes una còpia de seguretat lògica amb pg_dump i una altra de física amb tar, anotant la mida de cadascuna.
2. Provoca el desastre: esborra el contenidor aurora-db i el volum aurora-dades.
3. Comprova què respon l'API en aquell moment.
4. Recupera't pel camí més ràpid i explica quin has triat i per què. Verifica que els nou llibres —inclòs El Aleph, que no és a init.sql— tornen a estar disponibles a través de curl http://localhost:8080/api/llibres.

Solució a l'exercici 1

1. Després de docker restart:

El tmpfs ja s'ha perdut amb el simple reinici: vivia a RAM i el muntatge es recrea buit a cada arrencada.

2. Després d'esborrar i recrear:

3. Resultats i decisions:

I les tres decisions: el catàleg de llibres → volum amb nom (dada de producció que ha de sobreviure i de la qual Docker gestiona els permisos); el nginx.conf → bind mount de només lectura (fitxer versionat a Git que vols editar al teu IDE i que el contenidor només llegeix); el token de sessió → tmpfs (no ha de quedar escrit en disc ni un instant, i s'ha d'evaporar en aturar el contenidor).

Solució a l'exercici 2

Volum anònim confirmat: nom de 64 caràcters, creat pel VOLUME /data del Dockerfile oficial de Redis.

La clau sobreviu. Nota que van caldre dues coses: el volum amb nom (perquè els fitxers persisteixin) i --appendonly yes (perquè Redis hi escrigui). Un volum sense persistència activada desaria un fitxer que mai no s'actualitza.

4. Té sentit persistir una memòria cau?

A favor:

• Arrencada en calent. Després d'un reinici, la memòria cau ja té dades i no hi ha una allau de peticions contra PostgreSQL (el fenomen conegut com a thundering herd).
• Si Redis es fa servir també per a sessions d'usuari o cues de treball, allà ja no és una memòria cau: són dades que perdre-les té conseqüències visibles.

En contra:

• Una memòria cau, per definició, ha de poder perdre's sense conseqüències. Si el teu sistema no funciona sense ella, no és una memòria cau: és una base de dades disfressada, i s'hauria de tractar com a tal.
• La persistència costa: E/S de disc a cada escriptura i una arrencada més lenta.
• Les dades persistides poden quedar obsoletes: en recuperar-se, Redis serveix un catàleg antic fins que expiri el TTL.

Per a Aurora Libros, amb un TTL de 60 segons i un catàleg petit, no compensa: és més net deixar aurora-cache sense persistència i que s'ompli sola a la primera petició. Aquest és el criteri que s'aplicarà al compose.yaml del mòdul 4.

Solució a l'exercici 3

1. Les dues còpies:

Dues mil vegades més petita la lògica que la física, per exactament els mateixos nou llibres.

2 i 3. El desastre:

Interessant: l'error no és de base de dades, sinó de DNS. En no existir el contenidor, el nom aurora-db no es resol a aurora-net. És el mateix ENOTFOUND de la lliçó 03-04, ara amb una causa diferent: allà faltava la xarxa, aquí falta el contenidor.

4. La recuperació:

Vuit, no nou. L'init.sql va restaurar el catàleg original, però El Aleph no hi és: es va inserir després. Aquí és on la còpia de seguretat deixa de ser un tràmit i passa a ser l'única cosa que et salva:

He triat la còpia lògica, i per tres motius:

1. És més ràpida d'aplicar: un psql de 4 kB enfront d'aturar el servei, buidar el volum i desempaquetar 8,4 MB.
2. No exigeix aturar res: es restaura sobre la base de dades en marxa, mentre que la còpia física obliga a aturar el contenidor.
3. És portable: si en recuperar-me hagués aprofitat per pujar a PostgreSQL 17, el tar del volum no hauria servit —el format del directori de dades és específic de cada versió major— i el .sql sí.

La còpia física continua tenint el seu paper: és l'única opció per a volums d'aplicacions que no tenen una eina de bolcat pròpia, i és una còpia bit a bit que inclou configuració i estat que pg_dump no recull.

El segon gran problema està resolt. Has vist amb els teus propis ulls que un contenidor destruït s'emporta les seves dades —la primera vegada ni tan sols quedava la taula llibres— i saps per què: la capa d'escriptura neix i mor amb el contenidor, i els volums anònims que creen pel seu compte imatges com postgres o redis no es reutilitzen, sinó que queden orfes amb les seves dades a dins, inabastables a la pràctica.

Coneixes els tres tipus de muntatge i quan fer servir cadascun: volums gestionats per Docker per a les dades que importen, bind mounts per a configuració i desenvolupament, i tmpfs per al que no ha de tocar el disc. Saps on viuen realment els volums —/var/lib/docker/volumes/…, territori del dimoni, invisible a Docker Desktop— i que la manera correcta de mirar-hi dins és un contenidor efímer d'Alpine, mai el teu editor. Entens el xoc d'UID dels bind mounts, perquè el nucli compara números i no noms, i tens les tres maneres de resoldre'l. I prefereixes --mount a -v en scripts per una raó molt concreta: falla sorollosament en comptes de crear un directori buit que arruïna l'arrencada en silenci.

Aurora Libros ha canviat de categoria. aurora-db desa el seu estat al volum amb nom aurora-dades i rep init.sql com a bind mount de només lectura a /docker-entrypoint-initdb.d/, així que el catàleg es carrega sol la primera vegada i mai més no es trepitja. La prova definitiva va sortir com havia de sortir: vas inserir El Aleph, vas destruir el contenidor sencer, el vas recrear amb la mateixa comanda i els nou llibres hi continuaven sent. I aurora-web serveix index.html i nginx.conf des del teu repositori en :ro, editables des del teu IDE sense reconstruir res. A més saps copiar i restaurar: amb un contenidor auxiliar i tar per a qualsevol volum, i amb pg_dump —més petita, en calent i portable entre versions— per a la base de dades.

Queden dos riscos drets, i són els últims d'aquest mòdul. El primer el vas veure a docker stats a la lliçó 03-04: cap dels teus contenidors no té límit de memòria, així que una consulta desbocada a PostgreSQL o una fuita a Node poden deixar sense RAM tota la màquina. El segon és que si un contenidor mor de matinada, ningú no l'aixeca. A la lliçó següent, Límits de Recursos i Polítiques de Reinici, posaràs setge a tots dos: límits de memòria i CPU amb les seves taules de combinacions, l'OOM killer provocat a propòsit per veure'l amb OOMKilled: true i el seu codi 137, --pids-limit com a defensa davant d'una fork bomb, i les quatre polítiques de reinici amb la diferència subtil entre always i unless-stopped. I en acabar, tindràs al davant la llista completa de comandes que cal per aixecar Aurora Libros des de zero... i entendràs per què existeix Docker Compose.