Fa quatre lliçons que arrossegues la mateixa avaria i ja saps exactament què la causa: nslookup aurora-db retorna NXDOMAIN perquè la xarxa bridge per defecte no té DNS intern entre contenidors. La connectivitat hi és —nc -zv 172.17.0.2 5432 respon succeeded—, però l'API no sap com es diu la seva base de dades.

Aquesta lliçó és la que ho arregla, i amb dues comandes. Però abans d'escriure-les entendràs de debò el model de xarxa de Docker: per què cada contenidor té el seu propi localhost, què fa cadascun dels drivers integrats, en què es diferencia la bridge per defecte d'una xarxa creada per tu, i quina és la diferència —que es confon constantment— entre publicar un port i que dos contenidors es parlin. Després crearàs aurora-net, mouràs els tres serveis a dins, i executaràs el curl que fa tot el curs que esperes. I per rematar-ho, posaràs davant aurora-web amb Nginx com a proxy invers, i obriràs la llibreria completa al navegador.

1. Per què els contenidors no es veuen entre ells
2. Els drivers de xarxa integrats
3. La bridge per defecte enfront de les xarxes definides per l'usuari
4. Les comandes de docker network
5. Publicació de ports, revisitada
6. Pràctica: aurora-net i la resolució de noms
7. El moment de la veritat: /llibres retorna els vuit llibres
8. aurora-web: Nginx com a proxy invers
9. Connectar i desconnectar xarxes en calent
10. Bones pràctiques de xarxa

Un contenidor no és només un procés aïllat: té el seu propi namespace de xarxa. Això significa que posseeix, en exclusiva, la seva llista d'interfícies, la seva taula de rutes, les seves regles de tallafocs, els seus ports i —això és el que confon tothom— el seu propi localhost.

Tres localhost diferents a la mateixa màquina. Quan server.js intentava connectar-se a localhost:5432 al mòdul 2, estava preguntant per PostgreSQL dins del seu propi contenidor, on només viu node. D'aquí l'ECONNREFUSED: algú va contestar (el mateix contenidor) dient que allà no hi ha ningú escoltant.

Comprova-ho tu mateix:

Cadascun amb la seva IP, i al localhost de l'API no hi ha cap base de dades. La regla, en una línia:

Dins d'un contenidor, localhost sempre significa "jo mateix". Per parlar amb un altre contenidor cal fer servir la seva adreça: la seva IP o, molt millor, el seu nom.

Docker implementa les xarxes mitjançant drivers intercanviables:

Les tres primeres vénen preconfigurades i les veus amb:

Una ullada ràpida a host i none, que es fan servir poc però convé reconèixer:

Amb --network host, el contenidor té la mateixa IP que la teva màquina: no hi ha -p que valgui perquè els ports són directament els del host, i no hi ha cap aïllament de xarxa. Amb --network none, només existeix lo: ni tan sols pot fer ping a res.

Aquí hi ha el cor de la lliçó. Existeixen dos tipus de xarxa bridge i es comporten de manera molt diferent:

Només la primera fila importa avui, però és determinant: en una xarxa pròpia, Docker aixeca un servidor DNS intern a 127.0.0.11 que resol els noms dels contenidors connectats a aquesta xarxa. A la bridge per defecte, aquest DNS existeix però només reenvia consultes als servidors del host: no coneix cap nom de contenidor. Aquest és, literalment, tot el misteri que arrossegues des de la lliçó 02-06.

Abans d'arreglar-ho, deixa constància del punt de partida:

Amb opcions, quan necessitis control:

--internal mereix atenció: una xarxa interna permet que els contenidors es parlin entre ells però els talla la sortida a l'exterior. És una defensa excel·lent per a una base de dades que no té per què sortir a Internet, i es reprèn a la lliçó 05-03.

I la consulta més útil de totes: qui hi està connectat.

De moment no imprimeix res: la xarxa és buida.

Una xarxa amb contenidors connectats no es pot esborrar (network ... has active endpoints). I les tres xarxes predefinides —bridge, host, none— no es poden eliminar mai.

Ara que entens el model, la taula de la lliçó 03-01 cobra sentit ple:

I aquesta és la distinció que cal tenir absolutament clara:

D'aquí surten dos errors clàssics que ara pots evitar:

• Publicar ports "perquè els contenidors es vegin". No cal i a sobre exposa serveis interns. aurora-db no necessita cap -p perquè l'API la faci servir; només el necessites tu, si vols connectar-t'hi amb un client des del host.
• Fer servir el port del host a la cadena de connexió d'un altre contenidor. Si publiques -p 5433:5432, un altre contenidor s'ha de continuar connectant a aurora-db:5432, el port intern. El 5433 només existeix per al host.

Mans a l'obra. Primer, la xarxa:

Ara recrea els tres serveis a dins seu. Com que la xarxa és un ajust de namespace, es fixa en crear el contenidor (lliçó 03-01), així que cal esborrar i tornar a crear:

Fixa't en un canvi important a aurora-cache: ja no porta -p. Ningú des del host no necessita parlar amb Redis; només l'API, i per a això n'hi ha prou de ser a la mateixa xarxa. És el principi d'exposar el mínim imprescindible.

Abans d'arrencar l'API, torna a carregar el catàleg, perquè el contenidor de la base de dades és nou:

Apunta't aquesta molèstia, perquè és la segona vegada que la pateixes: cada vegada que recrees aurora-db perds les dades i les has de tornar a carregar a mà. Aquesta és la mancança que resol la lliçó 03-06.

I ara l'API:

Ja hi som. La mateixa comanda que fa deu minuts retornava codi 2 i cap línia, ara resol els tres noms. No has canviat ni una línia de server.js, ni el Dockerfile, ni el fitxer d'entorn: només has posat els contenidors en una xarxa pròpia.

Comprova també la connectivitat real, port a port:

Tots tres, per nom. I fixa't en el detall: aurora-cache respon al 6379 encara que no vas publicar cap port. La publicació és per al host; dins de la xarxa, tots els ports del contenidor estan disponibles per als seus veïns.

I l'estat de la flota:

(healthy). Aquest parèntesi fa quatre lliçons que diu unhealthy. El HEALTHCHECK que vas escriure a la lliçó 02-04 fa la seva comprovació contra /salut, /salut consulta PostgreSQL i Redis, tots dos responen, i per primera vegada retorna 200. I fixa't en la línia d'aurora-cache: 6379/tcp sense més, sense fletxa. Exposat però no publicat.

db: ok. cache: ok. I ara, la comanda que fa tot el curs que esperes:

Els vuit llibres. El jardín de senderos que se bifurcan, Rayuela, Cien años de soledad, La sombra del viento, Nada, La casa de los espíritus, Los detectives salvajes i El tiempo entre costuras, ordenats per títol, servits per una API en un contenidor, llegits d'una base de dades PostgreSQL en un altre contenidor, a través d'una xarxa virtual que has creat tu. Atura't un segon en això: la plataforma d'Aurora Libros està viva. És la primera vegada des de la lliçó 01-07, on l'executaves a mà en quinze passos i fallava, que el sistema complet funciona d'extrem a extrem.

I hi ha una segona comprovació, més subtil, que demostra que la memòria cau també està fent la seva feina:

La primera crida va anar a PostgreSQL i va desar el resultat a Redis amb un TTL de 60 segons; la segona ja el va servir des de la memòria cau. Els tres contenidors estan cooperant: l'API parla amb la base de dades pel seu nom i amb la memòria cau pel seu. Comprova-ho també per l'altre extrem:

Aquesta última fila és la lliçó que cal endur-se: el problema mai no va ser a l'aplicació ni a la imatge. Era a com es connectaven els contenidors entre ells.

Falta el quart servei. El teu web/index.html de la lliçó 01-07 crida /api/llibres, una ruta relativa, no http://localhost:3000/llibres. Aquell disseny era deliberat: el navegador ha de parlar amb un únic origen, i qui reparteix per dins és Nginx.

Crea ~/aurora-libros/web/nginx.conf:

Línia a línia, el que importa:

Arrenca el contenidor:

Dos detalls de la comanda:

• Els dos -v munten fitxers del host en només lectura (:ro). És la sintaxi mínima de la lliçó 03-01; la lliçó 03-06 explica què són exactament aquests muntatges i per què :ro és important en fitxers de configuració.
• --stop-signal SIGQUIT aplica el que vas aprendre a la lliçó 02-04: Nginx fa una aturada ordenada amb SIGQUIT i una d'abrupta amb SIGTERM. Amb aquesta opció, docker stop aurora-web no talla peticions a mig servir.

Comprova la cadena completa:

Obre http://localhost:8080 al navegador. La pàgina d'Aurora Libros carrega, crida /api/llibres, Nginx la reenvia a aurora-api, l'API consulta PostgreSQL o Redis, i la taula s'omple amb els vuit títols i els seus preus en euros. L'arquitectura completa, funcionant:

Ni una sola IP escrita a mà enlloc: aurora-web busca aurora-api, i aurora-api busca aurora-db i aurora-cache, tots per nom.

Amb xarxes definides per l'usuari, i només amb elles, pots canviar la topologia sense recrear res:

aurora-db té ara dues interfícies i dues IPs, una a cada xarxa. És el patró habitual per donar accés a una eina d'administració sense obrir la xarxa de l'aplicació:

Adminer veu la base de dades, però no veu aurora-api ni aurora-cache, perquè no és a aurora-net. Aïllament per disseny.

I un apunt sobre àlies de xarxa, que seran importants al mòdul 4:

Un contenidor pot respondre a diversos noms a la mateixa xarxa. És el que permet, per exemple, canviar d'implementació sense tocar la configuració de qui la consumeix.

Com queda la superfície exposada d'Aurora Libros:

En un desplegament real, fins i tot el -p 3000:3000 de l'API sobraria: si el navegador només parla amb Nginx, l'API no necessita estar publicada. Ho pots provar recreant-la sense -p i veuràs que http://localhost:8080/api/llibres continua funcionant perfectament, perquè el proxy hi arriba per la xarxa interna.

El que aquesta lliçó no cobreix, i on es veu: com funciona el bridge per dins (parelles veth, iptables, nat), les xarxes overlay entre diversos hosts, macvlan i les polítiques de xarxa s'estudien a la lliçó 05-01 i a la 06-03.

• Fer servir localhost per referir-se a un altre contenidor. Dins d'un contenidor, localhost és ell mateix. Fes servir el nom de l'altre contenidor.
• Deixar els contenidors a la bridge per defecte i esperar que es resolguin per nom. No passarà mai. Crea una xarxa amb docker network create.
• Escriure IPs a mà. Funciona fins al següent reinici. Docker assigna les IPs per ordre d'arrencada.
• Fer servir el port publicat del host a la connexió entre contenidors. Amb -p 5433:5432, un altre contenidor ha de continuar fent servir el 5432.
• Publicar ports "perquè es vegin entre ells". No cal, i exposa serveis interns a tota la xarxa.
• Intentar canviar de xarxa amb docker start. La xarxa es fixa en crear. Es canvia amb network connect/disconnect, o recreant.
• 502 a Nginx després de recrear l'API. Nginx va desar a la memòria cau la IP antiga. Es resol amb resolver 127.0.0.11 valid=10s i proxy_pass sobre una variable, com a la configuració d'aquesta lliçó.
• Oblidar la / final de proxy_pass. Sense ella, /api/llibres es reenvia com a /api/llibres i l'API respon 404. Amb ella, hi arriba com a /llibres.
• Consell: docker network inspect és la manera més ràpida de respondre a "qui hi ha en aquesta xarxa i amb quina IP?".
• Consell: per diagnosticar, llança netshoot connectat a la xarxa (--network aurora-net) i prova nc, dig i curl des de dins seu.

Crea dues xarxes, xarxa-a i xarxa-b. Aixeca un contenidor servidor-a amb nginx:alpine a xarxa-a, i dos clients de nicolaka/netshoot: client-a a xarxa-a i client-b a xarxa-b. Demostra amb comandes que:

1. client-a resol servidor-a pel nom i obté un HTTP 200.
2. client-b no el resol ni hi arriba, ni per nom ni per IP.
3. Després, sense recrear res, fes que client-b hi pugui arribar, i verifica quantes IPs té llavors.

Aixeca una pila mínima en una xarxa xarxa-botiga: un mini-db amb redis:7-alpine sense cap -p, i un mini-api amb nicolaka/netshoot que executi sleep 3600, publicant -p 9999:80. Respon amb comandes i explicacions:

1. Pot mini-api parlar amb mini-db? Demostra-ho.
2. Pots tu, des del host, parlar amb mini-db amb redis-cli o nc? Per què?
3. Què respon curl localhost:9999 i per què, si mini-api no té cap servidor web?
4. Recrea mini-db amb -p 127.0.0.1:6380:6379 i repeteix el punt 2. Ha canviat alguna cosa per a mini-api?

Amb la plataforma d'Aurora Libros funcionant, provoca i diagnostica dues avaries reals del proxy:

1. Canvia a nginx.conf la destinació a http://aurora-api-inexistent:3000, recarrega Nginx amb docker kill -s SIGHUP aurora-web i observa què retorna curl localhost:8080/api/llibres. Diagnostica amb docker logs aurora-web.
2. Restaura la destinació correcta però treu la barra final de proxy_pass. Recarrega i observa el nou error. Explica exactament quina ruta li està arribant a aurora-api (comprova-ho amb docker logs aurora-api).
3. Deixa-ho tot correcte i demostra, recreant aurora-api sense -p, que la web continua funcionant a localhost:8080.

Solució a l'exercici 1

1. Des de client-a:

2. Des de client-b:

Aquí hi ha dues fallades diferents i totes dues importen: el nom no es resol (no comparteixen xarxa, així que el DNS de xarxa-b no coneix servidor-a) i tampoc no funciona la IP, perquè són dues bridges separades i el trànsit entre elles no està permès. Compara-ho amb el diagnòstic de la lliçó 03-04: allà el nom fallava però la IP funcionava, cosa que demostrava que sí que compartien xarxa. La combinació de les dues proves és el que distingeix "mateixa xarxa sense DNS" de "xarxes diferents".

3. Connectar en calent:

Dues IPs, una per xarxa, sense haver aturat ni recreat el contenidor. Això només és possible amb xarxes definides per l'usuari.

Solució a l'exercici 2

1.

Sí, perfectament, i mini-db no publica cap port. Dins d'una xarxa compartida, tots els ports del contenidor estan disponibles per als seus veïns: -p no hi té res a veure.

2.

No. Com que mini-db no va publicar cap port, no existeix cap regla que reenviï trànsit del host cap a ell. El host i la xarxa de Docker són dos àmbits diferents: el host només arriba al que s'ha publicat explícitament.

3.

La publicació existeix —docker ps mostra 0.0.0.0:9999->80/tcp—, però dins del contenidor no hi ha res escoltant al 80: mini-api només executa sleep. És la demostració que -p no comprova res: crea el reenviament encara que la destinació estigui buida. És el mateix error que es comet en invertir l'ordre a -p 80:8080.

4.

Ara tu et pots connectar des del host pel port 6380, i per a mini-api no ha canviat absolutament res: continua fent servir mini-db:6379, el port intern. Els dos camins són independents.

Solució a l'exercici 3

1. Destinació inexistent:

502 Bad Gateway és l'error de "el proxy no ha pogut parlar amb la destinació", i el registre en dona el motiu exacte: could not be resolved. És el mateix NXDOMAIN de la lliçó 03-04, vist des de Nginx. I val la pena notar que la web estàtica es continua servint sense problema a http://localhost:8080/: només falla la ruta /api/.

2. Sense la barra final:

Ara sí que arriba a l'API, però amb la ruta equivocada. Amb la barra final, proxy_pass http://aurora-api:3000/ substitueix el prefix /api/ per /, així que /api/llibres hi arriba com a /llibres. Sense ella, Nginx concatena la ruta completa i l'API rep /api/llibres, una ruta que server.js no defineix, d'aquí el 404 d'Express. Un sol caràcter, i la meitat dels proxies mal configurats del món s'expliquen per ell.

3. Restaurar i treure la publicació de l'API:

Just el que es buscava: des del host, el port 3000 ja no existeix; des de la web, els vuit llibres continuen arribant. L'API ha deixat d'estar exposada i el servei no se n'ha ressentit, perquè Nginx hi arriba per la xarxa interna. És exactament l'arquitectura que voldries en producció: una sola porta d'entrada.

Com que a les lliçons següents convé poder cridar l'API directament per fer proves, torna a deixar-la publicada:

El misteri està resolt i la plataforma està viva. Saps que cada contenidor té la seva pròpia pila de xarxa i el seu propi localhost, i que per això localhost:5432 dins de l'API preguntava per una base de dades que mai no va ser allà. Coneixes els drivers integrats —bridge per a gairebé tot, host quan no vols aïllament ni NAT, none per a aïllament total— i saps que overlay, macvlan i ipvlan existeixen per a escenaris de diversos hosts i d'integració amb la xarxa física que veuràs a les lliçons 05-01 i 06-03.

I tens clavada la diferència que ho explicava tot: la bridge per defecte no té DNS intern; una xarxa definida per l'usuari sí. Un docker network create aurora-net i un --network aurora-net a cada contenidor, i getent hosts aurora-db va passar de retornar codi 2 a retornar 172.18.0.2 aurora-db. Sense tocar una línia de server.js, ni el Dockerfile, ni el fitxer d'entorn. També saps connectar i desconnectar xarxes en calent per donar accés puntual a una eina d'administració, i posar àlies de xarxa a un contenidor.

Distingeixes publicar un port de comunicar dos contenidors: -p és perquè el host i l'exterior hi entrin; dins de la xarxa, tots els ports estan disponibles per nom sense publicar res. Per això aurora-cache ja no porta -p, aurora-db està lligada a 127.0.0.1, i has demostrat que fins i tot l'API pot viure sense publicació si Nginx és l'única porta d'entrada.

El resultat, en una línia: curl http://localhost:3000/llibres retorna els vuit llibres d'Aurora Libros, servits per Node des de PostgreSQL, desats a la memòria cau de Redis amb el seu TTL de 60 segons, i http://localhost:8080 mostra la llibreria completa al navegador a través d'un proxy invers que reenvia /api/ sense exposar l'API. El healthcheck marca healthy per primera vegada en tot el curs. Quatre contenidors, una xarxa, zero IPs escrites a mà.

Queda un problema, i ja l'has patit dues vegades en aquesta mateixa lliçó: cada vegada que recrees aurora-db, els vuit llibres desapareixen i has de tornar a carregar init.sql amb docker cp. Les dades viuen en un volum anònim que ningú no controla, o directament a la capa d'escriptura que mor amb el contenidor. A la lliçó següent, Persistència de Dades amb Volums, atacaràs aquest problema d'arrel: veuràs els tres tipus de muntatge —volums gestionats, bind mounts i tmpfs—, la diferència entre -v i --mount, on viuen realment els volums i per què no els has de tocar a mà. Donaràs a PostgreSQL el volum aurora-dades, muntaràs init.sql perquè s'executi tot sol, i repetiràs la prova definitiva: inserir un llibre nou, destruir el contenidor de la base de dades, recrear-lo, i comprovar que el llibre continua allà.