Abans d'escriure la teva primera comanda, cal que entenguis quin problema has vingut a resoldre. Docker no és una moda ni una eina més de la caixa del desenvolupador: és la resposta a un mal concret i molt antic del desenvolupament de programari, el que fa que el mateix codi es comporti de manera diferent segons on s'executi. En aquesta lliçó veuràs quin és aquest mal, en què consisteix exactament la contenidorització, en què es diferencia de les màquines virtuals que potser ja coneixes, i quins són els tres conceptes —imatge, contenidor i registre— sobre els quals se sosté absolutament tot el que veuràs a la resta del curs. Encara no instal·laràs res ni teclejaràs comandes: aquesta lliçó construeix el mapa mental que farà que els sis mòduls següents tinguin sentit.

1. El problema real: "a la meva màquina funciona"
2. La deriva d'entorns i l'infern de dependències
3. Què és la contenidorització
4. Què és Docker concretament
5. Contenidors davant de màquines virtuals
6. Els beneficis que n'obtens
7. Casos d'ús reals
8. Els tres conceptes fonamentals: imatge, contenidor i registre
9. El projecte que construiràs: Aurora Libros

Imagina't aquesta escena, perquè passa cada dia a milers d'equips. Una desenvolupadora acaba una funcionalitat, la prova al seu portàtil, tot va bé i fa push. El servidor d'integració contínua la compila i falla. El seu company es descarrega la branca i a ell sí que li funciona. Es desplega a l'entorn de preproducció i l'aplicació arrenca però retorna errors estranys al cap de tres hores. La frase que tanca la discussió és sempre la mateixa: "doncs a la meva màquina funciona".

El problema no és que ningú menteixi. Tothom diu la veritat. El problema és que "la meva màquina", "el servidor de CI" i "preproducció" són quatre entorns diferents que només s'assemblen per casualitat:

Cadascuna d'aquestes files és una font potencial de fallada. Una aplicació que fa servir una funció de Node afegida a la versió 21 es trencarà al servidor amb Node 20. Una consulta SQL que aprofita una novetat de PostgreSQL 16 fallarà contra PostgreSQL 14. Un test que dona per fet la zona horària local passarà a Madrid i fallarà en UTC.

Hi ha dues patologies clàssiques al darrere de tot això i convé posar-los nom perquè les sentiràs constantment.

Deriva d'entorns (environment drift). Els entorns comencen sent iguals i se separen amb el temps. Algú instal·la un paquet a mà al servidor per sortir d'un destret i no ho documenta. Una altra persona actualitza el seu Node local perquè li venia de gust provar una cosa. Sis mesos després, ningú sap reconstruir el servidor des de zero, i l'única documentació fiable és el servidor mateix. Es converteix en el que s'anomena un snowflake server: un servidor floc de neu, únic i irrepetible, que fa por tocar.

Conflicte de dependències. La teva màquina és una de sola i només pot tenir una versió de cada cosa instal·lada globalment. Si el projecte A necessita Python 3.9 i el projecte B necessita Python 3.12, o si un projecte necessita PostgreSQL 14 i un altre PostgreSQL 16, tens un problema. Les solucions tradicionals (gestors de versions com nvm o pyenv, entorns virtuals) ajuden amb el llenguatge, però no resolen res del que hi ha per sota: llibreries del sistema, bases de dades, servidors web, eines de línia de comandes.

I hi ha un tercer cost, menys visible però enorme: l'onboarding. Quan entra algú nou a l'equip, es passa un o dos dies seguint un document desactualitzat per deixar la seva màquina a punt. Instal·la una base de dades, la configura, hi carrega dades de prova, instal·la una memòria cau, ajusta ports, descobreix que li falta una llibreria del sistema... i tot i així alguna cosa no funciona. Aquest temps, multiplicat per cada persona que entra i per cada vegada que algú reinstal·la el seu equip, són diners.

La contenidorització parteix d'una idea senzilla: si el problema és l'entorn, empaqueta'l juntament amb l'aplicació.

Un contenidor és un procés (o un grup de processos) que s'executa al teu sistema operatiu però aïllat de la resta, i que veu un sistema de fitxers propi que conté exactament el que l'aplicació necessita: el seu codi, el seu intèrpret o runtime, les seves llibreries, els seus fitxers de configuració. Des de dins del contenidor, l'aplicació es pensa que està sola en una màquina neta. Des de fora, és simplement un procés més del sistema.

La clau és que aquest aïllament no s'aconsegueix emulant maquinari ni arrencant un altre sistema operatiu, sinó fent servir funcionalitats que el mateix nucli de Linux ja ofereix per separar processos entre si i limitar-los els recursos. Per això un contenidor arrenca en mil·lisegons i consumeix poquíssim: no hi ha res per "encendre", només un procés que es llança amb una vista restringida del sistema.

En aquest curs tractarem aquest mecanisme amb detall molt més endavant, a la lliçó 05-07 (El Runtime per Dins: Namespaces, Cgroups i Capes). De moment en tens prou amb la intuïció: aïllament a nivell de procés, no de màquina.

Aquí convé ser precís, perquè s'utilitzen com a sinònims coses que no ho són:

• Contenidor és el concepte: un procés aïllat amb el seu propi sistema de fitxers.
• Docker és la plataforma més popular per crear, distribuir i executar contenidors. Inclou un motor que els executa (dockerd), una eina de línia de comandes (docker), un format per descriure com construir l'empaquetat (el Dockerfile) i un servei públic on compartir aquests empaquetats (Docker Hub).
• Docker, Inc. és l'empresa que el desenvolupa.

Docker no va inventar els contenidors —Linux feia anys que tenia les peces necessàries— però sí que va fer dues coses decisives el 2013: els va fer fàcils d'utilitzar (una comanda en lloc d'una configuració esotèrica) i, sobretot, va crear un format estàndard per empaquetar i compartir aplicacions contenidoritzades. Aquest format avui està estandarditzat sota l'OCI (Open Container Initiative), la qual cosa significa que una imatge creada amb Docker pot executar-se en altres eines compatibles.

En una frase que pots memoritzar:

Docker és una plataforma que empaqueta una aplicació juntament amb tot el seu entorn en una unitat portable i estàndard, i l'executa de manera aïllada i reproduïble en qualsevol màquina amb Docker instal·lat.

Si ja has fet servir VirtualBox, VMware o màquines al núvol, aquesta comparació et col·locarà el concepte al seu lloc. Una màquina virtual també aïlla, també empaqueta un entorn complet... però ho fa a un nivell molt més baix i molt més car.

Una màquina virtual emula maquinari. Sobre aquest maquinari fals hi instal·les un sistema operatiu convidat complet, amb el seu propi nucli, els seus serveis d'arrencada, els seus processos de sistema. Després hi instal·les la teva aplicació. El resultat són gigabytes de disc i centenars de megabytes de RAM abans que el teu codi hagi executat ni una sola línia.

Un contenidor comparteix el nucli del sistema amfitrió. No hi ha sistema operatiu convidat: només hi ha els fitxers d'espai d'usuari que l'aplicació necessita.

Fixa't en la diferència estructural del diagrama: a la columna de màquines virtuals hi ha un bloc "SO convidat amb nucli complet" per cada aplicació; a la de contenidors aquest bloc desapareix i tots comparteixen el nucli de l'amfitrió. Aquí hi ha l'estalvi.

Dos matisos importants que no has d'oblidar:

1. No són excloents. A la pràctica, moltíssims contenidors s'executen dins de màquines virtuals al núvol. Un proveïdor et dona una VM i tu hi fiques vint contenidors a dins.
2. L'aïllament d'un contenidor és bo, però no és el d'una VM. En compartir nucli, una vulnerabilitat del nucli afecta tots els contenidors de la màquina. Per això existeixen bones pràctiques de seguretat específiques, que veuràs a la lliçó 05-03.

Traduïm tot l'anterior a avantatges concrets.

• Portabilitat. La mateixa unitat empaquetada s'executa igual al teu portàtil, al CI i en producció. Això és el que mata el "a la meva màquina funciona".
• Reproduïbilitat. L'empaquetat es descriu en un fitxer de text versionat al costat del codi. Reconstruir l'entorn deixa de ser un ritual i passa a ser una comanda.
• Arrencada en segons. Aixecar una base de dades de proves o cinc rèpliques d'un servei deixa de ser una operació pesada.
• Densitat. On hi cabien 10 màquines virtuals hi caben centenars de contenidors, perquè no pagues el cost d'un sistema operatiu per aplicació.
• Aïllament. Dos projectes amb versions incompatibles de tot conviuen sense tocar-se. I el teu sistema operatiu es manté net: no instal·les bases de dades ni runtimes globalment.
• Onboarding ràpid. Un membre nou de l'equip clona el repositori, executa una comanda i té tota la plataforma funcionant.
• Rebutjabilitat. Si un contenidor s'espatlla, l'esborres i en crees un altre. Deixa d'haver-hi servidors "delicats" que ningú s'atreveix a reiniciar.

Aquests són els escenaris on Docker s'ha convertit en l'estàndard de facto:

Si d'aquesta lliçó només et quedes amb una cosa, que sigui aquesta. Tot Docker gira al voltant de tres objectes i de la relació entre ells.

La imatge és la plantilla: un paquet immutable i de només lectura que conté el sistema de fitxers de l'aplicació (el seu codi, el seu runtime, les seves llibreries) i unes metadades que indiquen com arrencar-la. Una imatge no s'executa: es fa servir per crear contenidors.

El contenidor és la instància en execució d'una imatge. És la imatge, més una capa d'escriptura pròpia, més un procés viu. D'una mateixa imatge pots crear un contenidor o mil, i cadascun tindrà la seva pròpia vida, les seves pròpies dades temporals i el seu propi estat.

El registre és el magatzem on viuen les imatges i des del qual es distribueixen. Docker Hub és el registre públic per defecte; les empreses solen tenir a més registres privats.

L'analogia que funciona millor si véns de la programació orientada a objectes:

I el flux bàsic que repetiràs mil vegades durant el curs:

Llegeix-ho així: construeixes una imatge a partir del teu codi, la publiques en un registre, qualsevol màquina la descarrega i a partir d'ella executa tants contenidors idèntics com vulgui. Aquesta cadena és, literalment, la raó de ser de Docker.

A la resta del mòdul aprofundiràs en cada peça: l'arquitectura que fa possible aquest flux a la lliçó 01-03, les comandes per manejar-lo a la 01-04, l'anatomia de les imatges a la 01-05 i el teu primer contenidor real a la 01-06.

Perquè res d'això no es quedi en teoria, el curs sencer se sosté en un projecte únic que anirà creixent mòdul a mòdul: Aurora Libros S.L., una llibreria en línia fictícia.

La seva plataforma tindrà quatre peces:

• aurora-api: l'API REST del catàleg, en Node.js 22 amb Express.
• aurora-db: una base de dades PostgreSQL 16 amb el catàleg de llibres.
• aurora-cache: un Redis 7 que fa de memòria cau de les consultes més freqüents.
• aurora-web: un Nginx que serveix el web estàtic i fa de proxy invers cap a l'API.

Avui, al punt de partida del curs, res d'això no està contenidoritzat: l'equip d'Aurora Libros pateix exactament els problemes descrits als apartats 1 i 2. A l'última lliçó d'aquest mòdul (01-07) coneixeràs el seu codi, intentaràs arrencar-lo sense Docker i veuràs amb els teus propis ulls per què necessiten aquest curs. A partir d'aquí, cada mòdul hi afegirà una peça fins a arribar a una plataforma completa, segura i desplegada.

• Creure que un contenidor és "una VM lleugera". És l'analogia més estesa i també la que genera més confusió després. Un contenidor no té nucli propi, no arrenca un sistema operatiu i, en general, executa un sol procés principal. Quan aquest procés acaba, el contenidor acaba. Pensa en "procés empaquetat", no en "màquina petita".
• Confondre imatge i contenidor. És l'error número u dels principiants i arrossega malentesos durant setmanes. Repeteix l'analogia: imatge = classe, contenidor = objecte. Esborrar un contenidor no esborra la seva imatge; esborrar una imatge no afecta els contenidors ja creats a partir d'ella.
• Pensar que Docker garanteix que la teva aplicació funcioni a qualsevol lloc. Garanteix que l'entorn sigui el mateix. No et protegeix de dependre d'una arquitectura de CPU concreta (una imatge construïda només per a amd64 no arrencarà tal qual en un Mac amb Apple Silicon), ni de recursos externs que no controles.
• Suposar que "contenidor" implica automàticament "segur". L'aïllament per defecte és raonable, però és configurable i es pot afeblir sense voler. La seguretat és un tema propi (lliçó 05-03).
• Consell: aprèn el vocabulari abans que les comandes. Les comandes es consulten; els conceptes, no. Si tens clars imatge, contenidor i registre, el 80 % dels missatges d'error de Docker es tornen llegibles.
• Consell: pensa en "rebutjable". La mentalitat correcta és que qualsevol contenidor pot morir en qualsevol moment i ser substituït per un altre d'idèntic. Aquesta idea guia totes les bones pràctiques que veuràs més endavant.

Un equip té aquesta situació:

• L'aplicació funciona al portàtil de la Marta (Node 22, PostgreSQL 16).
• Falla al servidor de CI amb un error de sintaxi SQL.
• El servidor de CI té PostgreSQL 14.
• Ningú recorda qui va instal·lar PostgreSQL al CI ni quan.

Respon: (a) quin nom rep el fenomen de fons?, (b) per què instal·lar PostgreSQL 16 al CI no és una solució satisfactòria?, i (c) com canvia el plantejament la contenidorització?

Per a cada situació, decideix si la solució natural és un contenidor, una màquina virtual, o totes dues combinades, i justifica-ho en una o dues frases:

1. Necessites executar una aplicació de Windows en un servidor Linux.
2. Vols que cadascun dels 12 desenvolupadors de l'equip tingui la mateixa pila de desenvolupament local.
3. Llogues capacitat de còmput a clients que executaran codi arbitrari i no te'n refies.
4. Vols executar 300 instàncies d'un microservei petit en un únic servidor potent.
5. Necessites provar la teva aplicació contra PostgreSQL 14, 15 i 16 a la mateixa màquina i alhora.

Sense fer servir la paraula "Docker", explica a un company no tècnic la relació entre imatge, contenidor i registre amb una analogia pròpia (no la de classe/objecte). Després, respon: si esborres un contenidor, desapareix la imatge? I si esborres la imatge del registre, s'aturen els contenidors que ja s'estaven executant?

Solució a l'exercici 1

(a) El fenomen és la deriva d'entorns (environment drift): els entorns van començar assemblant-se i es van separar amb el temps, agreujat pel fet que el servidor de CI és un snowflake server la configuració del qual ningú sap reproduir.

(b) Instal·lar PostgreSQL 16 al CI arregla aquesta fallada concreta però no el problema de fons. Segueix havent-hi un servidor configurat a mà, segueix sense haver-hi una descripció versionada de l'entorn, i demà el conflicte serà amb una altra peça (la versió de Node, una llibreria del sistema, la zona horària). A més, si un altre projecte del mateix CI necessita PostgreSQL 14, tornes a tenir un conflicte de dependències irresoluble amb una instal·lació global.

(c) Amb contenidors, la versió de PostgreSQL deixa de ser una propietat del servidor i passa a ser una propietat del projecte, declarada en un fitxer versionat al costat del codi. La Marta i el CI executen literalment el mateix empaquetat de PostgreSQL 16, i un altre projecte del mateix CI pot fer servir la 14 sense interferir. L'entorn es torna reproduïble i rebutjable en lloc d'instal·lat i permanent.

Solució a l'exercici 2

1. Màquina virtual. Un contenidor comparteix el nucli de l'amfitrió; un nucli Linux no pot executar binaris de Windows de manera nativa. Necessites virtualització real.
2. Contenidors. És el cas d'ús canònic: una definició versionada de l'entorn que els 12 executen idèntica, sense instal·lar res als seus sistemes.
3. Màquines virtuals, o contenidors dins de VM separades per client. Amb codi no fiable de tercers convé la frontera forta de la virtualització, perquè el nucli compartit dels contenidors és una superfície d'atac comuna.
4. Contenidors. La densitat és justament el seu gran avantatge: 300 VM en un servidor serien inviables per la sobrecàrrega de 300 sistemes operatius complets.
5. Contenidors. Tres contenidors amb tres versions diferents conviuen sense problema, cadascun al seu port. Amb instal·lacions natives seria un exercici de paciència, i amb tres VM pagaries una sobrecàrrega innecessària.

Solució a l'exercici 3

Una analogia vàlida és la de la rebosteria: la imatge és la recepta escrita juntament amb tots els ingredients ja mesurats i envasats en una caixa precintada; el contenidor és el pastís que enfornes a partir d'aquesta caixa (pots enfornar molts pastissos idèntics amb caixes iguals, i després cada pastís viu la seva pròpia vida); el registre és la botiga on es venen aquestes caixes i d'on qualsevol pot descarregar-se la que necessiti. Altres analogies igualment correctes: motlle/peça fosa/catàleg de motlles, o plànol/edifici/arxiu de plànols.

Respostes a les preguntes:

• Si esborres un contenidor, la imatge no desapareix. La imatge és independent i pot continuar generant contenidors nous. (Sí que es perden les dades que aquell contenidor hagués escrit a la seva capa pròpia; és un punt important que es tracta a la lliçó 01-05 i es resol a la 03-06.)
• Si esborres la imatge del registre, els contenidors en execució continuen funcionant. El registre només serveix per distribuir: un cop la imatge està descarregada en una màquina i hi ha contenidors creats a partir d'ella, el registre ja no hi intervé. El problema apareixerà el dia que una altra màquina intenti descarregar-la, o que necessitis recrear el contenidor des de zero.

Docker existeix perquè el programari no s'executa en el buit: depèn d'un entorn, i els entorns deriven. La contenidorització ataca el problema empaquetant l'aplicació juntament amb el seu entorn en una unitat portable, que s'executa aïllada compartint el nucli de l'amfitrió i, per tant, sense la sobrecàrrega d'una màquina virtual. D'aquí en surten els seus grans avantatges: portabilitat, reproduïbilitat, arrencada immediata, densitat i aïllament.

T'endús tres paraules que vertebraran tot el curs: la imatge (la plantilla immutable, la "classe"), el contenidor (la instància en execució, l'"objecte") i el registre (el magatzem des del qual es distribueixen les imatges). I t'endús un projecte, Aurora Libros, que aniràs contenidoritzant peça a peça.

Ja saps què és Docker i per què importa. A la lliçó següent, Instal·lant Docker, passaràs a la pràctica: veuràs la diferència entre Docker Engine i Docker Desktop, instal·laràs Docker pas a pas al teu sistema operatiu i comprovaràs que tot funciona executant el teu primeríssim contenidor.