Si treballes a macOS o a Windows, portes tot el curs executant contenidors dins d'una màquina virtual Linux sense veure-la. Docker Desktop és aquella VM, més una interfície gràfica i un grapat d'extres. Aquesta lliçó obre la caixa: què hi ha a dins, per què això explica que els bind mounts vagin lents, què aporta de debò, quant costa —inclosa la lletra petita de la llicència— i quines alternatives tens a cada sistema.

1. Què és exactament Docker Desktop
2. L'arquitectura per dins
3. Per què els bind mounts van lents
4. La VM i els seus recursos
5. El disc virtual que creix i no s'encongeix
6. Windows: WSL 2 davant d'Hyper-V
7. macOS: Apple Silicon, Rosetta i VirtioFS
8. El que aporta la interfície
9. Docker Scout, el Kubernetes d'un clic i les extensions
10. docker init, docker debug i els contenidors de desenvolupament
11. Llicència i cost
12. Alternatives a l'escriptori
13. Recomanació per perfil

Docker Desktop no és Docker. És un paquet que conté, entre altres coses:

El punt clau és a la primera fila: els contenidors són una funció del kernel de Linux —namespaces i cgroups, tal com vas veure a 05-07—. macOS i Windows no tenen aquell kernel, així que en cal un. A Linux, Docker Desktop és opcional precisament perquè el kernel ja hi és: allà docker parla directament amb dockerd sense cap VM pel mig.

Tot el que creuï la frontera entre l'amfitrió i la VM té un cost. I hi ha dues coses que la creuen constantment: els fitxers dels bind mounts i els paquets de xarxa dels ports publicats.

Quan muntes ./src:/app/src a Linux, no passa res d'especial: el contenidor veu el mateix sistema de fitxers de l'host a través del namespace de muntatge. A macOS o Windows, cada open(), cada stat() i cada read() viatja del contenidor a la VM, de la VM a l'amfitrió i tornada.

Aquí tens el motiu d'una recomanació que veuràs a tot arreu i que ara entens: node_modules mai en un bind mount. Instal·lar dependències d'aurora-api amb la carpeta muntada des de macOS pot trigar minuts; amb un volum amb nom, segons.

Mesura-ho tu mateix, que és més convincent que qualsevol taula:

La VM té una mida fixa que li has assignat, i tot el que executen els teus contenidors competeix a dins. Quan un docker compose up d'Aurora Libros va lent sense motiu aparent, aquest és el primer lloc on mirar.

Un símptoma freqüent i confús: PostgreSQL mor amb codi 137 en importar els nou títols del catàleg. No és una fallada de la base de dades, és l'OOM killer del kernel de la VM. Si la VM té 2 GB i els contenidors en demanen 3, algú mor; puja-la i el problema desapareix.

El disc de la VM és un fitxer dispers al teu amfitrió —Docker.raw a macOS, un .vhdx a Windows— que creix quan escrius i no minva quan esborres. Pots tenir 8 GB d'imatges segons Docker i 90 GB ocupats al teu portàtil.

Recuperar espai són dos passos, i l'ordre importa:

L'advertència de la tercera comanda és seriosa: --volumes s'emporta per davant aurora-dades si en aquell moment no hi ha cap contenidor fent-lo servir. Els nou títols del catàleg desapareixen sense preguntar. Fes servir docker volume ls abans i, en general, prefereix un prune selectiu.

La integració amb distribucions és el que fa còmode el dia a dia: a Settings → Resources → WSL Integration actives el teu Ubuntu, i des de la seva terminal la comanda docker funciona sense instal·lar-hi res.

I la regla que més rendiment et donarà a Windows: desa el codi al sistema de fitxers de Linux, no al de Windows.

La diferència no és de matís: un npm install d'aurora-api pot passar de tres minuts a vint segons només per moure la carpeta. Si necessites editar des de Windows, VS Code amb l'extensió WSL obre el projecte remot sense treure els fitxers de Linux.

En un Mac amb Apple Silicon, la VM és arm64. Les teves imatges es construeixen i s'executen en arm64 de manera nativa, i tot va ràpid... fins que apareix una imatge que només existeix per a amd64.

Rosetta s'activa a Settings → General → Use Rosetta for x86/amd64 emulation i millora molt l'experiència, però no és màgia: hi ha binaris que fallen, extensions de CPU que no hi són i càrregues que continuen sent lentes.

Per això la feina multiarquitectura del mòdul 5 no era acadèmica. La teva ghcr.io/auroralibros/aurora-api:2.0.0 està publicada per a linux/amd64 i linux/arm64, així que el Mac descarrega la variant arm64 i el servidor de producció l'amd64, sense emulació a cap dels dos costats. És la solució correcta al problema.

Pel que fa als fitxers, macOS fa servir VirtioFS amb el framework de virtualització d'Apple: és notablement més ràpid que l'antic gRPC-FUSE, tot i que continua sense arribar al natiu. Verifica que està actiu a Settings → General → Choose file sharing implementation.

La GUI no fa res que la CLI no pugui fer, però hi ha tasques on veure és més ràpid que teclejar.

El panell de Builds és el més infravalorat: et diu quin pas del Dockerfile d'aurora-api està costant els segons i si la memòria cau va encertar o no, que és exactament el que vas optimitzar a cegues a 05-04.

Docker Scout ve integrat i analitza les imatges locals:

És còmode per a una revisió ràpida a l'escriptori, però no substitueix l'escaneig del pipeline: qui decideix si una imatge es publica és el Trivy del teu GitHub Actions (06-02), que corre sense intervenció humana i fa fallar el build. Scout és la comprovació primerenca; el pipeline és la porta.

El Kubernetes d'un clic activa un clúster d'un sol node dins de la mateixa VM.

Davant de kind, minikube o k3d (06-04), el seu avantatge és que ja hi és; el seu desavantatge és que consumeix memòria de la mateixa VM i no pots tenir diversos clústers ni triar versió amb comoditat. Per experimentar amb diverses versions o simular diversos nodes, kind continua sent millor.

Les extensions afegeixen eines de tercers al panell (visors de logs, clients de bases de dades, gestors de discos). Són útils amb una precaució: són codi de tercers amb accés al teu daemon. Instal·la només les que necessitis i d'origen conegut.

docker init genera una bastida raonable: multietapa, usuari sense privilegis i .dockerignore. És un excel·lent punt de partida i un mal punt d'arribada: no fixa la base per digest, no afegeix les tres sondes de 06-01 ni l'aturada ordenada. Fes-lo servir per arrencar i aplica-hi al damunt el que saps.

docker debug resol el problema clàssic de les imatges mínimes: quan aurora-api:2.0.0 no té ni sh ni curl, docker exec no et serveix de res.

No instal·la res al contenidor ni canvia la imatge: munta un conjunt d'utilitats en una capa a part. És l'alternativa còmoda al netshoot que veuràs a 07-04, i una funció de la subscripció de pagament.

Finalment, els contenidors de desenvolupament de VS Code: un .devcontainer/devcontainer.json descriu l'entorn complet —imatge, extensions, ports, comandes— i l'editor s'executa dins del contenidor.

Amb això, algú nou a Aurora Libros clona el repositori, obre VS Code i té Node 22, PostgreSQL 16 i Redis 7 funcionant. És la resposta definitiva als quinze passos d'onboarding manual amb què va començar el curs a 01-07.

Docker Desktop és programari propietari amb llicència comercial, encara que el Docker Engine que porta dins sigui de codi obert. En els termes vigents el 2026:

El llindar ha canviat més d'un cop des del 2021, i la lletra concreta —què compta com a empleat, si inclou els contractistes, què passa en un grup d'empreses— determina si la teva organització ha de pagar.

Advertència pràctica: no instal·lis Docker Desktop en un equip corporatiu donant per fet que és gratis. Consulta els termes vigents al web oficial en el moment d'instal·lar-lo i valida-ho amb el departament legal o de compres de la teva empresa. Hi ha hagut auditories de llicències amb factures retroactives, i la responsabilitat no recau en qui el va instal·lar, sinó en la companyia. Si la teva empresa decideix no pagar, la bona notícia és que hi ha alternatives plenament funcionals i cap d'elles no afecta les teves imatges, que són OCI estàndard.

Fixa't en el detall: totes aquestes alternatives s'integren mitjançant contextos de Docker, el mecanisme de la lliçó anterior. I en totes elles les teves imatges i el teu compose.yaml funcionen sense canvis, perquè res del que has construït durant el curs no depèn de Docker Desktop.

L'última fila no admet matisos: en un servidor o en un runner d'integració contínua s'instal·la Docker Engine, mai Docker Desktop.

• Treballar des de /mnt/c/... a WSL 2. És la causa número u de lentitud a Windows. Mou el projecte a ~/ dins de la distribució.
• Fer bind mount de node_modules. Milers de fitxers petits creuant la frontera. Fes servir un volum amb nom per a aquella ruta.
• Estranyar-se del codi 137. És l'OOM killer de la VM. Puja la memòria a Resources o posa límits per servei.
• Creure que esborrar imatges allibera espai al portàtil. El disc virtual no s'encongeix sol: cal compactar-lo o purgar-lo a part.
• docker system prune -a --volumes sense mirar. S'emporta aurora-dades i amb ell els nou títols. Comprova docker volume ls abans.
• Instal·lar-lo a l'empresa sense comprovar la llicència. Els termes canvien i les auditories existeixen. Verifica-ho i consulta-ho amb legal o compres.
• Fer servir el Kubernetes de Docker Desktop com si fos producció. És un node únic: no prova disponibilitat, ni reprogramació, ni el CNI real.
• Consell: activa Rosetta a Apple Silicon, però resol el problema d'arrel publicant imatges multiarquitectura com vas fer a 05-05.
• Consell: revisa el panell Builds quan un docker compose build es faci lent. Et dirà el pas culpable en segons.
• Consell: desa un .devcontainer/devcontainer.json al repositori. Converteix l'onboarding en «clona i obre».

Exercici 1 — Mesura la frontera. Dissenya i executa una mesura que compari el temps de crear 3.000 fitxers petits en tres ubicacions: un bind mount des de la teva carpeta de l'amfitrió, un volum amb nom i el sistema de fitxers intern del contenidor. Anota els tres temps, calcula'n la proporció i explica el resultat amb l'arquitectura de §2. Si ets a Linux, explica per què els tres números s'assemblen.

Exercici 2 — Auditoria d'espai i recuperació. Esbrina quant ocupa Docker segons la seva pròpia comptabilitat i quant ocupa realment el disc virtual al teu amfitrió. Explica la diferència. Després allibera espai de manera segura, deixant intacte el volum aurora-dades, i comprova el resultat en totes dues mesures. Indica quina comanda hauria destruït les dades i per què.

Exercici 3 — Decisió d'eina d'escriptori. Aurora Libros creix fins a 14 desenvolupadors: 6 a macOS amb Apple Silicon, 5 a Windows i 3 a Linux. L'empresa supera el llindar de la llicència gratuïta. Compres pregunta si cal pagar 14 subscripcions. Prepara una recomanació amb: què es necessita realment a cada sistema, quina alternativa proposes per a cada grup, què es perd amb cada alternativa, i quines preguntes concretes cal fer a legal abans de decidir.

Solució 1.

Resultats típics en un Mac amb Apple Silicon i VirtioFS: bind mount al voltant de 8-12 s, volum amb nom 0,6-1,2 s, capa del contenidor 0,5-1 s. La proporció del bind mount ronda 10×. L'explicació és la de §2: cada open(), write() i close() dels 3.000 fitxers travessa la capa de compartició entre la VM i l'amfitrió, i són 9.000 viatges d'anada i tornada; el volum amb nom viu dins del disc de la VM i no creua res, igual que la capa d'escriptura d'overlay2 (05-07).

A Linux els tres números surten gairebé idèntics —dècimes de segon— perquè no hi ha frontera a creuar: el bind mount és el mateix sistema de fitxers vist des d'un altre namespace de muntatge. Aquest és exactament el motiu pel qual un company amb Linux no reprodueix el teu problema de lentitud, i pel qual la solució no és «tenir millor portàtil» sinó moure els fitxers al costat correcte de la frontera.

Solució 2.

La diferència és que el disc virtual és un fitxer dispers que creix en escriure i mai no es redueix en esborrar: quan elimines una imatge, els blocs queden lliures dins de la VM però el fitxer continua reservant aquella mida al teu portàtil.

La comanda destructiva és docker system prune -a --volumes: l'opció --volumes inclou els volums sense cap contenidor associat, i si en aquell moment aurora-db està aturat, aurora-dades entra al garbell i els nou títols del catàleg desapareixen sense confirmació per volum. Com a xarxa de seguretat, fes docker run --rm -v aurora-dades:/v -v "$PWD":/b alpine tar czf /b/aurora-dades.tgz -C /v . abans de qualsevol neteja agressiva, exactament el patró de còpia de 05-02.

Solució 3. Recomanació per grups:

Anàlisi: de 14 llicències, 3 sobren immediatament perquè a Linux Docker Desktop no aporta res. A macOS, Colima cobreix el cas complet amb la CLI de sempre i els mateixos contextos; s'hi perden funcions d'escriptori que l'equip probablement fa servir poc, i convé preguntar-ho abans de decidir per ells. Windows és on la integració amb WSL 2 té més valor real, així que allà pot compensar pagar unes poques llicències en lloc de forçar una alternativa. Una sortida intermèdia raonable: 5 llicències per a Windows i alternatives lliures a macOS i Linux, revisable d'aquí a sis mesos.

Preguntes per a legal i compres, abans de decidir res: què diuen exactament els termes vigents sobre el llindar, i comptem empleats totals o només desenvolupadors?; els contractistes externs i les filials compten dins del grup?; ja existeix un acord marc amb Docker o un contracte de subscripció d'un altre producte que cobreixi això? Afegeix-hi una quarta pregunta interna, que sovint és la que resol el debat: quines funcions concretes de Docker Desktop fa servir de debò l'equip cada setmana? Si la resposta és «arrencar Compose i veure logs», la decisió es pren sola.

Ja saps què és aquella VM que feies servir sense veure-la. Docker Desktop no és Docker: és una màquina virtual Linux amb dockerd a dins, més una GUI, plugins i extres, i existeix perquè els contenidors són una funció del kernel de Linux que macOS i Windows no tenen. A Linux és opcional justament per això.

D'aquella arquitectura en surt tota la resta. Entens per què els bind mounts van entre 2 i 30 vegades més lents segons el sistema i el protocol, per què node_modules ha de viure en un volum amb nom, i per què a WSL 2 moure el projecte de /mnt/c/... a ~/ pot convertir tres minuts en vint segons. Saps dimensionar la VM, diagnosticar un codi 137 com el que és —l'OOM killer, no una fallada de PostgreSQL— i recuperar espai als dos nivells, amb l'advertència que --volumes s'emporta aurora-dades sense preguntar.

Coneixes el terreny de cada sistema: WSL 2 davant d'Hyper-V i la integració amb distribucions a Windows; Apple Silicon, Rosetta i VirtioFS a macOS, amb la constatació que la feina multiarquitectura de 05-05 és la solució d'arrel al problema de l'emulació. I saps què aporta l'eina de debò: el panell de Builds amb la durada per pas, Scout com a comprovació primerenca que no substitueix l'escaneig del pipeline, el Kubernetes d'un clic amb els seus límits honestos, docker init com a bon punt de partida i mal punt d'arribada, docker debug per a les imatges sense shell, i els contenidors de desenvolupament com a resposta definitiva als quinze passos d'onboarding de 01-07.

I t'endús el que no és tècnic: és programari propietari amb llindars de llicència que han canviat diverses vegades, així que es verifica al web oficial i es valida amb legal o compres abans d'instal·lar-lo a l'empresa. Si la resposta és que no es paga, tens la taula d'alternatives —Engine natiu, Rancher, Podman Desktop, Colima, OrbStack, lima—, totes integrades per contextos i totes executant les teves imatges sense canviar-hi una línia, perquè res del que has construït no depèn de Docker Desktop.

A la lliçó següent sortim de l'escriptori per equipar el flux de treball: les eines i plugins de tercers que envolten Docker en un projecte real. Com funciona l'extensibilitat de la CLI —construiràs el teu propi docker aurora—, què val la pena en interfícies, inspecció, seguretat, registres d'imatges propis, desenvolupament i construcció alternativa, i amb quins criteris es decideix adoptar una eina o deixar-la fora.