Ya sabes qué es Docker, lo tienes instalado y entiendes su arquitectura. Toca aprender a hablar con él. La buena noticia es que la CLI de Docker no es una colección arbitraria de comandos que haya que memorizar: está organizada siguiendo exactamente los cuatro tipos de objeto que viste en la lección anterior, con una gramática regular y predecible. Si entiendes esa gramática, deduces la mayoría de los comandos sin consultarlos. En esta lección verás la anatomía de la CLI moderna y sus alias históricos, el sistema de ayuda integrado (que es tu mejor referencia y siempre está actualizado), los comandos esenciales sobre imágenes, contenedores y sistema, una sesión completa comentada de principio a fin, y cómo domar la salida con --format y --filter para que te dé exactamente lo que necesitas.

1. La anatomía de la CLI moderna
2. Alias cortos: la sintaxis histórica
3. El sistema de ayuda
4. Comandos esenciales sobre imágenes
5. Comandos esenciales sobre contenedores
6. Comandos de sistema
7. Una sesión completa comentada
8. Formatear la salida con --format
9. Filtrar la salida con --filter

La CLI moderna de Docker sigue una estructura de tres piezas:

• objeto: sobre qué tipo de cosa actúas. Son los del daemon: image, container, volume, network, más algunos de gestión (system, context, builder).
• acción: qué le haces. El vocabulario se repite entre objetos: ls, rm, inspect, prune, create.
• opciones y argumentos: modificadores y el objeto concreto.

Ejemplos que ilustran la regularidad:

Los cuatro listan; solo cambia el tipo. Y lo mismo con borrar:

Esta tabla de acciones comunes vale para casi todos los objetos:

La conclusión práctica: no memorices comandos, memoriza la gramática. Si necesitas listar volúmenes y nunca lo has hecho, docker volume ls es la apuesta obvia y es correcta.

Antes de la reorganización por objetos, los comandos eran planos: docker ps, docker images, docker rmi. Docker los mantuvo por compatibilidad, y en la práctica todo el mundo los sigue usando porque se escriben menos. Verás las dos formas constantemente, en documentación y en el trabajo real.

Un par de advertencias sobre la tabla:

• docker rm y docker rmi se parecen peligrosamente. rm borra contenedores; rmi borra imágenes. Una letra de diferencia y consecuencias muy distintas.
• docker inspect sin objeto es ambiguo: busca primero un contenedor con ese nombre o ID y, si no lo encuentra, una imagen. Cuando quieras certeza, usa la forma larga.
• docker build frente a docker buildx build: en versiones actuales, docker build ya usa BuildKit por debajo. La forma explícita docker buildx build es la recomendada en 2026 y la que usaremos a partir del módulo 2.

Recomendación para este curso: entiende la forma larga, usa la corta. Escribir docker ps es perfectamente profesional; lo que no es profesional es no saber que equivale a docker container ls.

La CLI de Docker documenta cada comando y opción. Esta ayuda está siempre sincronizada con tu versión instalada, algo que ninguna web garantiza.

Muestra los grupos de comandos por objeto (Management Commands) y los comandos sueltos (Commands), que son los alias del apartado anterior.

Lista todas las acciones disponibles sobre contenedores: attach, commit, cp, create, diff, exec, export, inspect, kill, logs, ls, pause, port, prune, rename, restart, rm, run, start, stats, stop, top, unpause, update, wait.

Aquí está el detalle de cada opción. Es una salida larguísima —run tiene decenas de opciones— y por eso conviene filtrarla:

Qué hace este comando: encadena la ayuda a grep -i (búsqueda ignorando mayúsculas) para quedarte con las líneas que mencionan "publish". Es la forma más rápida de recordar una opción cuya letra has olvidado.

Dos comandos más de referencia:

Ya los conoces; docker system info es simplemente la forma larga de docker info, y confirma que info también encaja en la gramática objeto-acción.

Veámoslos en acción:

Ya sabes leer esto de la lección 01-02: una capa descargada, el digest que identifica la imagen de forma inmutable, y en la última línea el nombre completo que Docker ha resuelto (docker.io/library/alpine:3.20), confirmando lo que viste sobre registros por defecto.

Columna a columna:

• REPOSITORY: el nombre del repositorio de la imagen.
• TAG: la etiqueta, la "versión". latest es solo un nombre de etiqueta más (lección 01-05).
• IMAGE ID: identificador corto (los primeros 12 caracteres del digest). Es lo que usarás para referirte a la imagen cuando no tenga nombre.
• CREATED: cuándo se construyó la imagen, no cuándo la descargaste. Que hello-world diga "9 months ago" es normal.
• SIZE: tamaño descomprimido. Ojo: estos tamaños no se suman directamente si las imágenes comparten capas, algo que verás con detalle en la lección 01-05.

Fíjate en la diferencia entre las líneas: Untagged significa que se ha quitado un nombre que apuntaba a la imagen; Deleted significa que las capas se han borrado de verdad del disco. Si otra imagen o un contenedor siguiera usando esas capas, solo verías Untagged.

Un error muy habitual aparece si un contenedor (aunque esté parado) usa la imagen:

La lectura es literal: hay un contenedor usando esa imagen. Borra primero el contenedor.

La gestión avanzada de imágenes (etiquetado, exportación, limpieza fina) se trata en la lección 02-05.

El punto conceptual más importante de este apartado:

docker run crea un contenedor NUEVO cada vez. No reutiliza el anterior. Para volver a arrancar uno existente se usa docker start.

Esa confusión es la causa número uno de que a los principiantes se les acumulen decenas de contenedores parados.

Cada columna:

• CONTAINER ID: identificador corto. Puedes usar un prefijo único (3f2a bastaría).
• IMAGE: de qué imagen nació.
• COMMAND: el proceso principal que ejecuta, truncado.
• STATUS: el dato clave. Up 2 minutes = en ejecución. Exited (0) = terminó, y ese 0 es el código de salida: 0 significa que terminó bien; cualquier otro número indica error (Exited (137) suele ser muerte por falta de memoria o kill).
• PORTS: mapeos de puertos activos. 0.0.0.0:8080->80/tcp se lee "el puerto 8080 de cualquier interfaz del host va al 80 del contenedor".
• NAMES: el nombre. Si no lo pones tú con --name, Docker inventa uno gracioso (nervous_hopper).

Sobre parar contenedores, conviene conocer la diferencia:

• stop envía SIGTERM al proceso principal y espera 10 segundos a que termine ordenadamente; si no lo hace, entonces sí lo mata con SIGKILL. Es la forma correcta.
• kill envía SIGKILL directamente: muerte inmediata, sin oportunidad de cerrar conexiones ni guardar nada.

Usa siempre stop salvo que el contenedor esté colgado. El ciclo de vida completo con todos sus estados se estudia en la lección 03-02, y las opciones de docker run en profundidad en la 03-01.

prune merece cuidado, porque es destructivo:

Lee siempre la lista antes de escribir y. Notas importantes:

• La versión sin -a es razonablemente segura: borra contenedores parados (que quizá querías conservar, pero rara vez importan) e imágenes dangling, es decir, sin etiqueta, que suelen ser restos de construcciones anteriores.
• La versión con -a es agresiva: borra todas las imágenes no usadas. Después tendrás que volver a descargarlo todo. En un portátil es un buen recurso cuando falta disco; en un servidor de producción, piénsatelo dos veces.
• --volumes es el más peligroso: los volúmenes contienen datos. Borrar el volumen de la base de datos de Aurora Libros por error significa perder el catálogo.

Puedes evitar la pregunta con -f, pero justamente en este comando la confirmación es tu red de seguridad.

Vamos a recorrer una sesión de principio a fin, empezando y terminando con el sistema limpio. Ejecútala tú también.

Paso 1. Punto de partida.

Si acabas de instalar Docker, verás solo las cabeceras de las tablas, sin filas. Si hiciste el hello-world de la lección 01-02, tendrás esa imagen y uno o dos contenedores parados.

Paso 2. Un contenedor que hace una cosa y muere.

Ya conoces la salida. Lo interesante viene ahora:

Vacío. El contenedor imprimió su mensaje y su proceso terminó, así que ya no está en ejecución. Pero:

Ahí sigue, parado, ocupando espacio. Esta es la lección más importante de la sesión: un contenedor que termina no desaparece.

Paso 3. Descargar una imagen y ejecutar un comando concreto.

Qué ha ocurrido: Docker creó un contenedor a partir de alpine:3.20, sustituyó el comando por defecto de la imagen por echo "Hola desde Aurora Libros", lo ejecutó, y al terminar el proceso el contenedor pasó a Exited (0). Todo lo que va después del nombre de la imagen es el comando a ejecutar dentro.

Paso 4. Varios contenedores de la misma imagen.

Dos observaciones valiosísimas:

• uname -a muestra el kernel del anfitrión (6.8.0-52-generic, un kernel de Ubuntu). Confirma con tus propios ojos lo de la lección 01-01: el contenedor comparte el kernel del host.
• cat /etc/os-release dice "Alpine Linux". Es decir: kernel de Ubuntu, espacio de usuario de Alpine. Eso es un contenedor.

Y ahora:

Cuatro contenedores parados de tres docker run con Alpine más el hello-world. Cada run creó uno nuevo. Ese --format que acabas de usar se explica en el apartado 8.

Paso 5. Ver los logs de un contenedor ya terminado.

Aunque el contenedor esté parado, su salida se conserva. Es una herramienta de diagnóstico fundamental: si un contenedor muere al arrancar, docker logs te dice por qué.

Paso 6. Limpiar.

rm acepta varios nombres o IDs y devuelve los que ha borrado. Para borrarlos todos de golpe:

container prune elimina todos los contenedores parados; -f salta la confirmación (aquí es seguro porque ya sabes lo que hay). Comprueba:

Tabla vacía. Las imágenes, en cambio, siguen ahí:

Borrar contenedores no borra imágenes. Una vez más: imagen y contenedor son objetos distintos.

Las tablas por defecto son anchas y traen columnas que a menudo no te interesan. --format acepta plantillas del lenguaje Go para que elijas tú.

Modo tabla, manteniendo cabeceras:

La palabra table al principio activa el formato tabular con cabeceras; {{.Campo}} inserta un campo; \t separa columnas.

Modo línea libre, sin cabeceras, ideal para scripts:

Modo JSON, para procesar con otras herramientas:

Campos disponibles más útiles:

Un ejemplo práctico que usarás mucho: obtener solo los IDs para pasárselos a otro comando.

-a (todos) combinado con -q (quiet, solo IDs). Y su uso típico:

Cómo funciona: $(...) ejecuta primero el comando interior y sustituye su salida como argumentos del exterior. El resultado es "borra todos los contenedores parados". Cuidado: si algún contenedor está en ejecución, rm se quejará de ese en concreto y borrará el resto. Y si la lista está vacía, docker rm protestará por falta de argumentos, lo cual es inofensivo.

Mientras --format decide qué columnas ves, --filter (o -f) decide qué filas.

Filtros de contenedores más útiles:

Qué hace cada uno:

• status=exited: solo los terminados. Otros valores: running, paused, created, restarting, dead.
• name=aurora: los que contengan "aurora" en el nombre (es subcadena, no coincidencia exacta). Muy útil con la convención de nombres de Aurora Libros.
• ancestor=alpine:3.20: los creados a partir de esa imagen.
• exited=1: los que terminaron con código de salida 1, es decir, los que fallaron. Oro puro para diagnosticar.

Filtros de imágenes:

• dangling=true: imágenes sin etiqueta, restos de construcciones. Son las que borra docker image prune.
• reference=alpine:*: las que casan con ese patrón de nombre.
• before=nginx:alpine: las creadas antes que esa imagen.

Y ahora la combinación de todo, que es donde la CLI brilla:

Traducción: "muéstrame en una tabla con nombre, imagen y estado todos los contenedores que hayan terminado con error". Dos filtros se combinan con Y lógico.

Otro ejemplo orientado a nuestro proyecto:

"Borra todos los contenedores parados cuyo nombre contenga aurora", sin tocar el resto de tu sistema. Cuando en los próximos módulos tengas aurora-api, aurora-db, aurora-cache y aurora-web conviviendo con otros experimentos, este patrón te ahorrará disgustos.

• Usar docker run para reanudar un contenedor. run siempre crea uno nuevo. Para reanudar, docker start <nombre>. Si te encuentras con 30 contenedores parados idénticos, esta es la causa.
• Confundir docker rm con docker rmi. El primero borra contenedores, el segundo imágenes. Si dudas, usa las formas largas docker container rm y docker image rm.
• Ejecutar docker system prune -a --volumes sin leer el aviso. Puedes borrar los datos de una base de datos de desarrollo en un segundo. Lee siempre la lista de lo que va a eliminar.
• Creer que los contenedores parados no ocupan. Ocupan: su capa de escritura, sus logs y sus metadatos. Míralo con docker system df.
• Olvidar -a en docker ps. "No tengo contenedores" suele significar "no tengo contenedores en ejecución". Ante la duda, docker ps -a.
• Consejo: nombra siempre tus contenedores con --name. Los nombres aleatorios son imposibles de recordar. Con la convención aurora-api, aurora-db, etc., los filtros por nombre funcionan solos.
• Consejo: usa prefijos de ID. No hace falta el ID completo: basta con los primeros caracteres si son únicos. docker stop 3f2a funciona.
• Consejo: --help antes que Google. La ayuda integrada corresponde exactamente a tu versión; los blogs, a menudo no.

Reescribe estos comandos en la forma moderna docker <objeto> <acción> y explica qué hace cada uno:

Después, responde: ¿qué hace exactamente la opción -f en los dos últimos comandos? ¿Significa lo mismo?

Prepara el escenario ejecutando:

Ahora, usando --filter y --format:

1. Lista en una tabla (nombre, imagen, estado) solo los contenedores cuyo nombre contenga aurora.
2. Averigua cuál de ellos terminó con error, sin leer estado a estado.
3. Borra en un único comando solo los contenedores parados cuyo nombre contenga aurora, dejando otra-cosa intacto.
4. Comprueba que otra-cosa sigue ahí y que las imágenes no se han tocado.

Responde con comandos, no de memoria:

1. ¿Cuánto espacio total ocupan tus imágenes y cuánto podrías recuperar?
2. ¿Qué imagen concreta es la más grande que tienes?
3. Si ejecutaras docker system prune (sin -a), ¿qué se borraría exactamente en tu sistema ahora mismo? Averígualo antes de ejecutarlo.

Solución al ejercicio 1

Sobre -f: no significa lo mismo en los dos casos, y es una fuente clásica de confusión.

• En docker logs -f, -f es --follow: no cierra la salida, se queda escuchando y muestra las nuevas líneas según aparecen (como tail -f). Se sale con Ctrl+C, lo cual no afecta al contenedor.
• En docker rm -f, -f es --force: mata el contenedor si está en ejecución y luego lo elimina. Sin -f, docker rm sobre un contenedor activo devuelve un error pidiéndote que lo pares primero.

Moraleja: las letras de opción se reutilizan con significados distintos según el comando. Ante la duda, --help.

Solución al ejercicio 2

(El filtro name=aurora es por subcadena, así que solo aparecen aurora-prueba-1 y aurora-prueba-2.)

El filtro exited=1 selecciona por código de salida. aurora-prueba-2 ejecutaba sh -c "exit 1", que termina con código 1, de ahí que sea el único que aparece. Es mucho más rápido que leer la columna STATUS de una lista larga.

Desglose: el comando interior docker ps -aq --filter ... --filter ... devuelve solo los IDs (-q) de los contenedores parados cuyo nombre contiene "aurora". La sustitución $(...) los pasa como argumentos a docker rm. Como otra-cosa no casa con el filtro de nombre, no entra en la lista y sobrevive.

Verás únicamente otra-cosa en la lista de contenedores, y alpine:3.20 intacta en las imágenes. Borrar contenedores nunca borra imágenes.

Solución al ejercicio 3

Lee la fila Images: la columna SIZE es el total ocupado y RECLAIMABLE lo que liberarías eliminando las imágenes que ningún contenedor usa. El porcentaje entre paréntesis te da la proporción de un vistazo.

--format produce una línea por imagen con tamaño y nombre; sort -h -r ordena por tamaño legible por humanos (-h entiende "MB", "GB") de mayor a menor (-r); head -5 se queda con las cinco primeras. La primera línea es tu imagen más grande.

Razonamiento: docker system prune sin -a elimina cuatro cosas, así que las inspeccionas por separado antes: los contenedores parados (primer comando), las imágenes colgadas sin etiqueta (segundo), las redes no usadas por ningún contenedor (tercero; las redes por defecto bridge, host y none nunca se borran) y la caché de construcción (cuarto, que muestra cuánto ocupa). Con esa foto previa sabes exactamente qué vas a perder antes de confirmar con y.

La CLI de Docker no se memoriza, se deduce: docker <objeto> <acción> [opciones], donde los objetos son los que gestiona el daemon (image, container, volume, network, system) y las acciones se repiten entre ellos (ls, rm, inspect, prune). Los alias históricos —docker ps, docker images, docker rmi— siguen siendo la forma habitual de escribirlos, y ahora sabes a qué corresponden.

Te llevas los comandos esenciales sobre imágenes (pull, images, rmi), sobre contenedores (run, ps, ps -a, stop, start, rm, logs) y de sistema (info, system df, system prune), y dos ideas que evitarán la mitad de tus tropiezos futuros: docker run crea siempre un contenedor nuevo, y un contenedor que termina no desaparece. Además, con --format y --filter puedes pedirle a Docker exactamente las filas y columnas que necesitas, algo que resulta imprescindible en cuanto tienes más de tres o cuatro objetos entre manos.

En la sesión práctica has visto algo revelador: un contenedor de Alpine mostrando el kernel de Ubuntu del anfitrión. Ese sistema de archivos de Alpine, empaquetado y descargado en segundos, es una imagen, y todavía no sabes realmente qué hay dentro. En la siguiente lección, Entendiendo las Imágenes de Docker, abrirás esa caja: capas, copy-on-write, digests, etiquetas, imágenes base, y por qué latest no significa lo que crees.