La lliçó anterior et va donar aïllament fort a un preu alt: cada màquina virtual porta el seu propi nucli, triga mig minut a arrencar, ocupa gigabytes al disc i reserva memòria només per existir. Per a un entorn de proves és raonable. Per desplegar una aplicació i poder-la recrear en segons, és caríssim.

Aquesta lliçó construeix l'alternativa, i comença per la idea que cal tenir clara abans d'escriure el primer docker run, perquè adquirir-la malament condiciona tot el que ve després:

Un contenidor no és una màquina petita. És un procés aïllat.

No hi ha un sistema operatiu a dins. No hi ha un nucli. No hi ha una arrencada. Hi ha un procés normal de l'amfitrió, executant-se amb una vista restringida del sistema de fitxers, de la xarxa i de la taula de processos, i amb un límit de recursos. Tot el que veuràs —les imatges, els volums, les xarxes, Compose— és maquinària al voltant d'aquella idea.

I les tres peces del nucli que la fan possible ja les coneixes per separat: els grups de control (cgroups) són literalment els del MemoryMax=512M que vas posar a 05-05, les capacitats (capabilities) són les de 05-02, i els espais de noms de muntatge són l'evolució del chroot amb què vas reparar GRUB a 07-01.

1. Les tres primitives: espais de noms, grups de control i capacitats
2. Espais de noms d'usuari i el sysctl que vas deixar comentat
3. Instal·lar Docker, i per què el grup docker equival a root
4. Imatges, contenidors i dipòsits d'imatges
5. docker run i les opcions que importen
6. Dockerfile: construir la imatge de Tramontana
7. Construcció en diverses etapes i elecció d'imatge base
8. Dades: volums, muntatges d'enllaç i tmpfs
9. Xarxa i publicació de ports
10. Docker Compose
11. Seguretat de contenidors
12. Alternatives, i quan no fer servir contenidors

Un contenidor no és una funció del nucli. No existeix una crida al sistema crear_contenidor(). És una convenció: un procés llançat amb certes restriccions activades alhora. Veure-ho directament, sense Docker pel mig, és el que fa que tota la resta encaixi.

Un namespace aïlla una classe de recurs global del nucli, de manera que els processos que hi són a dins en vegin la seva pròpia instància. N'hi ha set:

Tots els processos comparteixen els mateixos espais de noms, perquè no hi ha cap contenidor en marxa. Anem a crear-ne un a mà, sense Docker:

Aquí està l'efecte: bash és el PID 1 i només veu dos processos. Des de fora, el mateix procés té un PID normal:

El procés és el mateix. L'única cosa que canvia és el que veu. I això explica per què un contenidor arrenca en mil·lisegons: no hi ha res per arrencar, només un clone() amb unes quantes banderes.

L'espai de noms de xarxa és especialment il·lustratiu, perquè l'aïllament és total:

Ni enp0s3, ni IP, ni rutes, ni un sol sòcol. I lo està DOWN. Aquell és el punt de partida de qualsevol contenidor de Docker abans que se li connecti una interfície virtual.

A 07-01 vas fer servir chroot per entrar en un sistema instal·lat i reparar GRUB. chroot canvia l'arrel del sistema de fitxers per a un procés — és a dir, fa una part del que fa un espai de noms de muntatge.

Però només aquella part, i per això chroot no és un mecanisme de seguretat:

Un procés amb privilegis dins d'un chroot en pot sortir amb relativa facilitat —hi ha tècniques conegudes i documentades— i, encara que no en sortís, té accés complet a la xarxa, als processos i als dispositius de l'amfitrió. L'espai de noms de muntatge resol l'escapada; els altres sis espais de noms resolen la resta.

Els espais de noms controlen el que un procés veu; els grups de control controlen el que consumeix. I això ja ho has fet servir:

És exactament la mateixa tecnologia. Quan a 05-05 vas posar MemoryMax=512M a la unitat de systemd, estaves creant un grup de control amb memory.max. Docker fa el mateix amb --memory 512m. La diferència és l'embolcall, no el mecanisme.

De 05-02: en lloc de «root o no root», el nucli divideix els privilegis en una quarantena de capacitats independents.

Això és el que permet que el procés principal d'un contenidor pugui ser «root» i tot i així no pugui fer gairebé res perillós: se li retiren gairebé totes les capacitats. Docker, per defecte, en deixa unes catorze de les quaranta.

I amb les tres primitives juntes, ja pots definir què és un contenidor sense cap mena de màgia:

Un contenidor és un procés llançat amb espais de noms propis, dins d'un grup de control amb límits, amb un conjunt reduït de capacitats, i amb l'arrel del sistema de fitxers apuntant a la imatge.

L'espai de noms d'usuari és el més recent i el que més conseqüències de seguretat té. Permet que un UID de dins es correspongui amb un UID diferent a fora:

Llegeix-ho a poc a poc, perquè és contraintuïtiu: id diu uid=0(root), però no pot escriure a /etc. L'uid_map explica per què — l'UID 0 de dins és l'UID 1000 de fora. És root del seu propi espai de noms i de ningú més.

Això és el que fa possibles els contenidors sense privilegis (rootless): un usuari normal pot crear espais de noms, muntar-hi sistemes de fitxers a dins i ser root dins del seu contenidor, sense ser root a l'amfitrió.

I ara, el paràmetre que vas deixar comentat a 06-06:

La tensió és real i val la pena entendre-la en tots dos sentits:

La decisió per a srv-tramontana: deixar-lo actiu, perquè executarà contenidors. I la nota que s'afegeix al fitxer, perquè el criteri és el que cal documentar:

Un enfortiment descartat amb el seu motiu escrit és coneixement; descartat en silenci és una omissió.

Docker no és als dipòsits d'Ubuntu amb la versió actual, així que s'instal·la des del dipòsit oficial aplicant el de 05-03: clau a /etc/apt/keyrings/ i signed-by.

Fixa't que afegir un dipòsit de tercers és una decisió de seguretat, com es va dir a 05-03: a partir d'ara, qui controli aquell dipòsit pot instal·lar paquets al teu servidor. signed-by limita la clau a aquell dipòsit concret, que és el mínim exigible.

Aquella ordre apareix a tots els tutorials com una comoditat, i la seva implicació real gairebé mai no s'explica:

Pertànyer al grup docker és equivalent a tenir root sense contrasenya, i sense deixar el rastre que deixa sudo.

No és cap exageració. La demostració cap en una línia:

El dimoni de Docker corre com a root, i -v /:/amfitrio li demana muntar l'arrel de l'amfitrió dins del contenidor. Qualsevol del grup docker pot llegir /etc/shadow, escriure a /etc/sudoers.d/, o modificar /etc/tramontana/secrets/. I ho fa sense aparèixer a auth.log.

Les conseqüències pràctiques, que cal aplicar:

1. El grup docker es tracta com el grup sudo, amb el mateix control de qui hi entra i per què. A srv-tramontana només operador, i consta a la llista de verificació de 06-06.
2. Mai no s'afegeix a un compte de servei ni a un usuari d'aplicació. Si svc-tramontana fos a docker, un compromís de l'aplicació seria root immediat.
3. L'alternativa correcta quan hi ha diverses persones és sudo docker, amb una regla a sudoers.d que registri qui executa què — coherent amb el que vas fer a 05-02 amb desplegar-segur.
4. O fer servir podman, que no té dimoni amb privilegis i resol el problema d'arrel. Es veu al final de la lliçó.

Tres conceptes que es confonen i que convé separar d'una vegada:

La propietat més important d'una imatge és que està formada per capes, cadascuna un conjunt de canvis sobre l'anterior, identificada per la seva suma criptogràfica:

Les capes es comparteixen entre imatges: si deu imatges es basen en alpine:3.20, aquells 7,8 MB s'emmagatzemen una sola vegada. És la mateixa idea que els discos de suport de qcow2 a 07-04, aplicada al sistema de fitxers.

I la implicació de seguretat de les capes, que cal tenir present en escriure un Dockerfile: una capa no desapareix mai. Si en una capa hi copies un fitxer amb una contrasenya i a la següent l'esborres, el fitxer continua sent a la imatge i se'n pot extreure. Hi tornarem.

I ara la comprovació que tanca el primer apartat. Des de l'amfitrió:

El procés de nginx és a la taula de processos de l'amfitrió, amb un PID normal, i pgrep el troba. Només té espais de noms propis i un grup de control. No hi ha cap màquina, cap nucli, cap arrencada. És un procés.

Les opcions de docker run que es fan servir de debò:

Les de gestió del cicle de vida:

docker stop envia SIGTERM, espera 10 segons i després SIGKILL — exactament la disciplina de senyals de 03-06. Si la teva aplicació necessita més temps per tancar netament, --time 30.

Un Dockerfile és la recepta d'una imatge. Cada instrucció que modifica el sistema de fitxers crea una capa.

Les instruccions i el que cal saber de cadascuna:

Docker reutilitza una capa si la instrucció i el seu context no han canviat. Tan bon punt una capa s'invalida, totes les següents es reconstrueixen. D'aquí la regla:

Ordena les instruccions de menys a més freqüentment canviants.

A la primera versió, canviar una línia de codi obliga a tornar a descarregar totes les dependències: minuts a cada construcció. A la segona, segons.

I l'altra regla de capes, la d'encadenar:

L'rm en un RUN posterior no redueix la mida: la capa anterior ja conté els fitxers, i les capes són immutables. És el mateix motiu pel qual un secret copiat i esborrat després continua sent extraïble de la imatge.

.dockerignore importa per dos motius: velocitat —el context s'envia sencer al dimoni— i seguretat, perquè sense ell un COPY . . pot ficar a la imatge el directori .git amb tot l'historial, o un .env amb credencials.

19,4 MB. La comparació amb una construcció d'una sola etapa explica d'on ve:

I el benefici no és només el disc. La imatge de 850 MB conté el compilador de Go, git, make i desenes de biblioteques: cadascuna és superfície d'atac i una font potencial de CVE. La de 19 MB no té res d'això. És el principi de superfície mínima de 06-06 aplicat a una imatge.

Les bases habituals:

Alpine, que es va esmentar a 01-03 en parlar de distribucions, té una peculiaritat que cal conèixer: fa servir musl en lloc de glibc. Un binari compilat contra glibc no funciona a Alpine, i algunes aplicacions —notablement en Python amb extensions natives— tenen problemes subtils de rendiment amb l'assignador de memòria de musl. Amb Go i CGO_ENABLED=0 no hi ha problema, perquè el binari és estàtic.

Les imatges distroless van un pas més enllà: no tenen shell, ni ls, ni gestor de paquets. Un atacant que aconsegueixi execució no té amb què operar. A canvi, depurar exigeix docker debug o una imatge paral·lela amb eines.

El sistema de fitxers d'un contenidor és efímer: en esborrar-lo, la capa d'escriptura desapareix. Les dades que han de sobreviure es munten des de fora, i hi ha tres formes:

Aquell noexec,nosuid del tmpfs és el mateix criteri que vas aplicar a /tmp a 06-06.

La preferència pels volums davant dels muntatges d'enllaç per a dades té motius concrets: Docker els gestiona (creació, permisos, còpia amb docker run --volumes-from), són portables entre amfitrions, i no depenen que existeixi una ruta concreta. Els muntatges d'enllaç són millors per a configuració —perquè la vols editar des de l'amfitrió amb les teves eines— i per a desenvolupament.

I l'advertiment de permisos, que és la font número u de frustració amb volums: els UID són numèrics i no es tradueixen. Un fitxer propietat de l'UID 997 a l'amfitrió pertany a l'UID 997 dins del contenidor, es digui com es digui aquell usuari allà. Per això el Dockerfile de Tramontana crea svc-tramontana amb l'UID 997 i el grup amb el GID 1002: perquè coincideixin amb el servidor.

La diferència entre la xarxa bridge per defecte i una xarxa d'usuari és la que decideix el disseny:

Això és el que permet que app.conf digui db_host=bd en lloc d'una IP que canvia a cada arrencada. A la xarxa bridge per defecte no funciona.

I la publicació de ports, amb un detall de seguretat important:

Avís seriós: Docker escriu regles a nftables i se salta ufw. Un -p 8080:8080 insereix una regla a la cadena DOCKER que s'avalua abans que les d'ufw, així que el port queda accessible des d'Internet encara que ufw status digui que està bloquejat.

Es comprova, i cal comprovar-ho:

Les dues solucions: publicar sempre amb 127.0.0.1: al davant —que és el correcte quan hi ha un servidor intermediari invers al davant, com n'hi haurà a 08-01—, o desactivar la manipulació de regles de Docker:

Compte: amb "iptables": false els contenidors perden la sortida a Internet llevat que escriguis tu les regles de NAT. L'opció pràctica en la majoria dels casos és la primera.

Fixa't també en "log-driver": "journald": envia la sortida dels contenidors al journal, així que journalctl i el logrotate de 05-06 se'ls apliquen també. Per defecte, Docker escriu a fitxers JSON que creixen sense límit i són una causa habitual de discos plens.

Un compose.yaml descriu el conjunt de serveis, xarxes i volums en un fitxer versionable:

depends_on amb condition: service_healthy és la peça que resol un problema real: sense ella, depends_on només espera que el contenidor existeixi, no que el servei de dins estigui llest. L'aplicació arrencaria, no trobaria la base de dades i moriria. Amb la condició, Compose espera el healthcheck.

Aquell -v mereix l'avís: docker compose down -v esborra els volums, és a dir, la base de dades. És un rm -rf amb un altre nom, i la disciplina de 02-04 s'hi aplica igual.

L'aïllament d'un contenidor és més feble que el d'una VM, així que les mesures importen més. Les que cal aplicar sempre:

Sobre els secrets, la demostració de per què ENV és mala idea:

És exactament el problema que vas resoldre a 06-05 amb LoadCredentialEncrypted. L'equivalent a Docker és la secció secrets del compose.yaml, que munta el fitxer en un tmpfs dins del contenidor:

I l'escaneig d'imatges:

Fixa't en un detall que il·lustra l'advertiment del grup docker: aquella ordre munta /var/run/docker.sock dins d'un contenidor, cosa que li dona control complet del dimoni de Docker i per tant de l'amfitrió. Es fa amb imatges en què confies, i amb consciència del que implica.

Dues mesures més que tanquen el cercle amb mòduls anteriors:

El perfil docker-default d'AppArmor i el filtre seccomp per defecte bloquegen unes quaranta crides al sistema perilloses. Desactivar-los amb --privileged o --security-opt seccomp=unconfined és el que converteix un contenidor en un procés amb accés gairebé total a l'amfitrió, i --privileged no ha d'aparèixer mai en producció.

Podman mereix atenció pel que resol:

podman no té dimoni: cada contenidor és un procés fill del que el llança. En mode rootless fa servir espais de noms d'usuari, així que no existeix el problema del grup docker. Les seves ordres són compatibles (alias docker=podman funciona gairebé sempre) i s'integra amb systemd generant unitats, cosa que encaixa bé amb tot el del Mòdul 5. Per a un servidor on diverses persones executen contenidors, és l'opció més defensable.

LXC és diferent en concepte: contenidors de sistema, amb init complet a dins, diversos processos i sessions. S'assembla més a una VM lleugera que a un procés aïllat.

L'honestedat que falta a la majoria de les guies:

Aquell quart punt s'aplica a Tramontana ara mateix: srv-tramontana funciona, està enfortit, monitorat i documentat. Contenidoritzar-lo avui afegiria complexitat sense resoldre cap problema pendent. Els contenidors brillen quan hi ha diversos serveis, diversos entorns o diversos servidors — que és justament el terreny de les dues lliçons següents.

• Pensar en un contenidor com en una VM petita. Porta a ficar-hi systemd, sshd i cron a dins, i a tractar el contenidor com una màquina que s'administra. Un contenidor executa un procés i es reemplaça, no s'administra.
• Afegir algú al grup docker sense entendre el que implica. És root sense contrasenya i sense traça. Tracta'l com el grup sudo.
• Fer servir latest. La imatge canvia sense avisar, i una reconstrucció de la setmana que ve no produeix el mateix. Fixa la versió, i en producció el digest.
• Posar secrets a ENV o en una capa. Queden a la imatge per sempre, encara que els esborris després: les capes són immutables. Fes servir secrets o un fitxer muntat.
• Copiar el codi abans de les dependències al Dockerfile. Invalida la memòria cau a cada canvi i converteix una construcció de segons en una de minuts.
• rm en un RUN posterior per reduir mida. No funciona: la capa anterior ja conté els fitxers. Encadena amb && dins del mateix RUN.
• Oblidar .dockerignore. Un COPY . . pot ficar .git sencer, o un .env amb credencials, a la imatge.
• Executar com a root dins del contenidor. És el valor per defecte i és el primer que cal canviar amb USER.
• Publicar amb -p 8080:8080 i creure que ufw protegeix. Docker escriu regles que s'avaluen abans. Fes servir -p 127.0.0.1:8080:8080 i verifica-ho des de fora amb nmap.
• Deixar el controlador de registre per defecte. Els fitxers JSON creixen sense límit. "log-driver": "journald" els integra amb journalctl i logrotate.
• docker compose down -v sense pensar-hi. Esborra els volums, és a dir, les dades.
• --privileged perquè «funcioni». Desactiva seccomp, AppArmor i les capacitats de cop. Mai en producció; busca la capacitat concreta que falta.
• Consell de mètode. Un contenidor ha de poder morir i renéixer sense que es perdi res. Si el teu té estat dins de la seva capa d'escriptura, alguna cosa està mal muntada: tot el que importa va en un volum.

Demostra, sense fer servir Docker, que un contenidor és un procés aïllat. Crea un «contenidor» a mà amb unshare que tingui el seu propi nom de màquina, la seva pròpia taula de processos i la seva pròpia xarxa, i comprova des de l'amfitrió que continua sent un procés normal. Explica què li falta a la teva construcció per ser un contenidor de debò.

Revisa aquest Dockerfile que ha escrit el Luis i corregeix-lo, explicant cada problema:

La Marta pregunta si convé migrar Tramontana Reserves a contenidors. Redacta l'anàlisi, tenint en compte l'estat real del servidor i el que s'ha vist a les dues últimes lliçons.

Solució 1

Abans cal una arrel mínima, que és justament el que fa una imatge:

I ara, a dins:

Nom propi, PID 1, dos processos visibles, sense xarxa, i una distribució diferent de la de l'amfitrió — tot sense arrencar cap nucli.

La línia NSpid: 10415 1 és la demostració exacta: el mateix procés té el PID 10415 a l'amfitrió i el PID 1 dins del seu espai de noms. I uname -r dona el mateix nucli als dos costats:

Què li falta per ser un contenidor de debò:

La conclusió que es demana: Docker no aporta cap primitiva nova. L'aïllament ja és al nucli des de fa més d'una dècada. El que aporta és l'empaquetat: un format d'imatge amb capes compartides, un dipòsit on publicar-les, una forma reproduïble de construir-les, i l'aplicació coherent de les vuit restriccions de la taula, que a mà serien un guió llarg i fàcil d'equivocar. Entendre això explica per què existeixen alternatives compatibles com podman: si les primitives són del nucli, qualsevol les pot orquestrar.

Solució 2

Onze problemes. La versió corregida, i després el perquè de cadascun:

I el .dockerignore que faltava del tot:

Els onze problemes, en ordre de gravetat:

El resultat mesurat:

684 MB davant de 142, i la contrasenya recuperable amb una sola ordre per qualsevol que tingui accés a la imatge.

La nota que cal donar-li al Luis: la contrasenya que apareix en aquell Dockerfile és la de producció, així que —seguint la regla de 06-05— es considera compromesa des del moment en què es va escriure, i cal rotar-la amb el procediment crear-aplicar-verificar-retirar. No n'hi ha prou de corregir el fitxer.

Solució 3

Anàlisi: migrar Tramontana Reserves a contenidors Per a: Marta Vidal · De: Operacions de sistemes · 18 d'agost de 2026

Recomanació breu: encara no, però sí preparar-ho. Contenidoritzar avui srv-tramontana afegiria complexitat sense resoldre cap problema pendent. Proposo un camí intermedi amb benefici immediat i sense risc.

---

El punt de partida importa. No som davant d'una aplicació desplegada de qualsevol manera. srv-tramontana té desplegament atòmic amb reversió automàtica, servei de systemd enfortit amb la millor puntuació de seguretat que dona l'eina, secrets xifrats, registres centralitzats al journal amb rotació, còpies amb restauració provada, detecció de canvis i un tallafocs de llista blanca. Funciona, està documentat i està mesurat. Aquella és la referència contra la qual cal comparar.

Què hi guanyaríem

1. Desplegaments reproduïbles bit a bit. Avui desplegar.sh mou un enllaç simbòlic a un directori nou, i l'entorn —biblioteques del sistema, versions— és el que hi hagi a la màquina. Amb una imatge, el que es prova és exactament el que es desplega. Recorda que el release 3.3.0 va fallar al juliol i no vam saber per què fins aquesta setmana: una fallada d'aquell tipus és menys probable amb imatges, perquè l'entorn viatja amb l'aplicació.
2. Reversió encara més ràpida. Tornar a la imatge anterior és canviar una etiqueta.
3. Paritat entre entorns. La mateixa imatge en proves i en producció, sense la deriva que apareix quan es configuren dues màquines per separat.
4. Aïllament addicional de l'aplicació. Un compromís quedaria més contingut: sense shell útil, sense accés a la resta del sistema de fitxers, sense capacitats.
5. Preparació per créixer. Si en algun moment calen dues o tres instàncies darrere d'un balancejador, amb contenidors és qüestió de minuts.

Què costaria

1. Refer feina que ja està feta i validada. L'enfortiment de systemd, el perfil d'AppArmor, la gestió de secrets i la integració amb el journal s'haurien de reconstruir amb l'equivalent de contenidors. No és impossible, però són setmanes de feina per arribar on ja som.
2. Una capa més per aprendre i mantenir. Imatges, dipòsits, xarxes virtuals, volums, i els seus modes de fallada propis — que són diferents i menys coneguts que els del sistema.
3. Un risc de seguretat nou i concret. El dimoni de Docker corre com a root, i pertànyer al grup docker equival a tenir root sense deixar traça. A més, Docker escriu regles de tallafocs que se salten ufw: un port publicat queda obert encara que el tallafocs digui el contrari. Ho he verificat al laboratori. S'hauria de gestionar explícitament.
4. La base de dades és el punt difícil. PostgreSQL en contenidor és possible, però l'emmagatzematge persistent afegeix complexitat i no aporta res en un únic servidor. La meva recomanació seria deixar-la fora en qualsevol cas.
5. No resol el nostre problema real. El nostre problema obert és que srv-tramontana és un únic punt de fallada. Els contenidors no el resolen: si la màquina cau, cauen els contenidors. Això és redundància, i és el tema del qual et portaré una proposta.

---

El que proposo, en tres passos

Pas 1 — Ara: contenidoritzar només l'entorn de proves. Benefici immediat, risc nul. Permet aixecar l'aplicació i una base de dades neta en segons per provar un canvi, i aprendre l'eina sense exposar producció. Ja està funcionant a srv-tramontana-proves.

Pas 2 — Després: construir la imatge a cada release, sense desplegar-la. Cada versió produeix a més una imatge versionada i escanejada. Guanyem reproductibilitat i detecció de vulnerabilitats a les dependències, sense canviar res en producció. És un pas reversible.

Pas 3 — Quan es compleixi alguna condició: migrar. Les condicions que ho justificarien:

Condició	Per què canvia la decisió
Calen dues o més instàncies de l'aplicació	És on els contenidors comencen a rendir de debò
Apareixen més serveis (una API, un processador de tasques)	Gestionar cinc serveis a mà és on Compose guanya
Hi ha més d'un entorn per mantenir sincronitzat	La paritat deixa de ser un luxe
Tornem a tenir una fallada per diferències d'entorn	Seria la segona vegada; una és casualitat

I una observació sobre l'alternativa. Si fem el pas, proposo avaluar podman en lloc de Docker: no té dimoni amb privilegis, funciona sense root, resol d'arrel el problema del grup docker, i s'integra amb systemd generant unitats — és a dir, encaixa amb tot el que ja tenim muntat en lloc de substituir-ho. Les seves ordres són compatibles, així que el que hem après no es perd.

Resum. Els contenidors són la resposta correcta a un problema d'escala i reproductibilitat entre entorns. Avui tenim un servidor, un entorn i una aplicació que funciona, així que el benefici no compensa el cost. Comencem per proves i per construir les imatges, que és on el benefici és immediat, i ho reavaluem quan canviï alguna de les condicions de la taula.

Tens la idea correcta, que és el que més val d'aquesta lliçó: un contenidor és un procés aïllat, no una màquina petita. Ho has vist sense intermediaris —un bash que és PID 1 a dins i té un PID normal a fora, amb NSpid: 10415 1 a /proc com a prova— i saps que Docker no inventa cap primitiva: els espais de noms, els grups de control i les capacitats són al nucli, i són literalment els mateixos que el MemoryMax=512M de 05-05 i el chroot de 07-01. El que Docker aporta és l'empaquetat: imatges en capes compartides, un dipòsit d'imatges, construcció reproduïble, i l'aplicació coherent de vuit restriccions que a mà serien un guió llarg i fràgil.

Saps construir una imatge que pesi 19 MB en lloc de 850, ordenant les instruccions per aprofitar la memòria cau i fent servir dues etapes perquè el compilador no arribi a producció — que és el principi de superfície mínima de 06-06 aplicat a una imatge. Saps que un secret en una capa no s'esborra mai, que -p 8080:8080 se salta ufw i cal verificar-ho des de fora amb nmap, que USER no és opcional, i que docker compose down -v destrueix les dades. I has resolt el kernel.unprivileged_userns_clone que vas deixar comentat a 06-06: es queda actiu, amb la decisió i el seu motiu escrits, perquè la contenció que aporten els contenidors val més que la superfície que tanca.

Fixa't ara en on ets. Tens srv-tramontana en producció, srv-tramontana-proves recreable amb cloud-init, i contenidors que aixequen l'aplicació i la seva base de dades amb una ordre. Tres formes de crear màquines i serveis. I les tres comparteixen un problema: la configuració de producció continua sent un manual d'operació en prosa i la memòria de l'administrador. Cada usuari, cada regla de sudoers, cada unitat de systemd, cada línia d'ufw, cada sysctl i cada perfil d'AppArmor dels mòduls 5 i 6 es va aplicar a mà. L'RTO de 8 hores que la Marta va aprovar depèn enterament que algú recordi l'ordre correcte, i la regla de 06-04 —«un servidor compromès es reinstal·la, no es neteja»— és fàcil de dir i cara de complir.

A la lliçó 07-06: Automatització amb Ansible això es converteix en codi. Veuràs la diferència entre un script imperatiu com desplegar.sh i un estat desitjat idempotent, entendràs per què Ansible no necessita agent —treballa sobre l'SSH que vas enfortir a 06-02— i escriuràs inventaris, playbooks amb manejadors i etiquetes, plantilles Jinja2 que generen app.conf amb variables per entorn, i rols que ho organitzen tot en peces reutilitzables. Faràs servir --check i --diff, que són el --dry-run del curs portat a la configuració sencera, guardaràs els secrets amb Vault al costat del teu pass, i provaràs cada canvi contra srv-tramontana-proves abans de tocar producció. I al final faràs la mesura que importa: quant triga a reconstruir-se el servidor des de zero. Aquell número —de vuit hores a menys d'una— és el que converteix una regla de seguretat en un procediment que de debò es pot complir.