Docker resol construir i executar contenidors. Tota la resta —veure què passa sense bussejar dins de docker ps, saber per què una imatge pesa de més, detectar vulnerabilitats abans de publicar, muntar un registre d'imatges propi, provar contra una base de dades real— ho resol l'ecosistema que hi ha al voltant. Aquesta lliçó no és un catàleg: és l'equipament seleccionat amb criteri, i el criteri per seleccionar-lo tu.

1. Els tres nivells d'extensibilitat
2. Construeix el teu propi docker aurora
3. Plugins del daemon i extensions de l'escriptori
4. Interfícies de gestió
5. Inspecció i optimització d'imatges
6. Seguretat
7. Registres d'imatges propis
8. Desenvolupament i proves
9. Construcció sense Dockerfile
10. Neteja i manteniment
11. Xarxa i diagnòstic
12. Criteris per adoptar una eina
13. El kit mínim recomanat

La regla que se'n dedueix: experimenta lliurement al nivell de la CLI, sigues conservador al del daemon. Un plugin de logging mal escrit bloqueja l'arrencada de tots els contenidors de l'host.

El mecanisme dels plugins de CLI és sorprenentment simple: qualsevol executable anomenat docker-alguna-cosa a ~/.docker/cli-plugins/ es converteix en docker alguna-cosa. Així funcionen docker compose, docker buildx i docker scout. L'únic requisit formal és respondre a la subcomanda oculta docker-cli-plugin-metadata.

Quaranta línies i l'equip sencer deixa de memoritzar comandes llargues. Desa'l al repositori amb un make install-plugin i formarà part de l'onboarding. L'asterisc a l'ajuda indica que és un plugin, no una comanda nativa.

Els plugins del daemon amplien Docker per sota. S'instal·len amb docker plugin install i es gestionen per separat:

L'avís seriós: un plugin de logging que es bloqueja pot impedir que els contenidors arrenquin, perquè el daemon espera que accepti el flux. Abans de posar-lo en producció, prova'l amb la destinació caiguda a propòsit i comprova que mode: non-blocking està configurat.

Les extensions de Docker Desktop són contenidors amb interfície que s'integren al panell. Còmodes i amb la mateixa precaució que qualsevol codi de tercers amb accés al socket del daemon: si controla el socket, controla l'host (05-03).

Amb la pila d'Aurora Libros aixecada, lazydocker et dona en una pantalla els quatre contenidors, els seus logs en viu i el seu consum, i permet reiniciar aurora-api amb una tecla. Per depurar en local és més ràpid que qualsevol GUI.

Portainer només es justifica quan hi ha diverses persones operant diversos hosts i calen permisos per usuari. Per a un servidor i un equip petit amb Compose, Dockge és més lleuger i no amaga el YAML: continues tenint els teus fitxers i els edites des del navegador.

Precaució comuna a totes: exposen el socket de Docker. Portainer o Dockge accessibles des d'Internet sense autenticació forta equivalen a regalar l'host.

Aquell 98 % és el resultat de la feina de 05-04: la multietapa va deixar fora les dependències de compilació i no hi ha fitxers duplicats entre capes. dive en mode integració retorna un codi de sortida diferent de zero si el projecte baixa del llindar, i això encaixa directament al pipeline:

Sobre slim: aprima automàticament executant l'aplicació i quedant-se només amb el que va tocar. Pot portar una imatge de 400 MB a 30 MB, i també pot trencar-la de manera silenciosa el dia que s'executi una ruta de codi que no es va provar durant l'anàlisi. Fes-lo servir amb una bateria de proves completa al darrere, i prefereix sempre arreglar el Dockerfile si hi tens accés.

hadolint és el més barat d'adoptar i el que més problemes evita, perquè actua abans de construir res. Sobre una versió primerenca del Dockerfile de l'API:

Sis avisos que són exactament el temari dels mòduls 2 i 5: fixar la base, netejar memòries cau de paquets, fixar versions, COPY en lloc d'ADD, no acabar com a root i posar cometes a les variables dins de RUN. Sobre el Dockerfile actual d'aurora-api:2.0.0 no en surt cap, perquè la base està fixada per digest i l'USER final no és root. Integrar-lo costa quatre línies:

Falco és el que cobreix el buit que ningú més no cobreix: els altres analitzen artefactes aturats; Falco vigila syscalls en viu i alerta quan un contenidor fa alguna cosa que no hauria de fer —obrir una shell dins d'aurora-api, escriure a /etc, connectar-se a una IP desconeguda—. És l'última línia quan la vulnerabilitat no era a cap base de dades.

Sobre les tres primeres de la taula: no cal triar-ne una de sola. Trivy al pipeline com a porta que fa fallar el build, Scout a l'escriptori per a la comprovació primerenca, i Grype com a segona opinió quan un resultat sorprèn. Cada escàner fa servir fonts diferents i no coincideixen sempre.

Un ús que compensa gairebé sempre i que gairebé ningú no aplica: un mirall de Docker Hub a la xarxa local. Estalvia amplada de banda, esquiva els límits de descàrrega i manté el pipeline funcionant quan Hub té una mala tarda.

Harbor només es justifica quan hi ha diversos equips, polítiques de retenció, replicació entre regions i necessitat d'auditoria. És una plataforma amb base de dades, Redis i diversos components: algú l'ha de mantenir.

Testcontainers és la que més canvia la vida i la que menys es coneix. A 06-02 vas muntar serveis de PostgreSQL i Redis al workflow de CI; Testcontainers fa que el mateix test els aixequi, amb la qual cosa les proves s'executen igual al teu portàtil i al pipeline sense configuració duplicada:

El segon test és el que justifica l'eina: comprovar que el cache-aside retorna origen: cache exigeix un Redis de debò. Amb un doble de prova hauries validat el teu propi simulacre, no el comportament real. Testcontainers necessita un daemon accessible; a CI ja el tens, i funciona igual contra Podman amb el socket compatible (07-05).

Tilt i Skaffold resolen un altre problema: quan desenvolupes contra un clúster, el cicle build-push-deploy són minuts. Tots dos el redueixen a segons sincronitzant fitxers dins del Pod. Només compensen si el teu bucle intern és Kubernetes; si desenvolupes amb docker compose watch (04-07), no els necessites.

Aquí tens el compromís en una línia. Buildpacks t'estalvia escriure i mantenir el Dockerfile, i a canvi produeix una imatge quatre vegades més gran. Quan compensa?

Per a Aurora Libros, amb una imatge ben optimitzada, multiarquitectura i signada, no compensa. Per a una plataforma interna amb quaranta microserveis, probablement sí.

El disc s'omple sol. Automatitza-ho abans que et desperti una alerta:

El filtre until és la diferència entre una neteja segura i un pull complet l'endemà al matí. I la línia del comentari és la més important de l'script.

netshoot és una imatge amb totes les eines de xarxa que les teves imatges de producció, correctament, no porten: dig, curl, tcpdump, ss, iperf3, nmap.

La segona forma és la potent: --network container: comparteix el namespace de xarxa d'aurora-api (05-07), així que veus exactament les seves connexions i els seus ports sense instal·lar res a dins ni modificar la imatge. És el mateix que fa docker debug, amb una imatge pública i sense subscripció.

dockviz dibuixa l'arbre d'imatges i contenidors; útil per entendre un host heretat amb quaranta imatges d'origen desconegut.

Dues regles d'or. Primera: com més a prop del pipeline, més exigent. Una TUI local que s'abandoni se substitueix en cinc minuts; un plugin que signa les teves imatges i deixa de rebre pedaços és un problema de seguretat i de desplegament alhora. Segona: valida amb el responsable de seguretat qualsevol eina que entri a la cadena de construcció o que necessiti el socket del daemon, i comprova'n la llicència amb qui correspongui abans d'integrar-la en un producte comercial. Afegir una dependència al pipeline és una decisió d'arquitectura, no una preferència personal.

Si només en poguessis adoptar tres per a la resta de la teva carrera: hadolint (evita errors abans de construir), Trivy (impedeix publicar alguna cosa vulnerable) i Testcontainers (fa que les teves proves signifiquin alguna cosa). Totes tres són de codi obert, estan mantingudes i no lliguen ningú.

• Exposar Portainer o Dockge a Internet. Controlen el socket del daemon: qui hi entra és root a l'host. VPN o xarxa interna, sempre, i amb autenticació forta.
• Instal·lar un plugin de logging sense provar la fallada de la destinació. Si la destinació no respon i el mode és bloquejant, els contenidors no arrenquen. Prova-ho amb Loki caigut a propòsit.
• Confiar només en slim. Aprima observant una execució; el que no es va executar, desapareix. Sense una bateria de proves completa al darrere, és una bomba de rellotgeria.
• Acumular tres escàners que diuen el mateix. Un com a porta del pipeline, un altre com a segona opinió puntual. Més només genera soroll que ningú no llegeix.
• Afegir --volumes a la neteja programada. És la manera més ràpida de perdre aurora-dades un diumenge a la nit.
• Adoptar una eina perquè va sortir en una conferència. Aplica-hi abans la taula de §12: manteniment, llicència, criticitat i cost de sortida.
• Consell: posa hadolint al pipeline avui mateix. Costa quatre línies i evita mitja dotzena de males pràctiques per Dockerfile.
• Consell: desa el plugin docker aurora al repositori. Les dreceres de l'equip deixen de viure a l'historial de bash de cadascú.
• Consell: aprèn netshoot amb --network container:. Resol el 90 % de les depuracions de xarxa sense tocar la imatge.

Exercici 1 — Amplia docker aurora. Parteix del plugin de §2 i afegeix-hi tres subcomandes: escanejar, que executi Trivy sobre la imatge local de l'API i falli si hi ha vulnerabilitats crítiques; pesar, que mostri la mida de la imatge i executi dive --ci amb un llindar d'eficiència del 95 %; i xarxa, que llanci netshoot al namespace de xarxa d'aurora-api i comprovi que resol aurora-db i arriba a aurora-cache. El plugin ha de continuar funcionant sense instal·lar res més que Docker.

Exercici 2 — Lint i correcció d'un Dockerfile. Escriu a propòsit un Dockerfile dolent per a aurora-api (base sense etiqueta, apt-get sense netejar, ADD en lloc de COPY, npm install sense versió fixada, sense USER), passa-li hadolint i anota cada codi d'avís. Corregeix-los un a un fins que el lint quedi net, explicant en un comentari quin problema real evita cada correcció. Afegeix després la comprovació al pipeline amb llindar warning.

Exercici 3 — Avaluació d'adopció. Un company proposa afegir al pipeline una eina que optimitza automàticament les imatges abans de publicar-les. La publica un desenvolupador individual a Docker Hub, té 900 estrelles a GitHub, l'últim commit és de fa onze mesos i la imatge no està signada. Aplica la taula de criteris de §12 i escriu una resposta raonada: la teva recomanació, els tres riscos concrets que identifiques, i quines condicions s'haurien de complir perquè l'acceptessis.

Solució 1.

Tres decisions importen més que la resta. El muntatge del socket és imprescindible perquè tant Trivy com dive inspeccionen imatges locals del daemon, no remotes; muntar ~/.cache/trivy evita descarregar la base de vulnerabilitats sencera a cada execució, que és el que fa que la primera vegada trigui un minut i les següents tres segons. L'--exit-code 1 converteix l'escaneig en una porta: sense ell, Trivy informa i retorna 0, i el pipeline passaria amb vulnerabilitats crítiques. I --ignore-unfixed evita el soroll de fallades que encara no tenen pedaç disponible, sobre les quals no pots actuar. A xarxa, --network container:aurora-api entra al namespace de xarxa del contenidor real (05-07), de manera que el que veus és la seva resolució DNS i les seves connexions, no les d'una xarxa qualsevol.

Solució 2. Dockerfile dolent i els codis que dispara:

Versió corregida:

L'avís que més se subestima és el DL3025: amb CMD npm start, PID 1 és un shell que no propaga SIGTERM, i tota l'aturada ordenada que vas muntar a 06-01 deixa de funcionar sense que cap test ho detecti. Es manifesta com a peticions tallades durant els desplegaments, i costa dies trobar-ho si no saps on mirar.

Solució 3. Recomanació: no adoptar-la al pipeline en el seu estat actual.

Els tres riscos concrets: (1) cadena de subministrament —una imatge sense signar d'un autor anònim, executant-se a CI amb accés a les teves imatges i probablement al socket, és exactament el vector que Cosign i les attestations de 06-02 van venir a tancar—; (2) trencament silenciós, perquè una optimització automàtica pot eliminar un fitxer que només es fa servir en una ruta poc freqüent, i ho descobriries en producció; (3) abandonament, ja que onze mesos sense commits en una eina que toca l'artefacte final significa que el dia que trenqui amb una versió nova de BuildKit, el desplegament s'atura i l'arreglada és teva.

Condicions per acceptar-la: que s'executi fora de la ruta crítica, com a informe comparatiu i no com a pas que modifica la imatge publicada; que la imatge estigui signada i fixada per digest; que existeixi una bateria de proves d'integració que validi la imatge optimitzada abans de publicar-la; i que el responsable de seguretat validi la llicència i la procedència. Contraproposta raonable: l'objectiu del company —imatges més petites— ja està cobert per la multietapa i dive --ci amb llindar, que són part del pipeline, no depenen de tercers i ja donen un 98 % d'eficiència sobre aurora-api:2.0.0. La conversa no és «no», és «aquest problema ja està resolt».

Ja tens l'equipament que envolta Docker i, més important, el criteri per triar-lo. Entens els tres nivells d'extensibilitat i la seva asimetria de risc: a la CLI experimenta lliurement, al daemon sigues conservador, perquè un plugin de logging bloquejat impedeix arrencar contenidors. I has construït el teu propi docker aurora amb quaranta línies de bash, descobrint que el mecanisme de docker compose i docker buildx és simplement un executable al PATH que respon a docker-cli-plugin-metadata.

Del recorregut per categories t'endús selecció, no catàleg: lazydocker i ctop per veure la flota sense teclejar, Portainer només quan hi ha diverses persones i diversos hosts, Dockge quan el que gestiones són piles de Compose; dive confirmant el 98 % d'eficiència que vas guanyar a 05-04 i servint de porta a CI amb --ci --lowestEfficiency, container-diff per auditar què va canviar entre versions i slim amb la seva advertència seriosa; hadolint assenyalant en sis avisos tot el temari dels mòduls 2 i 5 —inclòs el DL3025 que trenca l'aturada ordenada sense que cap test ho noti—, Trivy com a porta, Scout com a comprovació primerenca i Falco vigilant syscalls quan la vulnerabilitat no era a cap base de dades; el mirall de Docker Hub amb registry:2 que gairebé ningú no munta i gairebé sempre compensa; Testcontainers aixecant PostgreSQL i Redis des del mateix test per comprovar que el cache-aside retorna origen: cache de debò; Buildpacks amb el seu compromís mesurat —412 MB davant dels teus 104— i la taula de quan compensa no escriure un Dockerfile; la neteja programada amb until i sense --volumes; i netshoot amb --network container: entrant al namespace de xarxa d'aurora-api sense tocar la imatge.

I t'endús els criteris d'adopció, que valen més que qualsevol llista d'eines: manteniment actiu, llicència compatible, procedència verificable, criticitat al pipeline, comprensió real de l'equip, cost de sortida i superfície d'atac afegida. Amb les dues regles d'or: com més a prop del pipeline, més exigent, i valida amb el responsable de seguretat —i amb qui porti les llicències— qualsevol eina que entri a la cadena de construcció o demani el socket del daemon. Si t'haguessis de quedar amb tres per a la resta de la teva carrera: hadolint, Trivy i Testcontainers.

A la lliçó següent fem un pas enrere fonamental: Podman, containerd i l'estàndard OCI. Descobriràs per què les imatges que has anat construint tot el curs no són «de Docker», què normalitza exactament l'Open Container Initiative, i com ghcr.io/auroralibros/aurora-api:2.0.0 s'executa igual a Podman, a containerd o en un node de Kubernetes sense canviar ni un sol byte.