Vas tancar el mòdul 1 amb les eines a la mà i el problema mesurat: quinze passos manuals per posar en marxa Aurora Libros. El mòdul 2 comença a enderrocar-los, i ho fa des del principi de la cadena: d'on surten les imatges. Fins ara has escrit docker pull node:22-alpine o docker run nginx:alpine sense preguntar-te gaire qui hi ha a l'altre costat, qui va publicar aquesta imatge ni per què t'hi hauries de refiar. En aquesta lliçó obres aquesta capsa. Entendràs què és exactament un registre d'imatges i què és un repositori dins seu, t'autenticaràs amb docker login i veuràs on queden les teves credencials (amb una sorpresa desagradable inclosa), aprendràs a distingir una imatge oficial d'una imatge que algú va pujar un dimarts del 2019 i no va tornar a tocar mai més, coneixeràs els límits de descàrrega que et poden tallar una build en el pitjor moment, i muntaràs el teu propi registre en un contenidor per veure que el mecanisme no té cap mena de màgia. Al final triaràs el repositori on viurà la imatge d'aurora-api durant la resta del curs.

1. Registre, repositori i etiqueta: les tres capes del magatzem
2. Docker Hub: compte i interfície
3. docker login, docker logout i on queden les teves credencials
4. Tipus d'imatge a Docker Hub i com avaluar-ne la confiança
5. Límits de descàrrega: anònim davant d'autenticat
6. Cercar imatges des del terminal amb docker search
7. Repositoris públics i privats
8. Registres alternatius a Docker Hub
9. El teu propi registre en un contenidor
10. El repositori d'Aurora Libros

A la lliçó 01-05 vas aprendre a llegir un nom complet d'imatge:

Ara toca entendre què hi ha darrere de cada tram, perquè són tres coses diferents que la gent confon constantment quan en parla.

• Un registre d'imatges (registry) és un servei: un servidor amb una API HTTP que emmagatzema i serveix imatges. Docker Hub és un registre. ghcr.io n'és un altre. El que muntaràs a l'apartat 9 al teu portàtil també ho és. Un registre conté molts repositoris.
• Un repositori (repository) és una col·lecció d'imatges relacionades entre si, que comparteixen nom i es distingeixen per l'etiqueta. library/nginx és un repositori: a dins hi viuen nginx:1.27, nginx:alpine, nginx:latest… totes són "nginx", en versions o variants diferents.
• Una etiqueta (tag) és una referència llegible que apunta a un manifest concret, identificat al seu torn per un digest sha256:… immutable.

Fixa't en dos detalls del diagrama que expliquen comportaments que ja has vist:

• Diverses etiquetes poden apuntar al mateix digest. 22 i latest són, gairebé sempre, la mateixa imatge amb dos noms. Per això a la lliçó 01-05 docker image ls et mostrava dues files amb el mateix IMAGE ID: no eren dues imatges, era una amb dues referències. Hi tornaràs amb detall a la lliçó 02-06.
• El digest és l'única cosa immutable. L'etiqueta 22-alpine avui apunta a un manifest i d'aquí a tres setmanes pot apuntar-ne a un altre (pedaç de seguretat de Node, actualització d'Alpine). El digest sha256:9f2c… sempre és exactament els mateixos bytes.

Una analogia útil: el registre és la biblioteca; el repositori és el prestatge dedicat a una obra; les etiquetes són els adhesius ("primera edició", "última edició", "edició de butxaca") enganxats a exemplars concrets. Moure un adhesiu no canvia l'exemplar; només canvia a quin exemplar apunta aquest nom.

Quan escrius docker pull nginx:alpine, Docker expandeix el nom així:

Tres regles que es dedueixen de la taula:

1. Si no hi poses registre, s'assumeix Docker Hub (docker.io). És una decisió històrica del client de Docker, no un estàndard; altres eines (Podman, per exemple, lliçó 07-05) poden preguntar-te quin registre vols.
2. Si no hi poses usuari/organització, s'assumeix library/, l'espai de noms reservat a les imatges oficials. Per això nginx i library/nginx són el mateix, i per això ningú més no pot publicar un repositori anomenat simplement nginx.
3. Si no hi poses etiqueta, s'assumeix latest, amb tots els perills que ja coneixes.

Pots comprovar la primera i la segona amb una comanda que ja domines:

Docker et mostra la forma curta perquè el registre és el predeterminat. Si fas el mateix amb una imatge d'un altre registre, el nom apareixerà complet, amb ghcr.io/… al davant. Aquesta asimetria en la sortida és una pista ràpida per saber d'on ve cada imatge de la teva màquina.

Docker Hub (hub.docker.com) és el registre públic per defecte de Docker: allotja milions de repositoris i és on han anat a buscar totes les imatges que has descarregat fins ara. Necessitaràs un compte per a dues coses: pujar la imatge d'aurora-api (lliçó 02-06) i —més immediat— duplicar la teva quota de descàrregues.

1. Entra a https://hub.docker.com i prem Sign Up.
2. Tria un Docker ID. Pensa-t'ho bé: serà l'espai de noms de totes les teves imatges públiques i no es pot canviar després. Al curs farem servir auroralibros com a Docker ID fictici de l'alumne; tu faràs servir el teu de debò allà on aparegui.
3. Verifica el correu electrònic.
4. Activa la verificació en dos passos (Account Settings → Security). A la pràctica no és opcional: el teu compte pot acabar publicant imatges que altres executen, i un compte compromès és un vector d'atac de manual.

Un cop a dins, aquestes són les zones que faràs servir:

Obre https://hub.docker.com/_/node (la barra baixa indica imatge oficial) i observa'n l'estructura, perquè és idèntica a tots els repositoris:

• Descripció: què és la imatge, com es fa servir, variables d'entorn que accepta, exemples. A les imatges ben mantingudes, aquesta pàgina és la documentació real del producte.
• Comanda de descàrrega a dalt a la dreta: el docker pull node a punt per copiar.
• Pestanya Tags: el catàleg d'etiquetes disponibles. És la pestanya que més faràs servir. Per a cada etiqueta et mostra la mida comprimida, les arquitectures disponibles (linux/amd64, linux/arm64…) i quan es va actualitzar per última vegada. Buscar-hi "22-alpine" abans d'escriure-ho en un FROM t'estalvia el clàssic manifest unknown per una etiqueta que no existeix.
• Enllaç al Dockerfile: a les imatges serioses, cada etiqueta enllaça al repositori de GitHub on hi ha el Dockerfile que la va construir. Poder llegir aquest fitxer és una de les millors senyals de confiança que existeixen.

Un exercici de dos minuts que convé fer ara: entra a la pestanya Tags de node, busca 22-alpine i anota'n la mida comprimida i la data d'actualització. Compara-ho amb 22 a seques. La diferència de mida explica per què a la lliçó 01-07 vas triar Alpine per a aurora-api.

Per pujar imatges o per descarregar de repositoris privats necessites autenticar-te. La comanda és directa:

Sense arguments, docker login apunta a Docker Hub. Per a un altre registre, se li passa com a argument:

I per tancar sessió:

Després d'un login correcte, Docker desa la credencial a ~/.docker/config.json. Mira-t'ho:

Aquest camp auth no està xifrat. És simplement usuari:contrasenya codificat en base64, que és una codificació reversible, no un sistema de protecció. Comprova-ho tu mateix:

Qualsevol persona amb accés de lectura al teu ~/.docker/config.json —un altre usuari del sistema amb permisos, un procés maliciós, una còpia de seguretat mal protegida o un contenidor al qual li vas muntar el directori per descuit— té les teves credencials en clar. De fet, Docker t'ho avisa en iniciar sessió:

Tres mesures concretes per mitigar-ho, de menys a més esforç:

a) Fes servir un token d'accés personal en lloc de la teva contrasenya. A Docker Hub, Account Settings → Personal Access Tokens → Generate new token, amb permisos mínims (Public Repo Read-only si només descarregues, Read & Write si publicaràs). Avantatges: si es filtra, es revoca aquest token sense canviar la teva contrasenya, no dona accés al web ni a la configuració del compte, i en pots tenir un per màquina. Es fa servir igual:

b) Evita docker login -p en scripts. Escriure la contrasenya a la línia de comandes la deixa a l'historial de l'intèrpret d'ordres i a la llista de processos. La manera correcta és per entrada estàndard:

--password-stdin llegeix la credencial de la canonada. És el patró obligatori a CI/CD (el veuràs aplicat a la lliçó 06-02).

c) Configura un credential helper. És un programa extern que desa les credencials al magatzem segur del sistema operatiu en lloc de fer-ho en un fitxer de text:

Instal·lació i activació a Linux d'escriptori:

I edita ~/.docker/config.json per afegir-hi la línia del helper:

Ara torna a autenticar-te:

L'objecte d'auths està buit: la credencial ja no és al fitxer, sinó al clauer del sistema, i l'avís ha desaparegut. Docker la recupera del helper cada vegada que la necessita.

Descarregar una imatge i executar-la és, al capdavall, executar programari d'un desconegut a la teva màquina. Docker Hub etiqueta els repositoris en categories que t'ajuden a decidir de qui et refies.

Per a Aurora Libros això es tradueix en una cosa molt concreta: node, postgres, redis i nginx són oficials, i per això són les quatre bases del projecte. No hi ha cap motiu per fer servir algunusuari/node-22-amb-tot al seu lloc.

Els distintius no cobreixen tots els casos: tard o d'hora necessitaràs una imatge de la comunitat. Aquesta és la comprovació que convé aplicar abans d'escriure-la en un FROM:

1. Data de l'última actualització. És a la pestanya Tags. Una imatge que no es toca des de fa un any arrossega un any de vulnerabilitats sense pedaçar del sistema base. És el criteri que més descarta.
2. El Dockerfile és públic? Si no pots llegir com es va construir, estàs executant una caixa negra. Busca l'enllaç a GitHub a la descripció.
3. Mida. Una imatge de 2 GB per servir un binari de 10 MB indica que porta a dins mig sistema operatiu amb eines que no necessites i que amplien la superfície d'atac.
4. Nombre i contingut de les capes. Amb el que has après a 01-05 pots auditar això sense descarregar res més que la imatge:

El que busques en aquesta sortida: instruccions comprensibles i justificables. Una capa amb un curl http://…/installador.sh | sh apuntant a un domini desconegut és una bandera vermella immediata; vol dir que la imatge descarrega i executa codi arbitrari d'un tercer en temps de construcció.

5. Descàrregues i estrelles, amb reserves. Un milió de descàrregues indica que molta gent la fa servir, no que sigui segura; les xifres s'inflen fàcilment amb automatitzacions. Fes-ho servir com a senyal feble, mai com a argument principal.
6. Publica diverses arquitectures? Si treballes en un Mac amb Apple Silicon o en un servidor ARM, necessites linux/arm64. La pestanya Tags ho indica. Si només hi ha amd64, funcionarà per emulació, més lenta (els manifests multiarquitectura es veuen a la lliçó 05-05).

Tot això és avaluació manual i prèvia. L'anàlisi automàtica del contingut d'una imatge a la recerca de vulnerabilitats conegudes (docker scout, escàners al pipeline) i la signatura criptogràfica d'imatges són una altra disciplina, i es tracten a la lliçó 05-03.

Docker Hub limita quantes imatges pots descarregar per unitat de temps. És un límit real que talla builds en producció, i convé conèixer-lo abans que et passi.

Les xifres exactes les revisa Docker periòdicament, així que consulta sempre la pàgina oficial de preus abans de dimensionar res. El que no canvia és l'estructura del problema, i hi ha un matís crític: en el cas anònim el comptador és per IP. Si ets en una oficina, en una universitat o darrere del NAT d'un proveïdor de núvol, comparteixes quota amb tots els altres. Una empresa sencera darrere d'una sola IP pública pot esgotar el límit en minuts sense que ningú hagi fet res estrany.

Quan el superes, l'error és aquest:

I si passa a mitja construcció, la veuràs així:

Com evitar-ho, per ordre d'eficàcia:

• Autentica't sempre, fins i tot per descarregar imatges públiques. Un simple docker login a la teva màquina i als agents de CI duplica la quota i l'aïlla per compte en lloc de fer-ho per IP.
• Aprofita la memòria cau local. Les capes ja descarregades no es tornen a baixar. Un agent de CI efímer que comença sempre en blanc ho descarrega tot cada vegada: és l'escenari que més consumeix.
• Fes servir un registre mirall o una memòria cau d'estirades (pull-through cache) a la teva organització. El registre de l'apartat 9 es pot configurar justament per a això.
• Consumeix les imatges base des d'un altre registre. Moltes imatges estan replicades a ghcr.io, a ECR Public o a mcr.microsoft.com, amb polítiques de límit diferents.

Pots comprovar la teva situació consultant la capçalera que retorna el registre en demanar un manifest, sense descarregar la imatge:

La lectura és: quota de 100 descàrregues en una finestra de 21.600 segons (6 hores), de les quals te'n queden 76. És una comprovació útil quan un pipeline comença a fallar de manera intermitent sense canvis al codi.

No cal obrir el navegador per cercar a Docker Hub:

Columnes: nom del repositori, descripció, estrelles i si és oficial. La primera fila no porta usuari al davant, la marca inequívoca que viu a library/.

Filtres i format disponibles:

Dues limitacions importants de docker search que cal tenir clares:

1. Només cerca a Docker Hub. No consulta ghcr.io ni cap altre registre, encara que hi tinguis sessió oberta. És una limitació de la comanda mateixa, no de la teva configuració.
2. No llista etiquetes. Et diu que existeix el repositori node, però no quines versions hi ha a dins. Per a això, la pestanya Tags del web o una consulta a l'API del registre:

Aquesta comanda consulta l'API pública de Docker Hub i n'extreu els noms de les etiquetes que contenen 22-alpine. És la manera ràpida de verificar des del terminal que una etiqueta existeix abans de posar-la en un FROM i descobrir l'error a mitja build.

En crear un repositori a Docker Hub en tries la visibilitat, i la decisió té conseqüències pràctiques:

La regla d'or: una imatge pública és codi publicat. Tot el que hi ha a dins —el teu server.js, les teves rutes internes, els comentaris del codi, qualsevol fitxer que es va colar al COPY— pot ser inspeccionat i extret per qualsevol. Això connecta directament amb l'advertència de l'exercici 3 de la lliçó 01-07: les credencials mai no entren a la imatge, i amb un repositori públic aquesta regla passa de ser una bona pràctica a ser crítica.

Per al curs, auroralibros/aurora-api serà públic: així en podràs compartir l'enllaç i executar-lo des de qualsevol màquina sense autenticar-te, que és exactament el que vols demostrar. A la lliçó 02-06 veuràs com canviar la visibilitat a privada i com donar accés a un equip, que és el que faria Aurora Libros de debò.

Docker Hub no és obligatori. Aquests són els registres que et trobaràs al món real:

La bona notícia és que tots parlen el mateix protocol, l'OCI Distribution Specification. Per això les comandes són idèntiques a tots ells: canvia el prefix del nom i res més. Un docker push a Docker Hub i un a Harbor són la mateixa operació contra servidors diferents. Ho comprovaràs ara mateix.

Res no aclareix millor què és un registre que aixecar-ne un. La imatge oficial registry:2 implementa el protocol de distribució i cap en uns pocs megabytes.

Repassa les opcions, totes conegudes de la lliçó 01-06: -d el deixa en segon pla, --name li dona un nom manejable i -p 5000:5000 publica el port del registre a la teva màquina. Comprova que respon:

/v2/ és l'arrel de l'API de distribució OCI, i _catalog llista els repositoris. Està buit: acabes d'estrenar-lo. Hi posarem alguna cosa a dins.

Què acaba de passar, pas a pas:

• docker tag no copia ni duplica res: crea un nom nou per a la mateixa imatge local. alpine:3.21 i localhost:5000/alpine:3.21 comparteixen IMAGE ID. És el mecanisme que estudiaràs a fons a 02-06.
• El prefix localhost:5000/ és el que determina la destinació del push. Docker no té cap comanda "puja a aquest servidor": el servidor forma part del nom de la imatge. Aquesta és la idea clau de tota la lliçó.
• La sortida mostra la capa pujada i el digest resultant, el mateix identificador immutable de l'apartat 1.

Verifica el catàleg i les etiquetes del repositori:

I ara la prova de foc: esborra la imatge local i recupera-la des del teu registre.

Has completat un cicle sencer —pull de Docker Hub, tag, push al teu registre, esborrat local, pull del teu registre, run— amb les mateixes comandes que faries servir contra qualsevol registre del món. L'única diferència entre el teu registre de joguina i el d'una multinacional és el prefix del nom i qui administra el servidor.

Un detall important que descobriràs així que passis del localhost: Docker exigeix HTTPS per a qualsevol registre remot. localhost n'està exempt per ser local. Si intentes fer servir 192.168.1.50:5000 sense TLS, obtindràs:

La solució correcta és posar un certificat vàlid davant del registre. La solució ràpida per a una xarxa de laboratori és declarar-lo com a registre insegur a /etc/docker/daemon.json i reiniciar el dimoni:

Fes-ho servir només en entorns aïllats i de prova: sense TLS, qualsevol persona de la xarxa pot llegir i alterar les imatges en trànsit.

Quan acabis d'experimentar, neteja:

Tingues en compte que les imatges que hi vas pujar vivien dins del contenidor i desapareixen amb ell, perquè no vas muntar cap volum. Un registre real necessita emmagatzematge persistent, i aquest és justament el tema de la lliçó 03-06.

Amb tot això, ja pots prendre la decisió que governa la resta del mòdul. La imatge de l'API d'Aurora Libros viurà a:

Que escriuràs en la seva forma curta:

Justificació de cada tram:

La regla d'"un repositori per servei" mereix un comentari, perquè és un error freqüent fer-ho al revés: posar diverses imatges diferents en un mateix repositori distingint-les per l'etiqueta (aurora:api-1.0.0, aurora:web-1.0.0). Tècnicament funciona, però trenca tota la resta: no pots donar permisos diferents per servei, les etiquetes deixen de significar "versió" i la pestanya Tags esdevé il·legible. Un repositori per artefacte desplegable.

Com a preparació per a la lliçó 02-06, crea ja el repositori buit des del web (Repositories → Create repository), amb nom aurora-api, visibilitat pública i una descripció curta com "API REST del catàleg d'Aurora Libros S.L.". No és imprescindible —Docker Hub crea el repositori automàticament al primer push—, però així fixes la descripció i la visibilitat des del principi i evites publicar per accident una cosa privada en públic.

A 02-02 construiràs la imatge que omplirà aquest repositori.

• Confondre registre amb repositori. "Puja la imatge al repositori de Docker" no significa res de precís. El registre és el servidor (docker.io); el repositori és el nom que hi ha a dins (auroralibros/aurora-api). Quan depuris un push fallit, la primera pregunta sempre és a quin registre apunta el nom complet de la imatge.
• Creure que docker login "canvia de registre". No hi ha cap registre actiu. Pots tenir sessió oberta simultàniament a Docker Hub, ghcr.io i el teu registre local; la destinació de cada operació la decideix el prefix del nom de la imatge, no un estat global.
• Deixar la contrasenya real a ~/.docker/config.json. Base64 no és xifratge. Fes servir un token d'accés personal amb permisos mínims i, si pot ser, un credential helper. En un servidor compartit això no és una recomanació, és un requisit.
• docker login -p laMevaContrasenya en un script. Queda a l'historial de l'intèrpret d'ordres i és visible a ps per a qualsevol usuari de la màquina. Fes servir --password-stdin sempre.
• Builds anònimes a CI. És la causa número u del toomanyrequests que apareix "de sobte" un dimarts a la tarda: la IP compartida del proveïdor va esgotar la quota. Autentica els agents de CI encara que només descarreguin imatges públiques.
• Refiar-se de les estrelles. Una imatge de la comunitat amb moltes descàrregues i sense actualitzar des de fa catorze mesos és pitjor opció que una d'oficial menys popular. Prioritza en aquest ordre: oficial → verificada → comunitat amb Dockerfile públic i actualitzada.
• Consell: mira sempre la pestanya Tags abans d'escriure un FROM. Confirma que l'etiqueta existeix, amb quines arquitectures i quan es va actualitzar. T'estalvia el manifest unknown a mitja build.
• Consell: un registre local és la millor eina d'aprenentatge. Quan alguna cosa del flux tag/push/pull no et quadri, reprodueix-la contra localhost:5000: és instantani, no consumeix quota i no publica res a Internet.

Tria tres repositoris de Docker Hub: un d'oficial (postgres), un de Verified Publisher o Sponsored OSS que triïs tu, i un de comunitat que trobis cercant "nodejs" a Explore. Per a cadascun, omple aquesta taula i decideix si el faries servir com a base d'un servei d'Aurora Libros:

Recolza't en el web per als tres primers criteris i en docker image history per inspeccionar com es van construir.

1. Aixeca un registre local al port 5001 (no el 5000, per practicar el mapatge) anomenat aurora-registry-lab.
2. Descarrega redis:7-alpine de Docker Hub.
3. Publica-la al teu registre local amb el nom localhost:5001/aurora-cache:7.
4. Consulta el catàleg del registre i la llista d'etiquetes del repositori amb curl.
5. Esborra totes dues referències locals i torna a descarregar la imatge des del teu registre.
6. Arrenca un contenidor amb ella i comprova que Redis respon.
7. Neteja-ho tot.

Explica la causa de cada missatge i la comanda exacta amb què el resoldries:

Solució a l'exercici 1

Un resultat típic, amb els valors del moment d'escriure aquesta lliçó (els teus variaran, l'important és el raonament):

El raonament per descartar la tercera és acumulatiu, i qualsevol dels punts bastaria per si sol:

• Dos anys sense actualitzar significa dos anys de CVE sense pedaçar al sistema base. Encara que el codi de l'aplicació fos perfecte, la libc, openssl i la resta del sistema no ho són.
• Sense Dockerfile públic no pots saber què hi ha a dins ni auditar-ho.
• latest com a única etiqueta és un símptoma de projecte no mantingut: no hi ha versionatge, així que no pots fixar res ni tornar enrere.
• Només amd64 la fa inservible en un Mac amb Apple Silicon o en instàncies ARM llevat d'emulació.
• La mida delata un sistema base complet amb eines innecessàries.

La conclusió pràctica per a Aurora Libros: les quatre bases del projecte (node, postgres, redis, nginx) són oficials, i aquesta és precisament la raó per la qual es van triar a la lliçó 01-07.

Solució a l'exercici 2

Fixa't en -p 5001:5000: el registre sempre escolta al 5000 dins del contenidor; el que canvies és el port de l'amfitrió. És exactament el mapatge port-amfitrió → port-contenidor de la lliçó 01-06.

El pas 5 és el que demostra l'objectiu de l'exercici: en esborrar les dues referències, la imatge desapareix de debò de la teva màquina (recorda de 01-05 que dues etiquetes sobre el mateix IMAGE ID compten com una sola imatge: mentre quedi una referència, les dades continuen sent-hi). Si el pull posterior funciona, els bytes vénen necessàriament del teu registre.

Solució a l'exercici 3

(a) pull access denied ... may require 'docker login'. El missatge barreja dues causes perquè el registre no distingeix entre "no existeix" i "no tens permís": fer-ho permetria esbrinar quins repositoris privats té una organització. Les causes reals, per freqüència:

1. El nom no porta usuari: aurora-api s'expandeix a docker.io/library/aurora-api, i library/ està reservat a imatges oficials, així que no existeix. Correcte: docker pull auroralibros/aurora-api:1.0.0.
2. El repositori és privat i no hi tens sessió: docker login.
3. Simplement hi ha una errada al nom.

(b) denied en fer push. Estàs intentant pujar a docker.io/library/aurora-api, un espai on ningú no té permís d'escriptura. La imatge ha de portar el teu espai de noms:

Regla general: si el push dona denied, mira el nom abans que les credencials. És més freqüent el nom mal format que la sessió caducada.

(c) toomanyrequests. Has esgotat la quota de descàrregues. Solució immediata:

Si ja estaves autenticat, la quota esgotada és la del teu compte i toca esperar que es renovi la finestra, fer servir un mirall o pujar de pla. A CI, la causa gairebé sempre és que els agents descarreguen de manera anònima: afegeix un pas de login amb --password-stdin al principi del pipeline (lliçó 06-02). Per confirmar el diagnòstic, la consulta de capçaleres ratelimit-* de l'apartat 5.

(d) x509: certificate signed by unknown authority. El registre sí que parla HTTPS, però el seu certificat està signat per una autoritat que la teva màquina no reconeix (típicament una CA interna de l'empresa). No és un problema de credencials. La solució correcta és instal·lar el certificat d'aquesta CA on Docker el busca:

El nom del directori ha de coincidir exactament amb l'amfitrió i el port que fas servir al nom de la imatge. L'alternativa d'afegir-lo a insecure-registries no arregla això: desactivaria la verificació en lloc de resoldre-la, i només és acceptable en un laboratori aïllat. Distingeix-lo de l'error de l'apartat 9 (server gave HTTP response to HTTPS client), que és el cas contrari: allà el servidor no té TLS en absolut.

Ja saps d'on vénen les imatges que executes. Un registre és un servidor que parla el protocol de distribució OCI; a dins té repositoris, col·leccions d'imatges que comparteixen nom; i dins de cada repositori, les etiquetes són punters mòbils a digests immutables. Aquest model de tres capes explica per què nginx significa realment docker.io/library/nginx:latest, per què dues etiquetes poden compartir IMAGE ID i per què la destinació d'un push no és un paràmetre de la comanda sinó part del nom de la imatge.

A més, ja tens compte a Docker Hub, saps que docker login deixa les teves credencials a ~/.docker/config.json en base64 —no xifrat— i com evitar-ho amb tokens d'accés personal, --password-stdin i un credential helper. Pots distingir una Docker Official Image d'una imatge de comunitat abandonada i aplicar una comprovació real de confiança: data d'actualització, mida, Dockerfile públic, capes comprensibles i arquitectures. Coneixes els límits de descàrrega, per què colpegen sobretot les builds anònimes darrere d'una IP compartida i quin error exacte produeixen. I has aixecat el teu propi registre amb registry:2 per comprovar, amb un cicle complet de tag, push, esborrat i pull, que el mecanisme no té res de màgic. La imatge de l'API d'Aurora Libros ja té adreça: auroralibros/aurora-api.

L'única cosa que falta és la imatge. A la lliçó següent, Construint Imatges Docker, passaràs de consumir imatges alienes a fabricar la teva: veuràs què fa exactament docker build, què significa aquell punt final de la comanda —el famós context de construcció—, com el fitxer .dockerignore que va quedar promès a 01-07 retalla aquest context, i com la memòria cau de capes de BuildKit converteix una build d'un minut en una de dos segons si ordenes bé les instruccions. En acabar-la tindràs auroralibros/aurora-api:0.1.0 construïda a la teva màquina, corrent en un contenidor i responent a curl http://localhost:3000/salut. El primer pas dels quinze comença a caure.