Última lliçó. Toca aixecar la vista del projecte i mirar endavant: quines tendències de l'ecosistema tenen substància i quines encara són aposta, què no canviarà —i per això és on convé invertir l'aprenentatge— i què has arribat a construir en aquestes 47 lliçons. Al final hi trobaràs una autoavaluació honesta, recomanacions per continuar i quatre projectes concrets per consolidar el que has après.

1. On és Docker avui
2. Com llegir una tendència
3. Rootless i aïllament reforçat com a norma
4. WebAssembly a l'ecosistema de contenidors
5. La cadena de subministrament com a requisit regulatori
6. Builds més ràpides i reproduïbles
7. Contenidors a la vora i en dispositius
8. Càrregues de treball d'IA
9. Plataformes internes de desenvolupament
10. Resum de maduresa
11. El que no canviarà
12. El camí d'Aurora Libros
13. Autoavaluació
14. Com continuar aprenent
15. Quatre projectes per consolidar

El 2013 Docker era els contenidors. El 2026 és una implementació excel·lent d'un estàndard obert que ell mateix va crear i donar. Aquesta frase sona a declivi i no ho és: és la definició d'èxit d'una tecnologia d'infraestructura.

El que continua sent seu i continua manant: l'experiència de desenvolupament. Docker Desktop, docker compose, BuildKit i Buildx, Scout i la documentació són el camí més curt entre una idea i un contenidor funcionant, i per això continuen sent el punt d'entrada de gairebé tothom. L'estratègia de l'empresa es va moure del centre de dades —on va guanyar Kubernetes— al portàtil del desenvolupador i a la cadena de subministrament, i allà és forta.

Que l'estàndard sigui obert és la millor notícia per a tu: el que has après no caduca amb un producte.

Abans de la llista, un filtre. Per a cada tendència, tres preguntes: quin problema real resol?, quina maduresa té de debò?, i m'afecta a mi ara o d'aquí a cinc anys? Es llegeix així:

Etiquetaré cada tendència amb honestedat, incloses les que estan de moda.

Maduresa: en producció. El mode rootless de Docker (05-03), el de Podman per defecte (07-05) i els SecurityContext obligatoris a Kubernetes van tots en la mateixa direcció: root dins del contenidor deixa de ser acceptable per defecte.

El que ve: polítiques d'admissió que rebutgen el desplegament si el manifest no compleix —Kyverno, OPA Gatekeeper, Pod Security Admission—, i aïllament reforçat (gVisor, Kata) allà on s'executa codi de tercers. Aurora Libros ja ho compleix: corre sense privilegis, amb read_only, cap_drop: [ALL] i no-new-privileges. Allò que vas fer al mòdul 5 per bones pràctiques serà en pocs anys un requisit d'admissió.

Maduresa: prometedor, amb nínxols ja en producció. Wasm és un format de bytecode portable amb un model de seguretat de caixa de sorra. Amb WASI pot fer entrada/sortida, i amb runwasi s'executa com un contenidor més des de containerd.

On encaixa avui: funcions sense servidor amb arrencades en fred inacceptables, plugins executant codi de clients, extensions de proxies i malles, i dispositius amb recursos escassos.

Què no substitueix, i convé dir-ho clar: PostgreSQL no s'executarà en Wasm, ni la teva API amb node_modules complet i accés lliure al sistema de fitxers. Wasm no ve a reemplaçar contenidors; ve a ocupar el buit on un contenidor és massa pesat. Per a aurora-api avui, la resposta és no. Val la pena seguir-lo, no reescriure res per ell.

Maduresa: en producció, i avançant cap a obligatori. És la tendència amb més impacte pràctic a curt termini, i ja l'has implementada sense saber que anaves per davant.

L'empenta ja no és només tècnica. Als Estats Units hi ha requisits d'SBOM per a proveïdors de l'administració des del 2021, i a Europa el Cyber Resilience Act imposa obligacions de seguretat i de transparència sobre components als productes amb elements digitals, amb terminis que es tanquen a la segona meitat d'aquesta dècada. Si el teu programari es ven a empreses europees, això arribarà als teus contractes en forma de qüestionari.

Advertència important: l'abast concret, els terminis i quins productes queden coberts són qüestions jurídiques que canvien, i això no és assessorament legal. Si el teu producte pot estar-ne afectat, consulta-ho amb el departament legal o de compliment normatiu de la teva organització i no ho dedueixis d'un curs tècnic. El que sí que et puc dir és el pràctic: la part tècnica ja saps fer-la, i arribar amb SBOM, signatura i procedència ja muntats converteix una auditoria en un tràmit.

Maduresa: en producció. La build va deixar de ser «esperar» per convertir-se en un problema d'enginyeria, i BuildKit (05-05) és el motor de gairebé tot el que ve.

Dues mereixen atenció. Les imatges deterministes porten la reproduïbilitat a l'extrem: avui la teva build és reproduïble en contingut però els timestamps fan que el digest variï; amb marques de temps fixades, dues builds del mateix commit produeixen el mateix digest, i això fa la procedència verificable per tercers sense confiar en ningú. I les bases mínimes tipus Wolfi o Chainguard: distribucions dissenyades per a contenidors, amb pedaços molt ràpids i objectiu de zero CVE conegudes, que resolen el degoteig de vulnerabilitats heretades de la imatge base. És el successor natural del teu node:22-alpine fixat per digest.

Maduresa: en producció al seu nínxol. Portar contenidors a fàbriques, botigues, vehicles o antenes, on no hi ha centre de dades ni administrador.

Si Aurora Libros obrís vint llibreries físiques amb un terminal de consulta del catàleg a cadascuna, aquest seria el seu terreny: la mateixa imatge multiarquitectura, un k3s per botiga o simplement Compose, i desplegament per GitOps. Cap peça nova per aprendre.

L'interessant de la vora és que inverteix les prioritats que has manejat tot el curs. Al centre de dades, l'amplada de banda és barata i una imatge de 300 MB no molesta ningú; en una botiga amb una connexió compartida, cada megabyte de la imatge es paga en minuts d'actualització multiplicats per vint seus. Allà la feina de 05-04 —baixar de 142 a 102 MB— deixa de ser una elegància i es converteix en la diferència entre actualitzar la flota en una nit o en un cap de setmana.

Maduresa: en producció, amb problemes sense resoldre. És avui el motor de canvi més gran de l'ecosistema, i on més fan mal les limitacions del model actual.

La regla d'or que emergeix, i que és pur sentit comú de contenidors: els pesos del model no van dins de la imatge. Una imatge de 15 GB que s'ha de reconstruir i redistribuir cada vegada que canvia una línia de Python és un desplegament de vint minuts. Els pesos són dades: van en un volum, en un magatzem d'objectes o en un artefacte OCI a part. És exactament la separació entre imatge i estat que vas aprendre a 03-06, aplicada a un problema nou.

I una conseqüència que ja t'afecta: els temps d'arrencada i la mida tornen a importar molt, cosa que empeny tot l'ecosistema cap a imatges més petites i arrencades més ràpides. Ningú no trobarà a faltar aquella empenta.

Maduresa: adoptable, amb molta moda al voltant. La constatació de la qual neixen: Kubernetes és massa per fer que cada desenvolupador el manegi cada dia. La resposta és una capa per damunt —Backstage, Crossplane, Score, Argo CD i un catàleg de plantilles— que ofereix una interfície senzilla i amaga el YAML.

La regla que separa l'èxit del fracàs: una plataforma interna funciona quan abstreu sense ocultar. El dia que alguna cosa falli, algú haurà de mirar els Pods, els esdeveniments i els logs, i allà no hi ha interfície que valgui. Per això el que has après en aquest curs no el fa obsolet una plataforma interna: el fa més valuós, perquè tu ets qui pot baixar-hi quan l'abstracció es trenca.

Si haguessis de dedicar temps aquest trimestre a una sola cosa d'aquesta taula, seria la segona fila. És la que ja té data.

Les tendències són entretingudes; els fonaments són rendibles. Aquests cinc porten una dècada estables i continuaran allà quan les modes d'aquesta lliçó hagin passat:

Aquí és on convé invertir l'aprenentatge. Qui entén de debò aquests cinc punts es mou entre Docker, Podman, containerd, Kubernetes o el que vingui el 2030 llegint la documentació una tarda. Qui només va memoritzar comandes, torna a començar cada vegada.

Hi ha una prova senzilla per saber en quin grup ets. Pensa en aquestes quatre preguntes i respon-les mentalment abans de continuar:

1. Per què canviar una línia de src/index.js no invalida la capa d'npm ci?
2. Per què un contenidor sense estat es pot reemplaçar i un amb estat no?
3. Per què la mateixa imatge serveix per a desenvolupament i per a producció?
4. Per què localhost dins del contenidor no és la teva màquina?

Si les quatre tenen resposta immediata, no són comandes memoritzades: és el model. I el model és el que es transfereix a qualsevol eina futura.

Aurora Libros va començar a 01-07 amb quinze passos manuals d'onboarding: instal·lar Node, instal·lar PostgreSQL de la versió correcta, instal·lar Redis, crear la base, carregar el catàleg, configurar variables, i resar. Dos dies perquè algú nou pogués arrencar el projecte, i un «a la meva màquina funciona» garantit.

Avui Aurora Libros és una plataforma real:

• Una imatge ghcr.io/auroralibros/aurora-api:2.0.0 de 104 MB, multietapa des de node:22-alpine fixat per digest, multiarquitectura (amd64 i arm64), signada amb Cosign, amb SBOM i attestation de procedència.
• Execució sense privilegis: read_only, cap_drop: [ALL], no-new-privileges, usuari no root.
• Configuració fora de la imatge, validada en arrencar i fallant en 0,4 segons si hi falta alguna cosa.
• Aturada ordenada sense perdre peticions i tres sondes amb semàntiques separades.
• Un pipeline que a cada git push prova contra PostgreSQL 16 i Redis 7 reals, construeix en 41 segons amb memòria cau remota, escaneja amb Trivy, signa i publica.
• Desplegament a Kubernetes amb Kustomize, StatefulSet amb PVC per a les dades, Ingress amb TLS, PgBouncer, HPA de 3 a 12 rèpliques que va portar el p95 de 1 840 ms a 88 ms, PodDisruptionBudget i rollback assajat.
• Observabilitat amb Loki, Promtail, Grafana, Prometheus i cAdvisor, amb alertes.
• I l'onboarding: clonar el repositori i executar una comanda.

De quinze passos manuals a una comanda. Aquesta és la feina de 47 lliçons.

Marca amb honestedat. El que no puguis explicar a una altra persona, encara no ho domines.

Si dubtes en tres files o més, torna a aquelles lliçons i executa els exercicis. Llegir-los no compta.

Certificacions que valen alguna cosa (per ordre d'utilitat pràctica):

Documentació de referència, per ordre de rendibilitat:

Projectes de la CNCF que mereixen la teva atenció, agrupats pel problema que resolen:

No els aprenguis tots: tria pel problema que tinguis al davant. Un projecte entès a fons val més que deu coneguts de sentir a dir.

Hàbits que valen més que qualsevol curs: llegeix els CHANGELOG de les eines que fas servir; quan alguna cosa falli, no t'aturis en arreglar-la, entén per què va fallar; llegeix Dockerfiles de projectes seriosos; i explica a un company el que acabes d'aprendre, que és la prova definitiva de si ho vas entendre.

El que de debò fixa el coneixement és aplicar-lo a alguna cosa que t'importi. Per ordre de dificultat:

Projecte 1 — Contenidoritza una aplicació teva. Agafa un projecte propi, real, amb les seves manies. Escriu un Dockerfile multietapa que baixi de 150 MB, treu tota la configuració a variables d'entorn, afegeix-hi les tres sondes i l'aturada ordenada, i munta'l amb Compose al costat de la seva base de dades. Objectiu: que una altra persona l'arrenqui amb una comanda.

Projecte 2 — Un pipeline complet. Sobre l'anterior, munta CI que executi proves amb Testcontainers, construeixi multiarquitectura amb memòria cau remota, escanegi amb Trivy i falli si hi ha crítiques, generi SBOM, signi amb Cosign i publiqui a ghcr.io. Objectiu: que un git push produeixi una imatge signada i verificable sense tocar res.

Projecte 3 — Desplega en un clúster gestionat. Porta l'aplicació a un Kubernetes gestionat amb Kustomize i dos overlays, Ingress amb TLS, HPA, PodDisruptionBudget i observabilitat. Fes una prova de càrrega, troba el coll d'ampolla real i assaja un rollback. Objectiu: trencar-lo a propòsit i recuperar-lo en menys de dos minuts.

Projecte 4 — Contribueix. Tria una imatge oficial o un projecte de la CNCF que facis servir i obre una contribució real: una millora de documentació, un Dockerfile més petit, un hadolint que passi net, un test que falti. Objectiu: passar de consumidor a participant, que és on més s'aprèn.

I un consell sobre tots quatre: acaba'ls. Un projecte acabat i desplegat ensenya més que cinc a mitges.

• Reescriure alguna cosa perquè ha sortit una tecnologia nova. Cap tendència d'aquesta lliçó no justifica reescriure una plataforma que funciona. Els canvis es fan per problemes, no per titulars.
• Confondre «prometedor» amb «a punt». Wasm és tècnicament sòlid i el seu ecosistema és jove. Portar-lo a producció avui per a una API convencional és canviar problemes resolts per problemes oberts.
• Ficar els pesos d'un model a la imatge. Converteix cada desplegament en vint minuts. Els pesos són dades, no codi.
• Esperar que la normativa obligui. Afegir SBOM, signatura i procedència a un pipeline que ja existeix costa una tarda; fer-ho amb un client preguntant i un termini al damunt, setmanes.
• Confiar en una plataforma interna sense entendre el que hi ha a sota. El dia que l'abstracció es trenqui, algú haurà de mirar els Pods. Que aquell algú sàpigues ser tu és el teu avantatge.
• Estudiar eines en lloc de fonaments. Les eines caduquen; el model de capes, la immutabilitat i l'aïllament pel kernel, no.
• Consell: dedica aquest trimestre a la cadena de subministrament. És l'única fila de la taula de maduresa que ja té data.
• Consell: quan avaluïs alguna cosa nova, escriu en tres línies quin problema teu resol. Si no les saps escriure, encara no és per a tu.
• Consell: rellegeix el compose.yaml i el Dockerfile d'Aurora Libros d'aquí a sis mesos. Hi veuràs coses que avui no veus, i aquest és el senyal que has crescut.

Exercici 1 — Avalua una tendència amb criteri. Tria una de les tendències d'aquesta lliçó (Wasm, bases mínimes tipus Wolfi, imatges deterministes, plataformes internes o càrregues d'IA) i escriu un informe breu de decisió per a Aurora Libros: quin problema real resoldria, quina maduresa té, què caldria canviar a la plataforma actual, quin cost i quin risc tindria, i la teva recomanació amb un disparador concret que la faria canviar. Màxim una pàgina.

Exercici 2 — Autoavaluació i pla. Recorre la taula de §13 i marca cada fila com a «ho explico a una altra persona», «ho faig mirant la documentació» o «no ho domino». Per a cada fila del tercer grup, localitza la lliçó corresponent, executa'n els exercicis i anota què et faltava. Converteix el resultat en un pla de quatre setmanes amb dues competències per setmana i una comprovació pràctica de cadascuna.

Exercici 3 — El projecte final. Executa el Projecte 1 de §15 sobre una aplicació teva de debò. Lliurables: el Dockerfile multietapa amb la seva mida final, el compose.yaml amb la base de dades, la configuració per variables d'entorn documentada, les tres sondes, l'aturada ordenada i un README amb les instruccions d'arrencada. Criteri d'èxit: que una persona aliena al projecte l'aixequi seguint només el README, sense preguntar-te res.

Solució 1. Exemple amb bases mínimes tipus Wolfi/Chainguard, que és la de millor relació benefici/cost per a Aurora Libros:

Disparador de revisió: «si d'aquí a dos mesos continuem republicant aurora-api més d'un cop al mes només per CVE de la imatge base, migrem; si no, la base actual fixada per digest és suficient». Fixa't en la forma del disparador: és mesurable i té termini, igual que el de la solució de l'exercici 3 de 07-02. Una recomanació tecnològica sense condició verificable és una opinió.

Solució 2. El pla surt del diagnòstic, així que no hi ha una resposta única, però sí una estructura que funciona:

Tres regles que fan que el pla funcioni: la comprovació sempre és fer, mai llegir; es marca «ho domino» només quan pots explicar-ho a una altra persona sense mirar; i si una setmana cau, es retarda el pla, no es salta la comprovació. L'error clàssic és substituir la pràctica per la relectura: rellegir una lliçó de seguretat no t'ensenya a diagnosticar per què falla readOnlyRootFilesystem, i provocar la fallada, sí.

Solució 3. Rúbrica d'autoavaluació del lliurable. Si alguna cosa no hi és, torna a la lliçó indicada:

L'última fila és l'única que no et pots puntuar tu: demana-ho de debò a algú i cronometra-ho. Si t'ha de preguntar alguna cosa, falta documentació o falta automatització, i en tots dos casos el projecte encara no està acabat. Aquell criteri —que un altre l'aixequi sol— és la mesura més honesta de tot el que has après, i és exactament el problema que Aurora Libros tenia a 01-07 amb els seus quinze passos manuals.

Has arribat al final de 47 lliçons. Vas començar sense saber què era una imatge i acabes amb una plataforma completa construïda amb les teves mans: Aurora Libros, que va passar de quinze passos manuals d'onboarding i un «a la meva màquina funciona» a una imatge de 104 MB multiarquitectura, signada, amb SBOM i procedència, executant-se sense privilegis, desplegada per un pipeline que construeix en 41 segons, escalant sola de 3 a 12 rèpliques en un clúster, observada, amb rollback assajat i amb un onboarding d'una sola comanda.

Pel camí has après les dues coses que importen. La primera són els fonaments que no caduquen: la imatge en capes adreçada per digest, la immutabilitat d'on surten el rollback i la procedència, la configuració per entorn que permet que la mateixa imatge visqui en desenvolupament i en producció, la separació entre construir i executar, i el procés aïllat per namespaces i cgroups del kernel. Aquests cinc punts porten una dècada estables i són la raó que puguis moure't entre Docker, Podman, containerd o el que vingui llegint la documentació una tarda.

La segona és el criteri, que és el que separa qui executa comandes de qui pren decisions. Saps quan Compose és la resposta professional i quan ho és Kubernetes, i saps formular la pregunta que ho decideix: si el clúster es trenca un dissabte a les tres de la matinada, qui l'arregla? Saps que l'host és superfície d'atac i que algú amb nom i cognoms n'ha de respondre. Saps avaluar una eina pel seu manteniment, la seva llicència, la seva procedència i el seu cost de sortida en lloc de fer-ho per la seva popularitat. Saps distingir el que és en producció del que és aposta. I saps que les decisions s'escriuen, amb la seva data i el seu disparador de revisió, perquè d'aquí a un any algú —potser tu— entengui per què es van prendre.

També t'endús alguna cosa menys visible i més valuosa: el costum de no quedar-te a la superfície. Vas obrir el config.json de runc, vas mirar els set namespaces, vas llegir el mediaType del teu propi índex multiarquitectura i vas comprovar que la teva imatge no era «de Docker» sinó un artefacte OCI. Aquella curiositat és el que fa que les tecnologies noves et resultin familiars en lloc d'amenaçadores, perquè gairebé sempre són combinacions diferents de les mateixes peces.

Docker canviarà. Kubernetes canviarà. Apareixeran runtimes, formats i plataformes que avui no existeixen, i alguns dels noms d'aquest curs sonaran antics d'aquí a cinc anys, igual que avui sona Docker Machine. No passa res: els contenidors són un estàndard obert, i tu no has après un producte, has après el model que hi ha a sota. Amb això, el que vingui es llegeix en una tarda.

Ara agafa alguna cosa teva —una aplicació real, amb les seves manies, aquella que fa temps que vols posar en marxa— i contenidoritza-la. Escriu-li el Dockerfile multietapa, treu-li la configuració, posa-li les tres sondes, munta-li el pipeline i desplega-la. Trenca-la a propòsit i arregla-la. Aquest és l'últim exercici del curs i l'únic que no té solució escrita, perquè la solució l'escrius tu.

Gràcies per arribar fins aquí. Que et funcioni en producció.