Aixecar la plataforma amb una comanda ja és una victòria. Però si per veure l'efecte de canviar una línia de server.js cal reconstruir la imatge i recrear el contenidor, ningú no farà servir Docker per programar: acabaran executant Node al host i tornarem als quinze passos.

Aquesta lliçó converteix el compose.override.yaml de desenvolupament en un entorn de treball diari: edites al teu editor, el canvi es veu a l'instant, depures pas a pas, executes proves aïllades i reinicies l'entorn amb una comanda. És l'última lliçó del mòdul 4.

1. L'objectiu i l'override de desenvolupament
2. Bind mount del codi i el problema de node_modules
3. Recàrrega automàtica del procés
4. develop.watch: el mecanisme natiu de Compose
5. docker compose watch en marxa
6. Depuració pas a pas amb VS Code
7. Accés a la base de dades
8. Proves en contenidors efímers
9. Dades de desenvolupament i reinici de l'entorn
10. Rendiment dels bind mounts a macOS i Windows
11. Les dreceres de l'equip: dev.sh i Makefile

El cicle que busquem és: desar el fitxer a l'editor → el procés del contenidor es reinicia sol → recarregar el navegador. Sense build, sense up, sense esperes. Tot el que cal viu a compose.override.yaml, que Compose carrega automàticament en local (lliçó 04-06) i que al servidor no es fa servir mai.

El bind mount fa que el directori del host substitueixi el del contenidor. I aquí hi ha el parany clàssic: si muntes tot el projecte (./api:/app), el node_modules del host tapa el que va instal·lar la imatge durant el docker build.

Les conseqüències són de les que arruïnen una tarda:

• Si no tens node_modules al host, el contenidor es queda sense dependències: Error: Cannot find module 'express'.
• Si el tens, són les que va instal·lar el teu sistema operatiu i la teva versió de Node. Qualsevol paquet amb binaris natius compilats per a macOS no funciona dins d'una imatge Alpine.

La segona opció mereix una explicació, perquè el mecanisme no és obvi: el muntatge més específic guanya. Docker munta ./api sobre /app i, a sobre, un volum anònim sobre /app/node_modules, que en la seva primera creació s'inicialitza amb el contingut que la imatge ja tenia allà. El resultat és codi del host i dependències de la imatge.

Per a Aurora Libros fem servir la primera, que és la més predictible. I la regla que evita el 90 % dels problemes: quan canviïs package.json, reconstrueix.

Muntar el codi no n'hi ha prou: el procés node continua executant el que va carregar en arrencar. Node 22 porta la solució de sèrie:

--watch vigila els fitxers importats i reinicia el procés en detectar un canvi. Ja no cal nodemon, encara que continua sent vàlid si necessites les seves opcions avançades (--watch-path, retards, execució de comandes prèvies).

Un avís sobre sistemes de fitxers: la propagació d'esdeveniments inotify a través d'un bind mount no sempre funciona a macOS i Windows. Si --watch no reacciona, fes servir --watch-preserve-output amb sondeig o el mecanisme de l'apartat següent, que no depèn d'inotify dins del contenidor.

Compose incorpora el seu propi sistema de sincronització. La diferència clau: vigila des del host, no des de dins del contenidor, així que funciona igual a Linux, macOS i Windows.

El bloc complet per a Aurora Libros:

Fixa't en el repartiment: la pàgina HTML només necessita copiar-se (sync), però nginx.conf es llegeix en arrencar, així que exigeix sync+restart. I package.json no es pot resoldre copiant: cal reconstruir.

La comanda deixa el terminal ocupat mostrant la sincronització en viu. Amb --no-up no aixeca la pila, només vigila el que ja està aixecat; i si prefereixes veure-ho al costat dels logs, docker compose up --watch combina totes dues coses.

Un avantatge poc comentat de watch enfront del bind mount: pots fer servir el mateix Dockerfile i la mateixa imatge que en producció, perquè el codi no es munta, es copia. Això elimina tota una classe de diferències entre "funciona a la meva màquina" i el servidor.

Amb --inspect=0.0.0.0:9229, Node obre el seu inspector. El 0.0.0.0 no és opcional: per defecte escolta només a 127.0.0.1 del contenidor, inabastable des del host.

.vscode/launch.json:

Les dues claus que gairebé tothom configura malament:

Posa un punt d'interrupció al gestor de /llibres, llança la configuració i executa curl -s http://localhost:8080/api/llibres. L'execució s'atura i pots inspeccionar variables, la pila i la consola, amb el procés corrent dins del contenidor, amb els seus límits de memòria i la seva xarxa.

Avís de seguretat: el port 9229 dóna execució arbitrària de codi. Publica'l només en local ("127.0.0.1:9229:9229") i mai en un servidor.

Dues vies, i convé tenir-les totes dues:

Recorda de la lliçó 04-04 que aurora-db és a la xarxa posterior, que és internal: per publicar-ne el port, l'override l'afegeix també a frontal. I per a còpies ràpides, -T és obligatori:

La manera directa, ja vista a la lliçó 04-03:

Però les proves d'integració necessiten una base de dades de debò i d'un sol ús. Un servei dedicat amb el seu PostgreSQL en tmpfs —és a dir, a RAM— resol les dues coses: aïllament total i una velocitat que el disc no dóna.

Tres peces encaixades: --abort-on-container-exit atura tot tan bon punt acaben les proves, --exit-code-from proves fa que la comanda retorni el codi de les proves (imprescindible a CI), i fsync=off és acceptable només perquè aquestes dades són d'un sol ús; en producció seria una barbaritat.

El servei llavors del perfil dades (lliçó 04-06) carrega un catàleg fictici ampliat sobre els nou títols d'init.sql:

I el reinici complet, la maniobra que faràs més vegades quan alguna cosa s'embolica:

Seixanta segons i tens un entorn idèntic al de la resta de l'equip. Aquí -v és correcte i desitjable: són dades de desenvolupament generades a partir de fitxers versionats. És l'únic context en què aquesta comanda no t'ha de fer por.

A Linux, un bind mount és una operació del nucli: cost zero. A macOS i Windows, Docker corre dins d'una màquina virtual lleugera i cada lectura travessa una frontera entre sistemes de fitxers. Amb node_modules —desenes de milers de fitxers petits— la diferència es nota molt.

L'error de rendiment més freqüent a Windows és tenir el repositori a C:\Users\... i accedir-hi des de WSL per /mnt/c/: cada require() travessa dues capes de traducció. Moure el projecte al sistema de fitxers de Linux multiplica la velocitat per deu.

Les opcions :cached i :delegated que veuràs en documentació antiga eren ajustos de consistència per a l'antic osxfs. Avui s'accepten i s'ignoren: VirtioFS les ha deixat obsoletes. I la millor mitigació continua sent estructural: docker compose watch copia en comptes de muntar, així que evita el problema d'arrel.

Ningú no recorda docker compose -f compose.yaml -f compose.proves.yaml up --abort-on-container-exit --exit-code-from proves. Posa-ho en un fitxer i documenta l'entorn de passada:

Dos detalls no negociables: en un Makefile la indentació és amb tabulador, i l'objectiu destructiu es diu reset —no netejar, no down— perquè ningú no el teclegi per inèrcia. Si prefereixes un dev.sh, la idea és la mateixa: les comandes de l'equip, a Git, al costat del codi.

Muntar tot el projecte sobre /app sense protegir node_modules. El node_modules del host tapa el de la imatge i apareixen mòduls que no existeixen o binaris d'una altra plataforma.

Canviar package.json i esperar que n'hi hagi prou amb desar. Instal·lar dependències exigeix reconstruir: up -d --build o una regla rebuild a develop.watch.

Fer servir --inspect sense 0.0.0.0. L'inspector escolta només dins del contenidor i VS Code no pot connectar-s'hi.

Deixar el 9229 publicat a totes les interfícies. És execució remota de codi. 127.0.0.1:9229:9229 i només en local.

Posar les comoditats de desenvolupament al compose.yaml base. Un build o un port de depuració acaben colant-se al servidor.

Treballar des de /mnt/c/ a WSL 2. El rendiment cau en picat. El repositori va al sistema de fitxers de Linux.

Consell: si el reinici automàtic no es dispara, l'ordre de diagnòstic és: és el fitxer realment dins de la ruta muntada o vigilada? (docker compose exec aurora-api ls -la src/), el procés arrenca amb --watch? (docker compose exec aurora-api ps aux), i si ets a macOS o Windows, canvia a docker compose watch, que no depèn d'inotify dins del contenidor.

Exercici 1. Munta ./api/src a aurora-api, arrenca amb node --watch i demostra el cicle complet: canvia el missatge de /salut al teu editor i comprova amb curl que la resposta canvia sense reconstruir ni recrear el contenidor. Verifica també que el contenidor és el mateix d'abans.

Exercici 2. Configura develop.watch amb les tres accions (sync per a src, sync+restart per a un fitxer de configuració i rebuild per a package.json), llança docker compose watch i provoca-les totes tres. Explica què observes en cada cas i per què cada fitxer necessita una acció diferent.

Exercici 3. Munta l'entorn de proves amb PostgreSQL en tmpfs, executa'l dues vegades seguides i demostra que (a) la segona execució parteix d'una base de dades completament neta i (b) la comanda retorna el codi de sortida de les proves, no el del contenidor de la base de dades.

Solució 1.

Edita api/src/server.js canviant el missatge a "Aurora API operativa i recarregada" i desa:

L'identificador del contenidor és idèntic: no s'ha recreat res. L'única cosa que ha passat és que el procés node dins del contenidor s'ha reiniciat en detectar el canvi en un fitxer que, gràcies al bind mount, és el mateix inode que el del teu editor. Aquest és el cicle de desenvolupament que buscàvem: dos segons entre desar i veure'n l'efecte.

Solució 2.

La progressió és de menor a major cost: sync triga mil·lisegons, sync+restart uns segons, rebuild desenes de segons. Per això convé reservar rebuild per als fitxers que de debò ho necessiten —package.json, package-lock.json, Dockerfile— i no apuntar-lo a un directori sencer: una regla rebuild sobre ./api reconstruiria la imatge cada vegada que toques una línia de codi.

Solució 3.

(a) La segona execució dóna exactament els mateixos resultats i no existeix cap volum: el tmpfs viu a la memòria del host i desapareix en eliminar el contenidor, així que cada execució parteix d'una base de dades acabada d'inicialitzar. És la propietat que fa que unes proves d'integració siguin fiables: si l'execució número cinquanta pot fallar per residus de la quaranta-nou, les proves no valen res.

(b) --exit-code-from proves és el que fa que això sigui utilitzable a CI. Sense aquesta opció, up retorna el codi del primer contenidor que acaba, que pot ser el de la base de dades aturant-se ordenadament amb un 0 alegre mentre les proves fallaven. Comprova-ho fent fallar una prova expressament: el codi passa a 1 i el pipeline es posa en vermell, que és justament el que ha de passar.

Docker ha deixat de ser una cosa que es fa servir "al final, per empaquetar" i s'ha convertit en l'entorn on programes. Saps muntar el codi amb un bind mount i esquivar el problema etern de node_modules —el del host tapant el de la imatge— amb les quatre estratègies possibles i la seva regla d'or: si canvia package.json, cal reconstruir. Tens recàrrega automàtica amb el --watch natiu de Node 22, i per damunt el mecanisme propi de Compose, develop.watch, amb les seves accions graduades per cost: sync per al codi, sync+restart per a la configuració que es llegeix en arrencar i rebuild per a les dependències, vigilant des del host i funcionant igual a les tres plataformes.

Depures de debò: --inspect=0.0.0.0:9229, el port publicat només a 127.0.0.1, i un launch.json amb la correspondència localRoot/remoteRoot que fa que els punts d'interrupció s'aturin al codi que corre dins del contenidor. Entres a la base de dades des del host o amb docker compose exec, executes proves d'integració contra un PostgreSQL efímer en tmpfs amb --abort-on-container-exit i --exit-code-from, carregues dades fictícies amb un servei de llavors i reinicies l'entorn sencer amb una comanda. I coneixes el perquè de la lentitud a macOS i Windows —la frontera entre el host i la màquina virtual— amb les seves mitigacions reals: VirtioFS, el codi dins del sistema de fitxers de WSL 2 i, sobretot, no muntar node_modules. Tot plegat resumit en un Makefile versionat que qualsevol de l'equip pot llegir.

I amb això es tanca el mòdul 4. Vas començar amb cinquanta línies de comandes imperatives encadenades, fràgils i sense versionar, i acabes amb la plataforma sencera declarada en un fitxer de text: quatre serveis més una migració, dues xarxes segmentades amb la zona de dades aïllada de l'exterior, un volum persistent, sondes de salut que distingeixen "arrencat" de "preparat", dependències que respecten aquest matís, límits de recursos, polítiques de reinici, variables parametritzades amb el seu .env.example versionat i els seus secrets fora de l'entorn, perfils per a les eines opcionals i overrides que fan que el mateix projecte serveixi al teu portàtil, a CI i al servidor. Tot revisable en una pull request, tot reproduïble. Els quinze passos d'onboarding de la lliçó 01-07 són avui exactament dos: git clone i docker compose up -d --wait.

A partir d'aquí, el curs canvia de registre. Fins ara has après a fer servir Docker molt bé; al mòdul 5 obriràs la caixa negra i entendràs per què funciona com funciona: les xarxes per dins, amb els seus drivers, taules de rutes i regles d'iptables; l'emmagatzematge a fons, amb controladors i estratègies de còpia de seguretat; la seguretat real, amb usuaris sense privilegis, capacitats del nucli, seccomp i anàlisi de vulnerabilitats; l'optimització d'imatges, on aquests 274 MB de PostgreSQL i aquests 142 MB de l'API es posen a dieta amb construccions multietapa; BuildKit i Buildx, amb memòria cau remota i compilació multiarquitectura; el registre i el monitoratge d'una plataforma en marxa; i, al final, els namespaces, cgroups i capes del nucli de Linux que fa temps que sostenen tot el que has fet des de la primera lliçó. Quan acabis aquest mòdul, ja no seràs algú que sap escriure un compose.yaml: seràs algú que sap què passa exactament quan l'executa.