Ara mateix tens tres o quatre contenidors a la teva màquina i encara els pots portar al cap. D'aquí a un mes en tindràs trenta: els quatre serveis d'Aurora Libros, mitja dotzena de proves oblidades, contenidors d'altres projectes i un munt d'Exited de fa setmanes ocupant disc i noms. Sense eines de gestió, aquell docker ps -a es converteix en una paret de text impossible de llegir, i el docker rm massiu que executes a les onze de la nit s'emporta per davant alguna cosa que necessitaves.

Aquesta lliçó és la de l'operació diària. Espremeràs docker ps fins al fons —columna per columna, amb els seus filtres i les seves plantilles—, muntaràs un tauler de control dels quatre serveis d'Aurora Libros, aprendràs a compondre comandes amb -q per operar sobre desenes de contenidors sense destrossar res, a copiar fitxers entre el host i un contenidor amb docker cp —amb la qual cosa per fi ompliràs la taula llibres amb els vuit títols—, a veure amb docker diff què ha canviat un contenidor respecte a la seva imatge, i a entendre per què docker commit és una temptació que cal resistir.

1. docker ps: les set columnes, una a una
2. Opcions de llistat: -a, -q, -s, -n, -l
3. Filtrar amb --filter
4. Donar format amb --format i plantilles Go
5. Etiquetes: organitzar la flota amb --label
6. Compondre comandes amb -q (i fer-ho amb cap)
7. Esborrar contenidors: rm, -f, -v i container prune
8. Reanomenar i modificar en calent: rename i update
9. docker cp: moure fitxers en els dos sentits
10. docker diff: què ha canviat respecte a la imatge
11. docker commit i per què no l'has de fer servir
12. El tauler de control d'Aurora Libros

Dues observacions sobre la sortida de dalt, que serveixen de repàs:

• aurora-cache posa Up 4 minutes i no Up 32 minutes perquè el vas reiniciar a la lliçó anterior: el comptador de STATUS es posa a zero amb cada arrencada, mentre que CREATED no es mou.
• El (healthy) d'aurora-cache no apareix per art de màgia: la imatge oficial de Redis 7 porta el seu propi HEALTHCHECK. aurora-db no en mostra res perquè la imatge de PostgreSQL no el defineix. La salut s'estudia a fons a la lliçó 03-04.

Per veure la comanda completa:

Aquesta columna té dos números i la diferència entre tots dos és la lliçó 01-05 feta comanda:

• El primer (0B, 127kB) és la capa d'escriptura: el que aquest contenidor ha escrit per damunt de la imatge. És l'única cosa que li pertany en exclusiva i l'única que es perd en esborrar-lo.
• El virtual és la mida total que veu el contenidor: la seva capa d'escriptura més totes les capes de la imatge, que són compartides i de només lectura.

Deu contenidors de redis:7-alpine no ocupen 412 MB, sinó 41,2 MB més deu capes d'escriptura minúscules. I aurora-db amb els seus 127 kB d'escriptura crida l'atenció: acabes de crear una base de dades sencera, on són les dades? En un volum anònim que la imatge oficial declara, i que no compta com a capa d'escriptura. Retén aquesta pregunta: és el cor de la lliçó 03-06.

--filter (o -f) accepta parells clau=valor i es pot repetir. Els filtres disponibles:

Receptes llestes per copiar:

Exemple real:

Dos avisos sobre el comportament dels filtres:

• Diversos --filter diferents es combinen amb I lògic. --filter status=running --filter name=aurora exigeix les dues condicions.
• Diversos valors del mateix filtre es combinen amb O lògic. --filter status=exited --filter status=created retorna els de qualsevol dels dos estats.
• name és una subcadena, no una igualtat. --filter name=aurora-db també troba aurora-db-copia. Si necessites exactitud, fes servir una expressió ancorada: --filter name=^aurora-db$.

--format fa servir plantilles del llenguatge Go, les mateixes que ja vas emprar amb docker image ls a la lliçó 02-05.

La paraula table al principi activa la capçalera i l'alineació en columnes:

Sense table, la sortida és text lliure, perfecta per fer-hi scripts:

I hi ha dos formats preconstruïts molt socorreguts:

Si un format t'agrada, fes-lo permanent a ~/.docker/config.json:

A partir d'aquell moment, un docker ps sense més fa servir el teu format. És un dels ajustos que més agraeix l'ús diari.

Quan a la mateixa màquina hi conviuen contenidors de tres projectes, filtrar per nom deixa de ser fiable. Les etiquetes són metadades arbitràries que assignes en crear el contenidor:

I després hi filtres amb precisió quirúrgica:

--filter label=clau=valor exigeix el valor exacte; --filter label=clau només exigeix que l'etiqueta existeixi.

Etiquetarem de debò la flota d'Aurora Libros. Com que les etiquetes, igual que els ports i les variables, es fixen en crear el contenidor i no s'hi poden afegir després (lliçó 03-01), cal recrear. No passa res: aurora-db encara no té dades a perdre.

Una convenció d'etiquetes que funciona bé i que farem servir a tot el curs:

Amb aquestes tres etiquetes, operacions com "atura tot el d'Aurora Libros en local sense tocar res més" es tornen trivials, i és exactament el que Docker Compose farà per tu automàticament al mòdul 4: les seves etiquetes com.docker.compose.project són aquest mateix mecanisme.

docker ps -q imprimeix només IDs, i això el converteix en l'entrada de qualsevol altra comanda:

Receptes que es fan servir a diari:

I ara les tres precaucions, perquè aquestes comandes són esmolades:

Primera: si el filtre no troba res, la comanda falla.

Molest però inofensiu. S'evita comprovant abans:

Segona: docker rm -f $(docker ps -aq) és la comanda més perillosa d'aquesta lliçó. Esborra absolutament tots els contenidors de la màquina, inclosos els d'altres projectes, i sense preguntar. Si necessites fer neteja, fes-la acotada:

Tercera: mira abans de disparar. La regla d'or és executar primer la versió que només llista:

Aquest mig segon de més ha salvat moltes bases de dades de desenvolupament.

docker rm només funciona sobre contenidors aturats. Amb un en marxa:

Sobre -f, un matís important que enllaça amb la lliçó anterior: docker rm -f no és docker stop + docker rm. Envia SIGKILL directament, sense els deu segons de gràcia. Sobre una base de dades, això és desendollar el servidor. La seqüència correcta quan hi ha dades pel mig és:

Què passa exactament en esborrar un contenidor:

Esborra tots els contenidors aturats. Val la pena repetir l'avís de la lliçó 02-05: un contenidor aturat pot ser alguna cosa que estaves depurant o una base de dades de desenvolupament que vas apagar ahir. Acota sempre que puguis:

Ja vas veure docker rename a la lliçó anterior. El seu company és docker update, que sí que pot canviar coses d'un contenidor en marxa, encara que una llista molt concreta:

El detall de totes aquestes opcions de recursos i de les polítiques de reinici és el contingut de la lliçó 03-07; aquí només importa retenir la frontera: update toca el que viu als cgroups; tot el que viu als namespaces (xarxa, muntatges, entorn) es fixa en crear el contenidor.

Un dels dos costats porta el prefix contenidor: i l'altre és una ruta del host. Funciona en les dues direccions i també amb contenidors aturats.

Ha arribat el moment d'omplir la base de dades. Tens ~/aurora-libros/db/init.sql des de la lliçó 01-07, amb la taula llibres i els vuit títols:

I ara executa'l dins del contenidor:

Comprova el resultat:

Els vuit llibres d'Aurora Libros són en una base de dades real, en un contenidor real. És la primera vegada en tot el curs que existeixen fora d'un fitxer .sql. Encara ningú no els pot llegir des de l'API —això arriba a la lliçó 03-05—, però ja hi són.

Un apunt de mètode: carregar l'esquema a mà amb docker cp funciona però no és la manera correcta, perquè cal repetir-ho cada vegada que recreïs el contenidor i ningú no se'n recorda. A la lliçó 03-06 ho resoldràs bé, muntant init.sql a /docker-entrypoint-initdb.d/ perquè PostgreSQL l'executi tot sol en inicialitzar-se.

El sentit invers és igual de fàcil i resulta imprescindible en investigar un incident:

I un cas molt habitual: rescatar el registre d'una aplicació que —contra tota bona pràctica— escriu en un fitxer en comptes de a la sortida estàndard.

Detalls del comportament de docker cp que eviten sorpreses:

Aquest últim punt mossega sovint: si copies un fitxer a un contenidor que corre amb USER node, el fitxer pertanyerà a root i l'aplicació potser no el podrà llegir. I una limitació clara: docker cp no pot copiar d'un contenidor a un altre directament; cal passar pel host.

docker diff compara el sistema de fitxers actual del contenidor amb el de la imatge de la qual va sortir:

Tres lletres i el seu significat:

És la manifestació visible del copy-on-write de la lliçó 01-05: el que veus aquí és exactament el contingut de la capa d'escriptura, i per això docker diff i la columna SIZE de docker ps -s parlen del mateix.

I ara l'observació important:

Ni una línia. Acabes de crear una taula i vuit registres, i el directori de dades de PostgreSQL no apareix al diff. La raó és que /var/lib/postgresql/data no està a la capa d'escriptura: la imatge oficial hi declara un VOLUME, així que Docker va crear un volum anònim i el va muntar en aquella ruta. I docker diff mai no mira dins dels muntatges.

Això és exactament el que anticipava la lliçó 02-04 en parlar de per què VOLUME en un Dockerfile té efectes secundaris, i és la porta d'entrada a la lliçó 03-06: hi ha dades que no viuen ni a la imatge ni a la capa d'escriptura, sinó en un tercer lloc. Un lloc que ara mateix, per a aurora-db, és anònim i fràgil.

Un cas d'ús molt pràctic de docker diff: descobrir què escriu una aplicació de la qual no et refies.

En deu línies saps que Nginx modifica la seva configuració en arrencar (ho fa el seu docker-entrypoint.sh), crea un fitxer de PID i diversos directoris de memòria cau. És informació valuosíssima quan vulguis fer el sistema de fitxers de només lectura per seguretat, cosa que veuràs a la lliçó 05-03.

docker commit converteix l'estat actual d'un contenidor en una imatge nova:

Funciona. I precisament per això és perillós. Aquests són els motius pels quals no es construeixen imatges així, reprenent tot el mòdul 2:

Al vocabulari de l'ofici, una imatge així s'anomena imatge artesanal o snowflake, i és l'equivalent contenidoritzat d'aquell servidor que ningú no gosava reiniciar. Té, això sí, un ús legítim:

Desar l'escena del crim abans de netejar-la. Per a això sí, i per a res més.

Tanquem ajuntant tot el de la lliçó en una comanda que faràs servir a diari:

Converteix-la en un àlies permanent al teu ~/.bashrc o ~/.zshrc:

I una versió amb salut i mida, per quan alguna cosa va malament:

Fixa't que la capa d'escriptura d'aurora-db ha crescut de 127 kB a 3,14 kB… un moment, ha baixat. El que passa és que el contenidor és nou: el vas recrear en afegir-li les etiquetes, i aquests 3,14 kB són gairebé exclusivament l'init.sql que vas copiar amb docker cp. Les dades dels vuit llibres no hi són, sinó al volum anònim del qual parlàvem. Un recordatori més que hi ha una peça del trencaclosques que encara no has col·locat.

• Executar docker rm -f $(docker ps -aq) "per netejar". S'emporta tot el de la màquina, inclosos contenidors d'altres projectes i bases de dades de desenvolupament amb setmanes de dades. Filtra sempre per label o per name.
• Confiar en --filter name= com si fos una igualtat. És una subcadena: name=aurora-db també troba aurora-db-backup. Ancora amb ^...$ quan importi.
• Llegir la columna CREATED com a "arrencat fa". És la data de creació. Per al temps en marxa, mira STATUS o {{.RunningFor}}.
• Interpretar la mida virtual com a espai ocupat. Deu contenidors de la mateixa imatge comparteixen les seves capes: el disc real és la suma de les capes d'escriptura més una còpia de la imatge.
• Fer servir docker rm -f sobre una base de dades. És un SIGKILL sense gràcia. Primer docker stop --time 30, després docker rm.
• Oblidar -v en esborrar i acumular volums anònims orfes. Cada contenidor de PostgreSQL esborrat sense -v deixa enrere el seu volum. Es localitzen amb docker volume ls -f dangling=true (lliçó 03-06).
• Copiar fitxers amb docker cp a un contenidor sense privilegis i no entendre el permission denied. El fitxer hi arriba com a root. Fes servir -a, o ajusta-ho després amb docker exec -u root ... chown.
• Construir imatges amb docker commit. Funciona avui i et deixa sense explicació demà. El Dockerfile és la font de la veritat.
• Consell: desa els teus formats preferits a ~/.docker/config.json amb psFormat. Un docker ps llegible per defecte és un regal diari.
• Consell: abans de qualsevol operació massiva, executa la versió que només llista. Mira la llista, i només llavors canvia ps per rm.

Crea cinc contenidors de prova amb alpine:3.20 i sleep 300, etiquetats així: dos amb projecte=aurora-libros i entorn=local, dos amb projecte=aurora-libros i entorn=proves, i un amb projecte=altre-client. Després escriu una única comanda docker ps que mostri només els d'Aurora Libros en entorn de proves, en una taula amb les columnes nom, entorn i temps en marxa. Finalment, atura i esborra en una sola comanda exclusivament els d'altre-client, deixant la resta intacta, i demostra amb una altra comanda que els quatre d'Aurora Libros continuen vius.

Arrenca un contenidor de redis:7-alpine anomenat diff-redis. Abans de tocar res, executa docker diff i anota el resultat. Després escriu 100 claus amb redis-cli, força un desament a disc amb redis-cli SAVE, i torna a executar docker diff. Respon:

1. Apareix el fitxer de dades de Redis al docker diff? I a la columna SIZE de docker ps -s?
2. Esbrina amb docker inspect --format '{{json .Mounts}}' on és realment aquest fitxer.
3. Copia'l al host amb docker cp i comprova'n la mida amb ls -lh.
4. Esborra el contenidor amb docker rm -f (sense -v) i explica què ha passat exactament amb aquelles 100 claus. S'han perdut? On són?

Simula el final d'una jornada de treball caòtica:

1. Crea sis contenidors que acabin immediatament: tres amb codi 0 (alpine:3.20 true) i tres amb codi 1 (alpine:3.20 sh -c 'exit 1'), tots amb l'etiqueta projecte=proves-neteja.
2. Escriu una comanda que llisti només els que van fallar, amb el seu nom i el seu estat.
3. D'un dels fallits, extreu amb docker cp el fitxer /etc/os-release al host abans d'esborrar-lo.
4. Esborra en una sola comanda només els que van fallar, deixant els tres correctes.
5. Finalment, neteja la resta amb docker container prune acotat a l'etiqueta, i verifica que ni aurora-db ni aurora-cache no s'han vist afectats.

Solució a l'exercici 1

La comanda del tauler, amb dos filtres combinats amb I lògic:

Els d'entorn=local no hi apareixen: compleixen el primer filtre però no el segon, i tots dos s'han de complir.

Esborrat quirúrgic d'altre-client:

Els quatre d'Aurora Libros continuen drets. La seqüència mirar → actuar → comprovar és la que converteix una comanda perillosa en una operació rutinària.

Solució a l'exercici 2

Pràcticament res: Redis acabat d'arrencar només escriu el seu fitxer de PID. Ara, càrrega i desament:

1. Aquí hi ha la sorpresa de l'exercici: dump.rdb existeix (l'acabes de llistar amb ls -lh, 3,4 kB) però no apareix al docker diff, i la capa d'escriptura continua mesurant 0 B. Les dues eines estan d'acord entre elles i totes dues diuen la veritat: aquest fitxer no és a la capa d'escriptura del contenidor.

2. L'explicació és als muntatges:

La imatge oficial de Redis declara VOLUME /data, així que Docker va crear un volum anònim —aquest nom que sembla un hash és exactament això: un volum sense nom— i el va muntar a /data. Tot el que Redis hi escriu va al volum, no a la capa d'escriptura, i per això docker diff no ho veu.

3.

docker cp sí que llegeix a través dels muntatges: per a ell, /data/dump.rdb és simplement una ruta del sistema de fitxers del contenidor. Els 3,4 kB coincideixen amb l'ls de dins; els 5,63 kB que informa Docker són la mida del flux tar amb què es fa la còpia, amb les seves capçaleres i el seu farciment a blocs.

4.

La resposta correcta és més interessant que un simple "s'han perdut":

• Les claus que eren en memòria van morir amb el procés, com a l'exercici de la lliçó anterior.
• Però el dump.rdb amb les 100 claus continua existint, en un volum que ara està orfe: sense contenidor que el faci servir, amb un nom que ningú no recorda i ocupant disc indefinidament. Com que vas fer servir docker rm -f sense -v, el volum no es va esborrar.
• Si demà arrenques un altre redis:7-alpine, Docker crearà un volum anònim nou i buit: no reutilitzarà l'anterior. Des del punt de vista pràctic, les dades estan perdudes encara que els bytes continuïn al teu disc.

Això és exactament el que li passa avui a aurora-db amb els vuit llibres que acabes de carregar, i és el problema que resol la lliçó 03-06 posant-li al volum un nom.

Solució a l'exercici 3

2. Llistar només els que van fallar, combinant status i exited:

El filtre exited=1 és el que fa la feina fina: distingeix "va acabar" de "va acabar malament", cosa que status=exited per si sol no pot.

3. Rescatar un fitxer d'un contenidor aturat:

Detall important: docker cp funciona amb el contenidor aturat. No cal arrencar-lo, i això el converteix en l'eina ideal per fer autòpsies de contenidors que ja no s'aixequen.

4. Esborrat selectiu dels fallits:

Els tres correctes continuen allà. No va caldre -f perquè ja estaven aturats.

5. Neteja final acotada i verificació:

aurora-db i aurora-cache intactes, perquè el --filter label= va acotar el prune a l'etiqueta correcta. Compara mentalment amb el que hauria passat amb un docker container prune -f sense més: els tres ok-* haurien caigut igual, però també qualsevol contenidor aturat de qualsevol altre projecte de la teva màquina. Les etiquetes no són burocràcia: són el mecanisme que fa que la neteja sigui selectiva en comptes d'indiscriminada.

Ja no mires docker ps: el llegeixes. Saps què diu cadascuna de les seves set columnes i, sobretot, què no diu —que CREATED no és l'hora d'arrencada, que IMAGE pot haver quedat obsoleta si l'etiqueta es va moure, i que el número virtual de -s no és espai ocupat sinó espai vist—. Saps filtrar per estat, nom, imatge, etiqueta, codi de sortida i salut, combinant filtres amb I i amb O, i saps donar forma a la sortida amb plantilles Go fins a convertir-la en un tauler de control d'Aurora Libros que cap en un àlies.

Has après a compondre comandes amb -q i, més important, a fer-ho amb xarxa: mirar → actuar → comprovar, filtrant sempre per etiqueta perquè un esborrat massiu no s'emporti mai el que no era seu. Coneixes la diferència entre docker rm i docker rm -f —que no és stop + rm, sinó un SIGKILL sense gràcia—, saps què es destrueix i què sobreviu en esborrar un contenidor, i fas servir docker container prune acotat amb until i label en comptes de a pèl. Has etiquetat la flota amb projecte, component i entorn, que és exactament el mecanisme que Docker Compose automatitzarà per tu al mòdul 4.

Amb docker cp mous fitxers en els dos sentits, fins i tot amb el contenidor aturat, i això t'ha servit per a una cosa memorable: els vuit llibres d'Aurora Libros estan carregats a PostgreSQL, amb la seva taula, el seu índex i el seu INSERT 0 8. Amb docker diff saps veure la capa d'escriptura convertida en llista de fitxers —A, C i D— i has descobert la peça que falta: el directori de dades de PostgreSQL no apareix al diff, perquè no és a la capa d'escriptura, sinó en un volum anònim que la imatge declara i que ningú no controla. I saps per què docker commit no serveix per construir imatges, encara que sigui perfecte per congelar l'escena d'un crim abans de netejar-la.

Saps mirar la flota quan tot va bé. Falta l'altra cara. A la lliçó següent, Inspecció i Depuració de Contenidors, t'enfrontaràs als contenidors que no funcionen i no diuen per què: llegiràs docker logs a fons amb els seus filtres de temps i la seva regla d'or sobre stdout, entraràs amb docker exec fins i tot en imatges mínimes que no tenen ni ping —amb contenidors efímers que en comparteixen els namespaces—, espremeràs el JSON de docker inspect amb plantilles i jq, i vigilaràs en directe amb docker top, docker stats i docker events. I aplicaràs tot això a tres avaries reals d'Aurora Libros, entre elles la que fa dues lliçons que espera: per què aurora-api no troba aurora-db encara que tots dos estiguin corrent a la mateixa màquina.