Docker resuelve construir y ejecutar contenedores. Todo lo demás —ver qué pasa sin bucear en docker ps, saber por qué una imagen pesa de más, detectar vulnerabilidades antes de publicar, montar un registro propio, probar contra una base de datos real— lo resuelve el ecosistema que hay alrededor. Esta lección no es un catálogo: es el equipamiento seleccionado con criterio, y el criterio para seleccionarlo tú.

1. Los tres niveles de extensibilidad
2. Construye tu propio docker aurora
3. Plugins del daemon y extensiones del escritorio
4. Interfaces de gestión
5. Inspección y optimización de imágenes
6. Seguridad
7. Registros propios
8. Desarrollo y pruebas
9. Construcción sin Dockerfile
10. Limpieza y mantenimiento
11. Red y diagnóstico
12. Criterios para adoptar una herramienta
13. El kit mínimo recomendado

La regla que se deduce: experimenta libremente en el nivel de la CLI, sé conservador en el del daemon. Un plugin de logging mal escrito bloquea el arranque de todos los contenedores del host.

El mecanismo de los plugins de CLI es asombrosamente simple: cualquier ejecutable llamado docker-algo en ~/.docker/cli-plugins/ se convierte en docker algo. Así funcionan docker compose, docker buildx y docker scout. El único requisito formal es responder al subcomando oculto docker-cli-plugin-metadata.

Cuarenta líneas y el equipo entero deja de memorizar comandos largos. Guárdalo en el repositorio con un make install-plugin y forma parte del onboarding. El asterisco en la ayuda indica que es un plugin, no un comando nativo.

Los plugins del daemon amplían Docker por debajo. Se instalan con docker plugin install y se gestionan por separado:

El aviso serio: un plugin de logging que se bloquea puede impedir que los contenedores arranquen, porque el daemon espera a que acepte el flujo. Antes de ponerlo en producción, pruébalo con el destino caído a propósito y comprueba que mode: non-blocking está configurado.

Las extensiones de Docker Desktop son contenedores con interfaz que se integran en el panel. Cómodas y con la misma precaución que cualquier código de terceros con acceso al socket del daemon: si controla el socket, controla el host (05-03).

Con la pila de Aurora Libros arriba, lazydocker te da en una pantalla los cuatro contenedores, sus logs en vivo y su consumo, y permite reiniciar aurora-api con una tecla. Para depurar en local es más rápido que cualquier GUI.

Portainer solo se justifica cuando hay varias personas operando varios hosts y hacen falta permisos por usuario. Para un servidor y un equipo pequeño con Compose, Dockge es más ligero y no esconde el YAML: sigues teniendo tus ficheros y los editas desde el navegador.

Precaución común a todas: exponen el socket de Docker. Portainer o Dockge accesibles desde Internet sin autenticación fuerte equivalen a regalar el host.

Ese 98 % es el resultado del trabajo de 05-04: la multietapa dejó fuera las dependencias de compilación y no hay ficheros duplicados entre capas. dive en modo integración devuelve código de salida distinto de cero si el proyecto baja del umbral, y eso encaja directo en el pipeline:

Sobre slim: adelgaza automáticamente ejecutando la aplicación y quedándose solo con lo que tocó. Puede llevar una imagen de 400 MB a 30 MB, y también puede romperla de forma silenciosa el día que se ejecute una ruta de código que no se probó durante el análisis. Úsalo con una batería de pruebas completa detrás, y prefiere siempre arreglar el Dockerfile si tienes acceso a él.

hadolint es el más barato de adoptar y el que más problemas evita, porque actúa antes de construir nada. Sobre una versión temprana del Dockerfile de la API:

Seis avisos que son exactamente el temario de los módulos 2 y 5: fijar la base, limpiar cachés de paquetes, fijar versiones, COPY en vez de ADD, no terminar como root y entrecomillar variables en RUN. Sobre el Dockerfile actual de aurora-api:2.0.0 no sale ninguno, porque la base está fijada por digest y el USER final no es root. Integrarlo cuesta cuatro líneas:

Falco es el que cubre el hueco que nadie más cubre: los demás analizan artefactos parados; Falco vigila syscalls en vivo y alerta cuando un contenedor hace algo que no debería —abrir una shell dentro de aurora-api, escribir en /etc, conectarse a una IP desconocida—. Es la última línea cuando la vulnerabilidad no estaba en ninguna base de datos.

Sobre las tres primeras de la tabla: no hace falta elegir una sola. Trivy en el pipeline como puerta que falla el build, Scout en el escritorio para la comprobación temprana, y Grype como segunda opinión cuando un resultado sorprende. Cada escáner usa fuentes distintas y no coinciden siempre.

Un uso que compensa casi siempre y casi nadie aplica: un espejo de Docker Hub en la red local. Ahorra ancho de banda, esquiva los límites de descarga y mantiene el pipeline funcionando cuando Hub tiene una mala tarde.

Harbor solo se justifica cuando hay varios equipos, políticas de retención, replicación entre regiones y necesidad de auditoría. Es una plataforma con base de datos, Redis y varios componentes: alguien tiene que mantenerla.

Testcontainers es la que más cambia la vida y la que menos se conoce. En 06-02 montaste servicios de PostgreSQL y Redis en el workflow de CI; Testcontainers hace que el propio test los levante, con lo que las pruebas se ejecutan igual en tu portátil y en el pipeline sin configuración duplicada:

El segundo test es el que justifica la herramienta: comprobar que el cache-aside devuelve origen: cache exige un Redis de verdad. Con un doble de prueba habrías validado tu propio simulacro, no el comportamiento real. Testcontainers necesita un daemon accesible; en CI ya lo tienes, y funciona igual contra Podman con el socket compatible (07-05).

Tilt y Skaffold resuelven otro problema: cuando desarrollas contra un clúster, el ciclo build-push-deploy son minutos. Ambos lo reducen a segundos sincronizando ficheros dentro del Pod. Solo compensan si tu bucle interno es Kubernetes; si desarrollas con docker compose watch (04-07), no los necesitas.

Ahí está el compromiso en una línea. Buildpacks te ahorra escribir y mantener el Dockerfile, y a cambio produce una imagen cuatro veces mayor. ¿Cuándo compensa?

Para Aurora Libros, con una imagen bien optimizada, multiarquitectura y firmada, no compensa. Para una plataforma interna con cuarenta microservicios, probablemente sí.

El disco se llena solo. Automatízalo antes de que te despierte una alerta:

El filtro until es la diferencia entre una limpieza segura y un pull completo la mañana siguiente. Y la línea del comentario es la más importante del script.

netshoot es una imagen con todas las herramientas de red que tus imágenes de producción, correctamente, no llevan: dig, curl, tcpdump, ss, iperf3, nmap.

La segunda forma es la potente: --network container: comparte el namespace de red de aurora-api (05-07), así que ves exactamente sus conexiones y sus puertos sin instalar nada dentro ni modificar la imagen. Es lo mismo que hace docker debug, con una imagen pública y sin suscripción.

dockviz dibuja el árbol de imágenes y contenedores; útil para entender un host heredado con cuarenta imágenes de origen desconocido.

Dos reglas de oro. Primera: cuanto más cerca del pipeline, más exigente. Una TUI local que se abandone se sustituye en cinco minutos; un plugin que firma tus imágenes y deja de recibir parches es un problema de seguridad y de despliegue a la vez. Segunda: valida con el responsable de seguridad cualquier herramienta que entre en la cadena de construcción o que necesite el socket del daemon, y comprueba su licencia con quien corresponda antes de integrarla en un producto comercial. Añadir una dependencia al pipeline es una decisión de arquitectura, no una preferencia personal.

Si solo pudieras adoptar tres para el resto de tu carrera: hadolint (evita errores antes de construir), Trivy (impide publicar algo vulnerable) y Testcontainers (hace que tus pruebas signifiquen algo). Las tres son de código abierto, están mantenidas y no atan a nadie.

• Exponer Portainer o Dockge a Internet. Controlan el socket del daemon: quien entra es root en el host. VPN o red interna, siempre, y con autenticación fuerte.
• Instalar un plugin de logging sin probar el fallo del destino. Si el destino no responde y el modo es bloqueante, los contenedores no arrancan. Prueba con Loki caído a propósito.
• Confiar solo en slim. Adelgaza observando una ejecución; lo que no se ejecutó, desaparece. Sin una batería de pruebas completa detrás, es una bomba de relojería.
• Acumular tres escáneres que dicen lo mismo. Uno como puerta del pipeline, otro como segunda opinión puntual. Más solo genera ruido que nadie lee.
• Añadir --volumes a la limpieza programada. Es la forma más rápida de perder aurora-datos un domingo por la noche.
• Adoptar una herramienta porque salió en una conferencia. Aplica la tabla de §12 antes: mantenimiento, licencia, criticidad y coste de salida.
• Consejo: mete hadolint en el pipeline hoy mismo. Cuesta cuatro líneas y evita media docena de malas prácticas por Dockerfile.
• Consejo: guarda el plugin docker aurora en el repositorio. Los atajos del equipo dejan de vivir en el historial de bash de cada uno.
• Consejo: aprende netshoot con --network container:. Resuelve el 90 % de las depuraciones de red sin tocar la imagen.

Ejercicio 1 — Amplía docker aurora. Parte del plugin de §2 y añádele tres subcomandos: escanear, que ejecute Trivy sobre la imagen local de la API y falle si hay vulnerabilidades críticas; pesar, que muestre el tamaño de la imagen y ejecute dive --ci con un umbral de eficiencia del 95 %; y red, que lance netshoot en el namespace de red de aurora-api y compruebe que resuelve aurora-db y alcanza aurora-cache. El plugin debe seguir funcionando sin instalar nada más que Docker.

Ejercicio 2 — Lint y corrección de un Dockerfile. Escribe a propósito un Dockerfile malo para aurora-api (base sin etiqueta, apt-get sin limpiar, ADD en lugar de COPY, npm install sin versión fijada, sin USER), pásale hadolint y anota cada código de aviso. Corrígelos uno a uno hasta que el lint quede limpio, explicando en un comentario qué problema real evita cada corrección. Añade después la comprobación al pipeline con umbral warning.

Ejercicio 3 — Evaluación de adopción. Un compañero propone añadir al pipeline una herramienta que optimiza automáticamente las imágenes antes de publicarlas. La publica un desarrollador individual en Docker Hub, tiene 900 estrellas en GitHub, el último commit es de hace once meses y la imagen no está firmada. Aplica la tabla de criterios de §12 y escribe una respuesta razonada: tu recomendación, los tres riesgos concretos que identificas, y qué condiciones tendrían que cumplirse para que la aceptaras.

Solución 1.

Tres decisiones importan más que el resto. El montaje del socket es imprescindible porque tanto Trivy como dive inspeccionan imágenes locales del daemon, no remotas; montar ~/.cache/trivy evita descargar la base de vulnerabilidades entera en cada ejecución, que es lo que hace que la primera vez tarde un minuto y las siguientes tres segundos. El --exit-code 1 convierte el escaneo en una puerta: sin él, Trivy informa y devuelve 0, y el pipeline pasaría con vulnerabilidades críticas. Y --ignore-unfixed evita el ruido de fallos que aún no tienen parche disponible, que no puedes accionar. En red, --network container:aurora-api entra en el namespace de red del contenedor real (05-07), de modo que lo que ves es su resolución DNS y sus conexiones, no las de una red cualquiera.

Solución 2. Dockerfile malo y los códigos que dispara:

Versión corregida:

El aviso que más se subestima es DL3025: con CMD npm start, PID 1 es un shell que no propaga SIGTERM, y todo el apagado ordenado que montaste en 06-01 deja de funcionar sin que ningún test lo detecte. Se manifiesta como peticiones cortadas durante los despliegues, y cuesta días encontrarlo si no sabes dónde mirar.

Solución 3. Recomendación: no adoptarla en el pipeline en su estado actual.

Los tres riesgos concretos: (1) cadena de suministro —una imagen sin firmar de un autor anónimo, ejecutándose en CI con acceso a tus imágenes y probablemente al socket, es exactamente el vector que Cosign y las attestations de 06-02 vinieron a cerrar—; (2) rotura silenciosa, porque una optimización automática puede eliminar un fichero que solo se usa en una ruta poco frecuente, y lo descubrirías en producción; (3) abandono, ya que once meses sin commits en una herramienta que toca el artefacto final significa que el día que rompa con una versión nueva de BuildKit, el despliegue se para y el arreglo es tuyo.

Condiciones para aceptarla: que se ejecute fuera de la ruta crítica, como informe comparativo y no como paso que modifica la imagen publicada; que la imagen esté firmada y fijada por digest; que exista una batería de pruebas de integración que valide la imagen optimizada antes de publicarla; y que el responsable de seguridad valide la licencia y la procedencia. Contrapropuesta razonable: el objetivo del compañero —imágenes más pequeñas— ya está cubierto por la multietapa y dive --ci con umbral, que son parte del pipeline, no dependen de terceros y ya dan un 98 % de eficiencia sobre aurora-api:2.0.0. La conversación no es «no», es «este problema ya está resuelto».

Ya tienes el equipamiento que rodea a Docker, y más importante, el criterio para elegirlo. Entiendes los tres niveles de extensibilidad y su asimetría de riesgo: en la CLI experimenta libremente, en el daemon sé conservador, porque un plugin de logging bloqueado impide arrancar contenedores. Y has construido tu propio docker aurora con cuarenta líneas de bash, descubriendo que el mecanismo de docker compose y docker buildx es simplemente un ejecutable en el PATH que responde a docker-cli-plugin-metadata.

Del recorrido por categorías te llevas selección, no catálogo: lazydocker y ctop para ver la flota sin teclear, Portainer solo cuando hay varias personas y varios hosts, Dockge cuando lo que gestionas son pilas de Compose; dive confirmando el 98 % de eficiencia que ganaste en 05-04 y sirviendo de puerta en CI con --ci --lowestEfficiency, container-diff para auditar qué cambió entre versiones y slim con su advertencia seria; hadolint señalando en seis avisos todo el temario de los módulos 2 y 5 —incluido el DL3025 que rompe el apagado ordenado sin que ningún test lo note—, Trivy como puerta, Scout como comprobación temprana y Falco vigilando syscalls cuando la vulnerabilidad no estaba en ninguna base de datos; el espejo de Docker Hub con registry:2 que casi nadie monta y casi siempre compensa; Testcontainers levantando PostgreSQL y Redis desde el propio test para comprobar que el cache-aside devuelve origen: cache de verdad; Buildpacks con su compromiso medido —412 MB frente a tus 104— y la tabla de cuándo compensa no escribir un Dockerfile; la limpieza programada con until y sin --volumes; y netshoot con --network container: entrando en el namespace de red de aurora-api sin tocar la imagen.

Y te llevas los criterios de adopción, que valen más que cualquier lista de herramientas: mantenimiento activo, licencia compatible, procedencia verificable, criticidad en el pipeline, comprensión real del equipo, coste de salida y superficie de ataque añadida. Con las dos reglas de oro: cuanto más cerca del pipeline, más exigente, y valida con el responsable de seguridad —y con quien lleve las licencias— cualquier herramienta que entre en la cadena de construcción o pida el socket del daemon. Si tuvieras que quedarte con tres para el resto de tu carrera: hadolint, Trivy y Testcontainers.

En la lección siguiente damos un paso atrás fundamental: Podman, containerd y el estándar OCI. Vas a descubrir por qué las imágenes que llevas construyendo todo el curso no son «de Docker», qué normaliza exactamente la Open Container Initiative, y cómo ghcr.io/auroralibros/aurora-api:2.0.0 se ejecuta igual en Podman, en containerd o en un nodo de Kubernetes sin cambiar un solo byte.