A la lliçó 03-06 vas aprendre a fer servir volums, bind mounts i tmpfs. Aquí veuràs què hi ha a sota: com el daemon apila les capes d'una imatge amb overlay2, quant costa de debò escriure a la capa d'un contenidor, què són els volume drivers i com muntar una estratègia de còpies de seguretat d'Aurora Libros amb restauració provada.

1. Què és un storage driver i què resol
2. overlay2 per dins: els quatre directoris
3. Inspecció real d'una imatge i d'un contenidor
4. Taula comparativa dels storage drivers
5. Consultar el driver actiu i canviar-lo
6. El cost del copy-on-write, mesurat
7. Per què les bases de dades exigeixen volums
8. El driver local i els seus driver_opts
9. Muntar NFS i tmpfs com a volum
10. Plugins de tercers i declaració a Compose
11. Volums external compartits entre piles
12. Estratègia de còpies de seguretat d'Aurora Libros
13. Script de còpia amb rotació i restauració verificada
14. Espai al disc i data-root
15. Rendiment i permisos (UID/GID)

Una imatge és una pila de capes de només lectura (lliçó 01-05). Un contenidor hi afegeix a sobre una capa d'escriptura. El problema tècnic és aquest: presentar totes aquelles capes com un únic sistema de fitxers coherent, i fer-ho sense copiar gigabytes cada vegada que arrenca un contenidor.

D'això se n'encarrega el storage driver del daemon. Té tres responsabilitats:

• Apilar les capes de la imatge en un sol arbre de directoris visible des de dins.
• Aplicar copy-on-write: en modificar un fitxer d'una capa inferior, copiar-lo a la capa superior i treballar sobre la còpia.
• Compartir les capes comunes entre contenidors, perquè deu instàncies de node:22-alpine ocupin l'espai d'una.

És una peça del daemon, no del contenidor: a dins només s'hi veu un sistema de fitxers normal.

overlay2 fa servir OverlayFS, un sistema de fitxers d'unió inclòs al kernel de Linux. Treballa amb quatre conceptes:

Les regles de resolució són senzilles i expliquen tot el comportament que ja has observat:

1. Llegir un fitxer: es busca a upperdir; si no hi és, es recorre lowerdir de dalt a baix. Guanya la primera coincidència.
2. Escriure en un fitxer que només existeix a lowerdir: es copia sencer a upperdir (copy-up) i s'hi escriu. L'original no es toca.
3. Esborrar un fitxer de lowerdir: no es pot esborrar el que és de només lectura, així que es crea a upperdir un fitxer especial de tipus whiteout que l'amaga. L'original continua ocupant espai.

Aquesta tercera regla és la raó, per fi explicada, que esborrar fitxers en una capa posterior d'un Dockerfile no redueixi la mida de la imatge. Ho veurem mesurat a la lliçó 05-04.

Tot això és visible al disc del host. Cada capa viu a /var/lib/docker/overlay2/<id>/:

Fixa't en els enllaços curts d'overlay2/l/: existeixen perquè la longitud dels arguments de muntatge del kernel està limitada, i una imatge amb moltes capes superaria el límit amb rutes completes.

Ara la demostració que ho tanca tot. Escriu un fitxer dins del contenidor i mira'l aparèixer a l'upperdir del host:

El fitxer és físicament al host, dins del diff d'aquell contenidor i només d'aquell contenidor. És el mateix que docker diff mostrava a la lliçó 03-03, però ara saps on viu.

Regla pràctica: si docker info diu overlay2, no toquis res; si diu vfs en un servidor, tens un problema de configuració que multiplicarà per deu l'espai al disc.

Canviar el driver es fa a /etc/docker/daemon.json amb {"storage-driver": "overlay2"} i reiniciant el daemon.

Advertència. Canviar el storage driver fa que el daemon deixi de veure totes les imatges i contenidors existents: continuen al disc, sota el directori del driver antic, però són inaccessibles fins que tornis enrere. Abans de tocar-ho, publica les teves imatges en un registre d'imatges, desa les que no estiguin publicades amb docker save i fes còpia de seguretat dels volums. Els volums, això sí, no depenen del driver: viuen a /var/lib/docker/volumes/ i sobreviuen al canvi.

La teoria diu que el copy-up copia el fitxer sencer la primera vegada que el toques. Anem a mesurar-ho amb un fitxer de 512 MB ficat en una imatge.

Gairebé dos segons per escriure un byte, i 512 MB de capa d'escriptura consumits.

Aquest és el cost real del copy-on-write, i explica tres regles que ja havies aplicat sense conèixer-ne el perquè:

PostgreSQL escriu sense parar en fitxers de dades de desenes o centenars de megabytes. Si /var/lib/postgresql/data fos a la capa d'escriptura, cada modificació d'una pàgina dispararia un copy-up del fitxer sencer la primera vegada, i el rendiment seria catastròfic.

Un volum evita OverlayFS del tot: és un bind mount a un directori del host (/var/lib/docker/volumes/<nom>/_data), muntat sobre el punt corresponent. Les escriptures van directes al sistema de fitxers del host, sense capes ni copy-up.

Aquí tens la prova: mentre / és overlay, /var/lib/postgresql/data és directament el sistema de fitxers del host. Per això les imatges oficials de bases de dades declaren aquell punt com a VOLUME: si t'oblides de muntar-lo, si més no eviten la penalització creant un volum anònim.

El driver de volums per defecte s'anomena local i admet opcions que gairebé ningú no fa servir, tot i que són sorprenentment potents: són les mateixes de la comanda mount de Linux.

La diferència amb un bind mount corrent és de gestió: un volum amb nom apareix a docker volume ls, admet etiquetes, es pot declarar external i no depèn de la ruta relativa del projecte.

Un volum NFS permet que diversos hosts comparteixin les mateixes dades, una cosa impossible amb un volum local:

Tres avisos de camp. El muntatge passa en arrencar el contenidor: si el servidor NFS no respon, el contenidor no arrenca. Fes servir soft i un timeo raonable perquè una fallada de xarxa produeixi un error i no un procés penjat per sempre en estat D. I mai no posis les dades de PostgreSQL a NFS: el bloqueig de fitxers per xarxa no ofereix les garanties que una base de dades necessita, i la corrupció és qüestió de temps. Per a fitxers estàtics —les portades del catàleg— és perfecte.

Un volume driver és un plugin del daemon que atén les peticions de muntatge. Docker porta local; la resta s'instal·la:

A Compose es declaren igual que qualsevol altre volum, amb driver: rclone i els seus driver_opts (remote: "s3aurora:copies"). L'avís important: un plugin de volum és programari privilegiat dins del teu daemon. Instal·la només plugins d'origen verificat i tracta'ls amb el mateix criteri amb què aprovaries una dependència de producció.

Compose anteposa el nom del projecte als volums que crea (aurora-libros_aurora-dades). Quan un volum ha d'existir fora del cicle de vida del projecte —o compartir-se amb una altra pila—, es declara external:

Dues conseqüències molt pràctiques. La primera: docker compose down -v no esborra un volum external, cosa que el converteix en una xarxa de seguretat barata per a les dades que no et pots permetre perdre. La segona: una altra pila —per exemple, un projecte separat d'informes— pot muntar el mateix volum en mode :ro i llegir les dades sense tocar la plataforma principal.

Hi ha dues maneres de copiar les dades d'aurora-db, i no són intercanviables:

Còpia lògica, en calent:

El -T és obligatori: sense ell, exec assigna un pseudoterminal i corromp el flux binari amb traduccions de final de línia. És l'error clàssic d'aquesta operació i no dona cap avís: el fitxer sembla correcte i falla en restaurar.

Còpia del volum a nivell de fitxer:

Per què cal aturar el servei: PostgreSQL manté pàgines modificades en memòria i escriu de manera asíncrona. Un tar sobre un directori de dades viu captura uns fitxers en un instant i uns altres en un altre, produint un conjunt incoherent que pot restaurar sense errors i corrompre's dies després. Amb el servei aturat, el directori està quiet i la còpia és vàlida.

El que converteix aquest script en una cosa seriosa no és la còpia, és la verificació: cada execució restaura el fitxer acabat de crear en un PostgreSQL efímer a tmpfs i compta les files. Si la còpia era buida, truncada o corrupta, l'script falla avui, no el dia del desastre.

Grava't la regla: una còpia que no s'ha restaurat mai no és una còpia, és una carpeta amb esperança a dins.

Tot el que Docker desa viu sota /var/lib/docker:

Si containers/ és enorme, el culpable són els logs sense rotar (ho resoldràs a 05-06). Si ho és overlay2/, són imatges antigues. Per moure el magatzem a un disc més gran:

Fes servir rsync -aHAX i no cp: cal preservar enllaços durs, atributs estesos i permisos, o les capes quedaran inservibles. Comprova que tot funciona abans d'esborrar el directori antic.

Elecció de muntatge per rendiment, de millor a pitjor per a escriptura intensiva:

Els permisos són l'altra meitat del problema. Un volum buit hereta el propietari del punt de muntatge de la imatge; un volum amb dades conserva els seus, i aurora-api corre com l'usuari node (UID 1000), així que un volum creat per root li resulta il·legible.

Amb bind mounts la solució és diferent, perquè el propietari el fixa el host: o bé alinees l'UID del contenidor amb el del teu usuari (user: "${UID}:${GID}" a Compose), o bé ajustes els permisos al host. I recorda de la lliçó 03-06 que el kernel només entén números: el nom node no significa res fora del contenidor.

Escriure dades persistents a la capa del contenidor. Rendiment pèssim per copy-up i pèrdua total en recrear-lo.

Fer tar d'un volum amb la base de dades en marxa. La còpia sembla correcta i és incoherent. Atura el servei o fes servir pg_dump.

Oblidar -T a docker compose exec pg_dump. El pseudoterminal corromp el bolcat binari sense avisar.

No provar mai una restauració. El dia de l'incident descobreixes que fa mesos que guardes fitxers buits.

Executar docker volume prune sense mirar. Esborra tot volum no fet servir per cap contenidor, i un volum d'una pila aturada entra dins d'aquella definició. Declara external allò crític.

Canviar el storage driver sense còpia prèvia, o posar dades de PostgreSQL a NFS. En el primer cas desapareixen imatges i contenidors de l'inventari; en el segon, el bloqueig de fitxers per xarxa no dona les garanties que una base de dades necessita.

Consell: etiqueta els volums en crear-los (--label criticitat=alta) i filtra per aquella etiqueta abans de qualsevol neteja: docker volume ls --filter label=criticitat=alta. Un minut d'etiquetatge evita l'esborrat que no té marxa enrere.

Exercici 1. Demostra el copy-on-write en dues direccions: localitza l'upperdir d'aurora-api, crea un fitxer dins del contenidor i troba'l al disc del host; després mesura el cost de modificar un byte d'un fitxer de 256 MB que vingui a la imatge, i compara'l amb modificar un byte d'un fitxer ja present a la capa d'escriptura.

Exercici 2. Munta el cicle complet de còpia i restauració d'aurora-db: fes una còpia lògica, destrueix les dades esborrant el volum, restaura i comprova que els nou títols hi tornen a ser. Explica en quin punt exacte la plataforma hauria quedat inservible sense la còpia.

Exercici 3. Converteix aurora-dades en un volum external, demostra que docker compose down -v ja no l'esborra i explica quina protecció aporta això i quina n'és la contrapartida.

Solució 1.

Un segon davant de zero, per escriure exactament el mateix byte. La diferència és el copy-up: en el primer cas el fitxer viu en un lowerdir de només lectura i el kernel ha de copiar els 256 MB sencers a l'upperdir abans de permetre l'escriptura; en el segon, cp ja l'havia portat a la capa d'escriptura. Extrapola: PostgreSQL escrivint sense parar en fitxers de dades sense un volum pagaria aquell peatge una vegada i una altra, a més de multiplicar l'espai ocupat. Aquí es veu, en un segon de rellotge, per què la decisió de la lliçó 03-06 no era una convenció sinó una necessitat física.

Solució 2.

Aquí hi ha un matís que confon molta gent: després del down -v la base de dades torna amb 9 llibres sense haver restaurat res, perquè el volum s'ha recreat buit i PostgreSQL ha executat de nou db/init.sql. Això és exactament el que fa perillosa la situació: sembla que no s'ha perdut res.

El que sí que s'ha perdut són les dades afegides després de la inicialització, que és tot el que importa en producció:

Després del desastre en queden 9 (els d'init.sql); després de restaurar, els 10 reals. El punt exacte en què la plataforma hauria quedat inservible és el down -v: el -v esborra els volums, i amb ells l'únic lloc on existien les dades afegides pels usuaris. Sense /tmp/aurora10.dump, aquella fila no es recupera d'enlloc.

Solució 3.

El down -v no ha esborrat el volum i les dades continuen intactes: Compose es nega a destruir el que no ha creat. La protecció és real i costa dues línies de YAML, així que per al volum de dades d'una plataforma en producció és una decisió gairebé automàtica.

La contrapartida té dues cares. La primera, operativa: el volum deixa de crear-se sol, i qui desplegui per primera vegada en un servidor nou ha d'executar docker volume create abans de l'up, o Compose fallarà amb external volume not found. La segona, conceptual: perds la reproductibilitat d'un entorn des de zero. En desenvolupament això molesta —el reset de la lliçó 04-07 deixa de funcionar—, així que la pràctica sensata és declarar external només a compose.prod.yaml, deixant que l'entorn local continuï sent d'un sol ús.

Ja saps què passa sota -v. Un storage driver apila les capes d'una imatge i aplica copy-on-write, i overlay2 ho fa amb quatre directoris que has vist al disc: els lowerdir de només lectura de la imatge, l'upperdir on apareix cada fitxer que escriu el contenidor, el merged que és el que el procés veu com a / i el workdir intern del kernel. D'allà surten les tres regles de resolució, inclosa la dels whiteouts que explica per què esborrar un fitxer en una capa posterior no allibera espai. Coneixes la taula completa de drivers —btrfs, zfs, el retirat devicemapper, fuse-overlayfs per a rootless i el lentíssim vfs— i saps que canviar de driver deixa invisibles totes les teves imatges.

I has mesurat el copy-on-write: gairebé dos segons i 512 MB de capa per escriure un sol byte en un fitxer que venia a la imatge. Aquesta xifra converteix en física el que era una recomanació: una base de dades escriu constantment en fitxers grans, per tant va en un volum, que evita OverlayFS i escriu directe al sistema de fitxers del host. Saps esprémer el driver local amb els seus driver_opts —bind amb nom, tmpfs amb mida, NFS per a les portades i mai per a PostgreSQL—, declarar plugins de tercers a Compose i fer servir volums external perquè down -v no pugui endur-se per davant les dades de producció. T'endús a més una estratègia de còpies que és una estratègia i no una intenció: la taula que distingeix la còpia lògica en calent amb pg_dump de la còpia de fitxers amb tar —i per què la segona exigeix aturar el servei—, un script amb rotació que restaura i compta files a cada execució, la regla que una còpia que no s'ha restaurat mai no és una còpia, i el control de l'espai a /var/lib/docker amb data-root.

A la lliçó 05-03 arriba el torn de la seguretat, i amb ella l'enduriment complet d'Aurora Libros: el model d'amenaces i les seves quatre superfícies, per què pertànyer al grup docker equival a ser root —amb l'escalada demostrada—, el mode rootless, imatges mínimes i fixades per digest, --read-only, capacitats del kernel, seccomp, escaneig de vulnerabilitats amb Docker Scout i Trivy, SBOM i signatura amb Cosign, i un compose.prod.yaml endurit línia a línia amb la seva llista de comprovació accionable.