Portes 44 lliçons construint imatges amb Docker, i hi ha una cosa que convé dir amb claredat: aquelles imatges no són «de Docker». Són artefactes que compleixen un estàndard obert, i funcionen igual a Podman, a containerd, a CRI-O o en un node de Kubernetes sense canviar ni un byte. Aquesta lliçó explica per què, desmunta l'ecosistema peça a peça i executa ghcr.io/auroralibros/aurora-api:2.0.0 fora de Docker per demostrar-ho.

1. La pregunta correcta: de qui és una imatge?
2. L'estàndard OCI i les seves tres especificacions
3. Què significa això a la pràctica
4. El mapa de peces: runtimes de baix i d'alt nivell
5. CRI: per què Kubernetes no parla amb Docker
6. Podman: l'arquitectura sense daemon
7. Rootless per defecte
8. Compatibilitat de comandes i què es trenca
9. Pods, generate kube i play kube
10. Compose, el socket compatible i Testcontainers
11. Docker davant de Podman, i la migració d'Aurora Libros
12. containerd i nerdctl
13. Buildah i Skopeo
14. Aïllament reforçat: gVisor i Kata Containers
15. Taula de decisió

Quan vas executar docker build -t aurora-api:2.0.0 ., Docker no va inventar cap format propi. Va produir un artefacte amb una estructura pública: un manifest JSON, una configuració amb les variables d'entorn, l'ENTRYPOINT, l'usuari i l'historial, i una llista de capes comprimides, tot identificat per digests SHA-256.

Fixa't en el mediaType: hi diu vnd.oci.image.index.v1+json, no «docker». Aquell prefix és la prova literal que la teva imatge és un artefacte OCI, i que la multiarquitectura que vas muntar a 05-05 és una funció de l'estàndard, no de Docker.

L'Open Container Initiative va néixer el 2015 dins de la Linux Foundation, impulsada per la mateixa Docker, que hi va donar el seu format d'imatge i el seu runtime runc. El motiu va ser evitar una guerra de formats incompatibles (hi havia un competidor seriós, rkt, amb format propi). El resultat és que avui el contenidor és un estàndard i no un producte.

Qualsevol constructor produeix imatges que qualsevol registre emmagatzema i qualsevol runtime executa. Aquella quadrícula completa és el que compra l'estàndard.

Conseqüència directa per a Aurora Libros: ghcr.io/auroralibros/aurora-api:2.0.0 —104 MB, dues arquitectures, signada amb Cosign, amb SBOM i attestation de procedència— corre exactament igual a Docker, a Podman, a containerd o en qualsevol node de Kubernetes, i la seva signatura es verifica igual a tots. No has après un producte: has après un estàndard i una de les seves implementacions.

Canviar el de baix nivell és una línia de configuració, i les imatges no se n'assabenten:

Kubernetes necessita parlar amb algun runtime a cada node. En comptes d'acoblar-se a un, va definir la Container Runtime Interface, una API gRPC amb dos serveis: RuntimeService (cicle de vida de Pods i contenidors) i ImageService (imatges).

Docker Engine no va implementar mai CRI, així que va existir un adaptador anomenat dockershim dins del mateix kubelet. Era codi de Kubernetes mantenint compatibilitat amb un producte concret, i es va retirar a la versió 1.24 (2022).

Allò es va comunicar fatal i va generar titulars del tipus «Kubernetes deixa de donar suport a Docker». El que realment va passar va ser que es va eliminar un intermediari: containerd, que ja hi era a sota, va passar a parlar directament amb el kubelet. Les teves imatges no se'n van veure afectades gens ni mica, perquè són OCI. És la millor il·lustració possible de la tesi d'aquesta lliçó.

Podman (Red Hat) és l'alternativa més rellevant a Docker, i la seva diferència estructural és que no hi ha daemon.

La quarta fila és la raó de fons. El «el grup docker és equivalent a root» que vas aprendre a 05-03 simplement no existeix a Podman: no hi ha cap socket privilegiat al qual pertànyer. I l'última importa en entorns regulats: els registres d'auditoria atribueixen les accions a persones, no a un dimoni.

Docker admet el mode rootless des de la 20.10, però s'ha d'activar. A Podman és el normal des del principi, recolzat en user namespaces (05-07) i en els rangs de /etc/subuid i /etc/subgid.

El contenidor es pensa que és l'usuari redis (UID 999) i el kernel el veu com el 100998, un UID sense cap privilegi. Una fuga del contenidor no dona root: dona un usuari que no pot fer res.

Podman replica la CLI de Docker de manera deliberada:

Funciona per a la immensa majoria de la feina diària. El que no és idèntic:

Podman pren manllevada de Kubernetes la seva unitat d'agrupació: el pod, un conjunt de contenidors que comparteixen namespace de xarxa (i per tant localhost i els ports).

Fixa't en REDIS_URL=redis://localhost:6379: dins d'un pod, els contenidors comparteixen la interfície de xarxa, així que s'arriben per localhost. És exactament el model d'un Pod de Kubernetes, assajat al teu portàtil.

I d'aquí en surt el pont més útil de Podman:

generate kube produeix un Pod (o Deployment amb --type deployment) llest per revisar. No substitueix la feina del mòdul 6 —no genera Ingress, HPA, PDB ni sondes afinades— però com a esborrany és molt millor que kompose, perquè parteix d'alguna cosa que ja funciona.

Dos camins per executar el teu compose.yaml:

L'opció B és superior perquè fa servir el Compose oficial v2, amb tota la seva cobertura de claus, parlant amb Podman a través d'un socket que emula l'API de Docker. I aquell mateix socket habilita la resta:

Migració d'Aurora Libros, pas a pas i amb la comprovació al final:

Zero canvis a la imatge, zero canvis al compose.yaml, mateixa signatura verificable i el cache-aside retornant db i després cache. L'única diferència real d'operació és al pas 5: on Docker tenia restart: unless-stopped, aquí hi ha unitats de systemd d'usuari, i l'enable-linger és el detall que s'oblida sempre.

containerd és un projecte graduat de la CNCF, i és la peça que ja fas servir sense saber-ho: Docker Engine hi delega. Gestiona imatges, snapshots, xarxes bàsiques i el cicle de vida, i crida runc. És també el runtime per defecte de la majoria dels Kubernetes gestionats.

La seva CLI nativa, ctr, és una eina de depuració, no de treball:

nerdctl és el que fa containerd usable: replica la CLI de Docker, inclou BuildKit i porta Compose.

nerdctl a més exposa funcions que Docker no té: imatges xifrades, lazy-pulling amb stargz (arrencada sense descarregar la imatge sencera) i contenidors Wasm. És la via habitual per experimentar amb el que ve.

Buildah construeix imatges OCI sense daemon i sense Dockerfile si no en vols:

Skopeo és el que més s'enyora quan no es coneix: inspecciona i copia imatges entre registres sense descarregar-les al disc local.

L'--all copia l'índex multiarquitectura complet, no només la variant de la teva màquina: sense ell, replicaries mitja imatge i el servidor amd64 fallaria. I l'última comanda és or pur en un pipeline: verificar el digest de producció costa una petició HTTP en lloc d'una descàrrega completa.

Els contenidors comparteixen el kernel de l'host. Si apareix una vulnerabilitat d'escalada al kernel, l'aïllament es trenca. Aquests dos runtimes ataquen justament això.

Per a Aurora Libros no calen: el teu codi és teu i ja corre sense privilegis, amb read_only, cap_drop: [ALL] i no-new-privileges. Es justifiquen quan executes codi que no controles —funcions de clients, CI de repositoris públics, quaderns de tercers— i allà el cost de rendiment es paga sense discussió.

La conclusió honesta: el 2026 Docker continua sent l'elecció natural per a desenvolupament per ecosistema i comoditat, Podman guanya en entorns on la seguretat i la política del sistema manen, i containerd és el que executa el món en producció sense que gairebé ningú no el teclegi. I les tres coses executen la teva mateixa imatge.

• Creure que cal reconstruir per canviar de runtime. No. El digest és el mateix i la signatura de Cosign es verifica igual.
• Repetir que «Kubernetes va deixar de donar suport a Docker». El que es va retirar va ser dockershim, un adaptador. Les imatges OCI mai no van estar en qüestió.
• Barrejar contenidors de root i d'usuari a Podman. Els magatzems estan separats: el que construeixes amb sudo podman no ho veu podman. És la confusió número u en començar.
• Esperar restart: always a Podman. No hi ha daemon. Genera unitats amb podman generate systemd i no oblidis loginctl enable-linger.
• Publicar el port 80 en rootless sense ajustar res. Els ports privilegiats estan vetats. Ajusta ip_unprivileged_port_start o posa un proxy al davant.
• Copiar imatges amb skopeo copy sense --all. T'endús només una arquitectura i l'altre entorn falla en desplegar.
• Fer servir ctr per al dia a dia. És una eina de depuració de containerd. Fes servir nerdctl.
• Consell: executa docker buildx imagetools inspect --raw sobre la teva imatge i llegeix el mediaType. Veure vnd.oci a la pantalla fixa la idea millor que qualsevol explicació.
• Consell: si t'interessa Podman, comença pel socket compatible i docker compose. Migres l'execució sense migrar les eines.
• Consell: podman generate kube és el millor esborrany de manifestos que existeix, perquè parteix d'alguna cosa que ja funciona.

Exercici 1 — Demostra la portabilitat. Executa ghcr.io/auroralibros/aurora-api:2.0.0 amb Docker i amb Podman (o nerdctl) a la mateixa màquina. Compara el digest de la imatge en tots dos, comprova que l'endpoint /llibres retorna els nou títols en els dos casos i verifica la signatura de Cosign contra el registre. Escriu què és idèntic i què canvia entre totes dues execucions.

Exercici 2 — Un pod a l'estil Kubernetes amb Podman. Crea un pod aurora que contingui aurora-cache (redis:7-alpine) i aurora-api, comunicant-se per localhost, amb el port 8080 publicat. Comprova que el cache-aside funciona (origen: db la primera vegada, cache la segona). Després genera el manifest de Kubernetes amb podman generate kube, llegeix-lo i anota tres coses que li falten per ser apte per a producció segons el que has après al mòdul 6.

Exercici 3 — Skopeo al pipeline. Escriu un script que, sense descarregar cap imatge, comprovi si el digest de ghcr.io/auroralibros/aurora-api:2.0.0 coincideix amb el que hi ha desplegat en producció (llegeix-lo d'un fitxer digest-produccio.txt), i que en cas de discrepància repliqui la imatge completa, amb les seves dues arquitectures, al registre intern registre.intern:5000. L'script ha de retornar 0 si tot coincideix i 10 si ha hagut de replicar.

Solució 1.

Idèntic: el digest, el contingut, el comportament de l'API i la verificació de la signatura —perquè Cosign valida un artefacte que viu al registre, no al runtime—. Canvia el que envolta l'execució: a Docker el contenidor és fill de dockerd (root) i apareix a ps aux com a tal; a Podman rootless és fill de conmon sota el teu UID, el procés intern es mapeja a un UID alt de l'host, i podman ps només mostra els teus contenidors. També canvia la xarxa (netavark davant del bridge de Docker) i la gestió de l'arrencada automàtica. Cap d'aquestes diferències no afecta l'artefacte: el que s'executa és exactament el mateix.

Solució 2.

El que li falta al manifest generat per ser apte per a producció: (1) les tres sondes —genera com a molt el que va deduir del contenidor, no les startupProbe, livenessProbe i readinessProbe sobre /salut/viu i /salut/preparat que vas separar a 06-01—; (2) resources amb requests i limits, sense els quals el planificador no pot col·locar el Pod amb criteri ni l'HPA calcular el percentatge d'ús; (3) és un Pod solt, no un Deployment, així que no hi ha rèpliques, ni rolling updates, ni rollback, ni recuperació si el node cau. N'hi afegiria dues més: no hi ha ConfigMap/Secret (la configuració va com a variables literals, incloses les credencials) i no hi ha Service ni Ingress. Serveix com a esborrany excel·lent perquè parteix d'alguna cosa que funciona, i com a recordatori que tot el que fa que un desplegament sigui apte per a producció és feina deliberada.

Solució 3.

Les claus. skopeo inspect --format '{{.Digest}}' fa una única petició HTTP al manifest: comprovar si alguna cosa ha canviat costa mil·lisegons en lloc de descarregar 104 MB, i això permet executar-ho cada cinc minuts sense cost. skopeo copy transfereix de registre a registre sense materialitzar capes al disc local, cosa que un docker pull seguit d'un docker push no pot fer. L'--all és imprescindible: sense ell copiaries només el manifest que correspon a l'arquitectura de l'executor, i el dia que un node arm64 tirés de la còpia interna, el pull fallaria amb un error de plataforma que costa força diagnosticar; la verificació posterior amb --raw confirma que les dues arquitectures hi han arribat. I el codi de sortida 10 distingeix «no hi havia res a fer» d'«he replicat», que és el que permet encadenar un pas de notificació al pipeline només quan hi ha hagut canvi real.

Ja saps per què les imatges que has construït durant tot el curs no són «de Docker». Ho has comprovat llegint el mediaType del teu propi índex multiarquitectura: application/vnd.oci.image.index.v1+json. L'Open Container Initiative normalitza tres coses —la Image Spec que dona forma a les teves imatges, la Runtime Spec que defineix el config.json que vas obrir a 05-07, i la Distribution Spec que regeix cada push a ghcr.io—, i d'aquí en surt la quadrícula completa: qualsevol constructor, qualsevol registre, qualsevol runtime.

Tens el mapa de peces ordenat per capes: runtimes de baix nivell que viuen mil·lisegons (runc, crun, youki) davant de gestors d'alt nivell (containerd, CRI-O, Podman, Docker Engine), amb CRI al mig explicant per què el kubelet parla amb containerd i per què la retirada de dockershim a la 1.24 va ser eliminar un intermediari, no deixar de donar suport a les teves imatges.

Coneixes Podman a fons: sense daemon, amb els contenidors com a fills del teu usuari i no d'un procés root, cosa que fa que el «grup docker és root» de 05-03 simplement no existeixi; rootless per defecte sobre user namespaces, amb les seves quatre limitacions reals i les seves solucions; els pods que assagen el model de Kubernetes al teu portàtil amb localhost entre contenidors; generate kube i play kube com el millor esborrany de manifestos que existeix, perquè parteix d'alguna cosa que funciona; i el socket compatible que et deixa fer servir el docker compose oficial i Testcontainers sense canviar d'eines. I has migrat Aurora Libros de debò: mateixa imatge, mateix digest, mateixa signatura verificada, mateix compose.yaml, amb el cache-aside retornant db i després cache, i systemd d'usuari ocupant el lloc de restart: unless-stopped.

Completen el quadre containerd —la peça que ja feies servir sense saber-ho— amb ctr per depurar i nerdctl per treballar, inclòs nerdctl compose; Buildah per construir sense daemon; Skopeo per inspeccionar i copiar entre registres sense descarregar res, amb l'--all que evita replicar mitja imatge; i gVisor i Kata quan cal executar codi que no controles i el cost de rendiment es paga de gust. La taula de decisió et diu quan Docker continua sent l'elecció natural i quan compensa una altra cosa.

A l'última lliçó del curs aixequem la vista del tot: cap on va l'ecosistema de contenidors, quines tendències tenen substància i quines són aposta, què no canviarà —i per això és on convé invertir l'aprenentatge—, i el tancament complet del camí que ha recorregut Aurora Libros des d'aquells quinze passos manuals d'onboarding.