Durant sis mòduls has donat per fet que tenies una màquina amb Docker instal·lat. Al mòdul 6 aquella màquina es va multiplicar en un clúster i la pregunta va deixar de ser còmoda: d'on surten els hosts, qui hi instal·la Docker, qui els actualitza i qui respon quan un deixa d'arrencar? Aquesta lliçó comença per l'eina que ho va intentar primer —Docker Machine, avui arxivada— i acaba en com es fa el 2026.

1. El problema real de l'aprovisionament
2. Què va ser Docker Machine i el seu model de drivers
3. Les comandes característiques
4. Per què està arxivat i què fer si te'l trobes
5. El que sí que va sobreviure: els contextos de Docker
6. Un context aurora-prod sobre SSH
7. Desplegar contra un host remot sense canviar de terminal
8. SSH davant d'exposar el daemon per TCP
9. El mapa d'alternatives actuals
10. Instal·lació directa: l'script idempotent
11. cloud-init: que la màquina neixi amb Docker
12. Terraform / OpenTofu: infraestructura declarativa
13. Ansible: configurar i mantenir la flota
14. Packer i els serveis gestionats
15. L'host com a superfície d'atac
16. Hosts propis o gestionat? Criteris de decisió

Entre «tinc compte en un proveïdor de núvol» i «docker compose up -d aixeca Aurora Libros en producció» hi ha una llista que algú ha d'executar: crear la VM (mida, regió, disc, xarxa, grup de seguretat), configurar l'accés SSH i un usuari sense privilegis, instal·lar Engine i el plugin de Compose, ajustar el daemon (data-root, logging, live-restore), endurir l'host (tallafocs, pedaços automàtics), desplegar l'aplicació, repetir-ho idèntic al segon host i mantenir-ho durant tres anys. Els dos últims punts són els que separen una eina d'un tutorial: Docker Machine atacava els tres primers i la resta quedava fora.

Docker Machine (docker-machine) va ser un binari oficial, contemporani de Docker Toolbox (2015-2018), amb un propòsit concret: crear una VM amb Docker Engine ja instal·lat —en local o al núvol— i apuntar el teu client local cap a aquell daemon remot.

Aquella segona meitat era la interessant. Recorda 01-03: client i daemon són processos separats que parlen per una API. Si el client arriba a un daemon remot, docker ps llista els contenidors d'un servidor de Frankfurt des del teu portàtil. Docker Machine automatitzava el paperam: crear la VM, instal·lar Engine, generar certificats TLS mutus i exportar les variables que redirigien el client.

La peça extensible era el driver: un adaptador per plataforma. La comanda era la mateixa; només canviaven --driver i les seves opcions.

El driver generic no creava res: es connectava per SSH a una màquina existent i hi instal·lava Docker. Era un instal·lador remot rudimentari, exactament el que avui cobreix millor un gestor de configuració.

Les veuràs en documentació antiga i en scripts heretats. Reconeix-les encara que no les executis:

L'eval era la màgia i també el problema. Exportava DOCKER_TLS_VERIFY=1, DOCKER_HOST=tcp://203.0.113.42:2376 i DOCKER_CERT_PATH apuntant als certificats generats.

A partir d'aquí, cada comanda docker d'aquella terminal anava al servidor remot, i obrir una altra pestanya et retornava al daemon local. Més d'un incident cèlebre va néixer d'un docker compose down a la terminal equivocada.

Docker va arxivar el repositori el 2021. No hi ha pedaços de seguretat, els drivers fan servir APIs que han canviat i la instal·lació descarrega versions d'Engine que ja no existeixen.

Regla pràctica: si un tutorial el fa servir, té més de cinc anys i cal verificar tota la resta del que diu. Si apareix en un script heretat de la teva empresa, no l'executis: identifica quines màquines gestiona, trasllada aquesta informació a contextos o a Terraform i planifica'n la retirada amb qui mantingui la infraestructura.

La idea que valia la pena —un client, diversos daemons— és avui una funció de primera classe: els contextos. Un context és una destinació amb nom. A diferència de l'eval, el canvi és global i persistent, no per terminal.

La distinció important: docker-machine rm destruïa una màquina; docker context rm només oblida una adreça. Els contextos no creen, no instal·len i no mantenen res: només apunten. Per això continuen sent útils i per això no substitueixen l'aprovisionament.

Aurora Libros té un host a libros.example.com amb un usuari deploy del grup docker. Primer, que SSH funcioni amb clau i sense contrasenya, i una entrada a ~/.ssh/config que faci llegible la resta:

El context és una línia, i la comprovació no exigeix activar-lo:

Quatre contenidors, nou dies en marxa, sense obrir ni una sola sessió SSH manual.

Compose respecta els contextos, així que el desplegament complet és això:

Tres detalls canvien el resultat:

De la segona fila en surt una regla d'or: en producció no es construeix, es desplega una imatge ja publicada. És el que fa el teu compose.prod.yaml, que referencia ghcr.io/auroralibros/aurora-api:2.0.0 per digest en lloc d'un build:. El pipeline de 06-02 construeix, signa i publica; l'host només fa pull.

Patró defensiu: no facis servir mai docker context use per a producció. Deixa default actiu i escriu --context aurora-prod de manera explícita, o com a molt un alias dprod='docker --context aurora-prod'. És més llarg de teclejar, i aquest és exactament l'avantatge.

Docker Machine feia servir tcp://IP:2376 amb TLS mutu. Avui ho pots fer, però gairebé mai no hauries de fer-ho.

La fila del risc és la que cal interioritzar. Ja ho vas veure a 05-03: qui parla amb el daemon pot llançar docker run -v /:/host --privileged i és root a la màquina. Un 2375 obert a Internet és una màquina regalada; hi ha bots escanejant aquell port de manera contínua i el patró habitual és minar criptomonedes al teu servidor durant setmanes.

Si alguna eina exigeix l'API per TCP, la resposta correcta és un túnel SSH local, no obrir el port:

No competeixen: s'apilen. Un muntatge sa del 2026 és Terraform crea + cloud-init arrenca + Ansible manté + contextos operen.

La versió honesta del driver generic. La clau és que es pugui executar deu vegades amb el mateix resultat.

Avantatge: zero dependències i ho entén qualsevol. Límits: no controla la deriva entre hosts, no sap quina versió hi ha a cadascun i creix fins a tornar-se il·legible. A partir del tercer host, Ansible. I un apunt: get.docker.com és còmode, però és un curl | sh contra Internet; en producció es fa servir el repositori APT oficial amb la seva clau GPG fixada, que és el que l'script fa per sota.

cloud-init és l'estàndard de facto en imatges de núvol: llegeix un user-data en la primera arrencada i configura la màquina abans que ningú hi iniciï sessió. És el substitut més directe de docker-machine create.

Es passa com a --user-data en crear la instància, i es valida sense gastar diners amb cloud-init schema --config-file cloud-config.yaml; ja a l'host, cloud-init status --wait espera que acabi i /var/log/cloud-init-output.log explica què va passar. La seva limitació és estructural: s'executa un sol cop. No serveix per canviar alguna cosa en cinquanta màquines ja en marxa.

Terraform descriu la infraestructura desitjada i calcula el pla per arribar-hi. OpenTofu és la seva bifurcació de codi obert sota la Linux Foundation, nascuda arran del canvi de llicència del 2023; per al que veuràs aquí són intercanviables (tofu en lloc de terraform).

terraform plan és el motiu pel qual això substitueix els scripts: et diu què passarà abans que passi. I com que viu a Git, l'aprovisionament es revisa en un pull request com qualsevol codi. El fitxer d'estat (terraform.tfstate) conté secrets en clar: va en un backend remot amb bloqueig, mai al repositori.

Terraform crea; Ansible manté. Es connecta per SSH, no necessita agent i els seus mòduls són idempotents: descrius l'estat final i només actua si cal.

El ghcr_token va xifrat amb ansible-vault encrypt_string, mai en clar. I a la segona execució veuràs changed=0: això és la idempotència funcionant de debò.

En lloc d'instal·lar Docker a cada arrencada, Packer construeix un cop una imatge de màquina (AMI, snapshot) que ja ho porta tot, i les instàncies arrenquen en segons. És el raonament de les imatges de contenidor un nivell més avall.

El cost és un pipeline més: cada pedaç obliga a reconstruir i redistribuir la imatge. Amb autoescalat, es paga sol. Però la millor manera de mantenir un host continua sent no tenir-lo:

Per a una imatge com ghcr.io/auroralibros/aurora-api:2.0.0 —sense estat, dotze factors, sondes i aturada ordenada, just el que vas preparar a 06-01— un servei tipus Cloud Run és candidat seriós: li dones imatge, port i variables. Que t'ho puguis plantejar és conseqüència directa del mòdul 6, no una casualitat.

A 05-03 vas endurir el contenidor. Tot allò és inútil si l'host fa catorze mesos que no rep pedaços.

I una advertència que no és tècnica: acorda per escrit qui manté aquestes màquines. La pregunta «qui aplica els pedaços del kernel de l'host de producció?» ha de tenir un nom per resposta abans que arribi el primer client. Si hi ha equip d'infraestructura o responsable de sistemes, la propietat de l'host, la finestra de manteniment i el procediment d'accés es pacten amb ell; si no n'hi ha, el responsable ets tu, i convé que estigui escrit perquè ningú no ho descobreixi durant un incident.

Per a Aurora Libros el 2026 la resposta raonable és mixta: base de dades gestionada —ningú no vol ser el responsable de la recuperació a un punt en el temps de PostgreSQL a les tres de la matinada— i aplicació en hosts propis o en Kubernetes gestionat segons la mida. Que és justament la decisió que analitza la lliçó següent.

• Seguir un tutorial amb docker-machine el 2026. Arxivat des del 2021; si el tutorial el fa servir, tota la resta també ha caducat.
• Exposar el 2375 «només un moment per provar». Hi ha bots escanejant aquell port de manera permanent. Un daemon obert és root regalat, i el minat comença en minuts.
• Confondre context actiu amb màquina de treball. docker context use aurora-prod i oblidar-ho és la recepta del compose down en producció. Fes servir --context explícit sempre.
• Construir imatges a l'host de producció. El context de build viatja per SSH, la memòria cau no es reaprofita i el servidor gasta CPU en una cosa que li toca al pipeline. Publica i fes pull.
• Scripts no idempotents. Si executar-lo dues vegades trenca alguna cosa, no és aprovisionament: és un accident ajornat.
• Desar terraform.tfstate a Git o secrets al user-data. Tots dos són llegibles: el primer per qualsevol amb accés al repositori, el segon des del servei de metadades. Backend remot amb bloqueig i gestor de secrets.
• Consell: un context per entorn amb descripció clara, i default sempre actiu. La fricció de teclejar --context és deliberada.
• Consell: comença per cloud-init encara que només tinguis un host; el dia que necessitis el segon, ja estarà resolt. I documenta al README qui manté cada host, amb quina finestra de pedaços i a qui s'avisa: aquella pàgina val més que qualsevol script.

Exercici 1 — Un context i una auditoria remota. Crea un context aurora-lab que apunti a un host per SSH (val una VM local o un altre portàtil). Sense activar-lo mai com a context per defecte, comprova la versió del daemon remot, llista els seus contenidors, verifica que els ports 2375 i 2376 no estan a l'escolta i mostra quant disc consumeix Docker. Escriu-ho com a auditar-host.sh, que ha de retornar codi 1 si detecta el daemon exposat i 2 si no arriba a l'host.

Exercici 2 — cloud-init per a un node d'Aurora Libros. Escriu un cloud-config.yaml que prepari un node amb: usuari deploy amb la teva clau pública i al grup docker, Docker Engine des del repositori oficial, rotació de logs a 10 MB i 3 fitxers, tallafocs que només permeti 22 i 443, SSH sense contrasenya, actualitzacions desateses i /opt/aurora a punt per al compose.yaml. Valida'n la sintaxi sense arrencar cap màquina.

Exercici 3 — Decisió raonada. Aurora Libros obre mercat a Mèxic i necessita una rèplica de la plataforma. Dades: quatre desenvolupadors sense ningú de sistemes, sense guàrdies nocturnes, unes 40 peticions per segon amb pics ×8 en campanya, còpies de la base de dades de 30 dies, i la direcció exigeix poder canviar de proveïdor «si pugen els preus». Escriu una recomanació amb l'opció triada, dues alternatives descartades amb el seu motiu i les tres preguntes que faries al responsable d'infraestructura abans d'executar res.

Solució 1.

Claus: --context explícit a cada comanda (mai use); docker context inspect --format dedueix l'host sense duplicar configuració; i els codis de sortida distingeixen «no hi arribo» (2) de «hi arribo i està mal configurat» (1), que és el que permet ficar l'script en un cron o en un pipeline.

Solució 2.

Partint del fitxer de §11, cal afegir tres blocs i una línia:

Tres detalls marquen la diferència: l'usermod -aG docker deploy va a runcmd i després d'instal·lar Engine, perquè abans el grup no existeix; ufw denega l'entrant per defecte i només obre 22 i 443, mai 2375/2376; i no hi ha ni un sol secret al fitxer, perquè el user-data és llegible des del servei de metadades per qualsevol que entri a la màquina.

Solució 3. Opció triada: aplicació en Kubernetes gestionat (o Cloud Run) + PostgreSQL gestionat a la regió de Mèxic.

Descartades: (a) hosts propis amb Compose, que aguantaria 40 req/s però obligaria a escalar a mà en el pitjor moment de l'any i deixaria el sistema operatiu sense amo; (b) Fargate o App Service, que resolen l'operació però xoquen amb l'exigència de portabilitat, mentre que Kubernetes conserva els manifestos del mòdul 6 gairebé tal com estan.

Preguntes prèvies: qui és el propietari declarat de la plataforma mexicana i quina és la seva finestra de manteniment?; hi ha requisit legal de residència de dades que impedeixi replicar a Europa?; quin és el pressupost mensual màxim i es prefereix pagar més per no contractar algú de sistemes? La tercera sol decidir de debò, i no és una pregunta tècnica.

Has tancat el buit que quedava sota la plataforma: les màquines. Saps què va ser Docker Machine, què resolia amb els seus drivers i el seu eval $(docker-machine env), i per què està arxivat des del 2021; si el veus en un tutorial o en un script heretat, saps llegir-lo i saps com retirar-lo.

El que va sobreviure el tens a les mans: els contextos. Vas crear aurora-prod sobre SSH, vas comprovar el daemon remot sense obrir sessió, vas desplegar amb docker --context aurora-prod compose up -d i vas entendre els tres paranys —volums que es resolen al servidor, contextos de build que viatgen per la xarxa i ports que es publiquen on no mires—, amb la regla que se'n deriva: en producció no es construeix, es fa pull d'una imatge signada. I tens clar per què ssh:// guanya a tcp://, i per què un 2375 obert no és un descuit sinó una màquina regalada.

Del costat modern domines el repartiment de papers: cloud-init perquè l'host neixi configurat, Terraform o OpenTofu per crear-lo de manera declarativa i revisable en un pull request, Ansible per mantenir la flota sense deriva i desplegar la pila amb mòduls idempotents, Packer quan l'arrencada ha de durar segons, i els serveis gestionats quan la millor manera de cuidar un host és no tenir-lo. Amb la taula de criteris pots defensar l'elecció amb arguments, no amb gustos. I t'endús una cosa que no és una comanda: l'host és superfície d'atac —s'hi apliquen pedaços, s'hi posa tallafocs, s'audita— i algú amb nom i cognoms n'ha de ser el responsable abans que arribi el primer client.

A la lliçó següent posem cara a cara les dues maneres de desplegar que ja saps fer servir: Docker Compose i Kubernetes. No com un duel, sinó com una decisió amb criteris, amb equivalències exactes entre tots dos formats i amb una resposta honesta a la pregunta que gairebé ningú no fa en veu alta: quant costa de debò mantenir un clúster.