Ahora mismo tienes tres o cuatro contenedores en tu máquina y todavía puedes llevarlos en la cabeza. Dentro de un mes tendrás treinta: los cuatro servicios de Aurora Libros, media docena de pruebas olvidadas, contenedores de otros proyectos y un montón de Exited de hace semanas ocupando disco y nombres. Sin herramientas de gestión, ese docker ps -a se convierte en una pared de texto imposible de leer, y el docker rm masivo que ejecutas a las once de la noche se lleva por delante algo que necesitabas.

Esta lección es la de la operación diaria. Vas a exprimir docker ps hasta el fondo —columna por columna, con sus filtros y sus plantillas—, vas a montar un panel de control de los cuatro servicios de Aurora Libros, vas a aprender a componer comandos con -q para operar sobre decenas de contenedores sin destrozar nada, a copiar ficheros entre el host y un contenedor con docker cp —con lo que por fin llenarás la tabla libros con los ocho títulos—, a ver con docker diff qué ha cambiado un contenedor respecto a su imagen, y a entender por qué docker commit es una tentación que hay que resistir.

1. docker ps: las siete columnas, una a una
2. Opciones de listado: -a, -q, -s, -n, -l
3. Filtrar con --filter
4. Dar formato con --format y plantillas Go
5. Etiquetas: organizar la flota con --label
6. Componer comandos con -q (y hacerlo con cabeza)
7. Borrar contenedores: rm, -f, -v y container prune
8. Renombrar y modificar en caliente: rename y update
9. docker cp: mover ficheros en los dos sentidos
10. docker diff: qué ha cambiado respecto a la imagen
11. docker commit y por qué no debes usarlo
12. El panel de control de Aurora Libros

Dos observaciones sobre la salida de arriba, que sirven de repaso:

• aurora-cache pone Up 4 minutes y no Up 32 minutes porque lo reiniciaste en la lección anterior: el contador de STATUS se pone a cero con cada arranque, mientras que CREATED no se mueve.
• El (healthy) de aurora-cache no aparece por arte de magia: la imagen oficial de Redis 7 trae su propio HEALTHCHECK. aurora-db no muestra nada porque la imagen de PostgreSQL no lo define. La salud se estudia a fondo en la lección 03-04.

Para ver el comando completo:

Esta columna tiene dos números y la diferencia entre ambos es la lección 01-05 hecha comando:

• El primero (0B, 127kB) es la capa de escritura: lo que ese contenedor ha escrito por encima de la imagen. Es lo único que le pertenece en exclusiva y lo único que se pierde al borrarlo.
• El virtual es el tamaño total que ve el contenedor: su capa de escritura más todas las capas de la imagen, que son compartidas y de solo lectura.

Diez contenedores de redis:7-alpine no ocupan 412 MB, sino 41,2 MB más diez capas de escritura minúsculas. Y aurora-db con sus 127 kB de escritura llama la atención: acabas de crear una base de datos entera, ¿dónde están los datos? En un volumen anónimo que la imagen oficial declara, y que no cuenta como capa de escritura. Sujeta esa pregunta: es el corazón de la lección 03-06.

--filter (o -f) acepta pares clave=valor y se puede repetir. Los filtros disponibles:

Recetas listas para copiar:

Ejemplo real:

Dos avisos sobre el comportamiento de los filtros:

• Varios --filter distintos se combinan con Y lógico. --filter status=running --filter name=aurora exige las dos condiciones.
• Varios valores del mismo filtro se combinan con O lógico. --filter status=exited --filter status=created devuelve los de cualquiera de los dos estados.
• name es una subcadena, no una igualdad. --filter name=aurora-db también encuentra aurora-db-copia. Si necesitas exactitud, usa una expresión anclada: --filter name=^aurora-db$.

--format usa plantillas del lenguaje Go, las mismas que ya empleaste con docker image ls en la lección 02-05.

La palabra table al principio activa la cabecera y la alineación en columnas:

Sin table, la salida es texto libre, perfecta para guionizar:

Y hay dos formatos preconstruidos muy socorridos:

Si un formato te gusta, hazlo permanente en ~/.docker/config.json:

A partir de ese momento, un docker ps a secas usa tu formato. Es uno de los ajustes que más agradece el uso diario.

Cuando en la misma máquina conviven contenedores de tres proyectos, filtrar por nombre deja de ser fiable. Las etiquetas son metadatos arbitrarios que asignas al crear el contenedor:

Y después filtras por ellas con precisión quirúrgica:

--filter label=clave=valor exige el valor exacto; --filter label=clave solo exige que la etiqueta exista.

Vamos a etiquetar de verdad la flota de Aurora Libros. Como las etiquetas, igual que los puertos y las variables, se fijan al crear el contenedor y no se pueden añadir después (lección 03-01), hay que recrear. No pasa nada: aurora-db todavía no tiene datos que perder.

Una convención de etiquetas que funciona bien y que usaremos en todo el curso:

Con estas tres etiquetas, operaciones como "para todo lo de Aurora Libros en local sin tocar nada más" se vuelven triviales, y es exactamente lo que Docker Compose hará por ti automáticamente en el módulo 4: sus etiquetas com.docker.compose.project son este mismo mecanismo.

docker ps -q imprime solo IDs, y eso lo convierte en la entrada de cualquier otro comando:

Recetas que se usan a diario:

Y ahora las tres precauciones, porque estos comandos son afilados:

Primera: si el filtro no encuentra nada, el comando falla.

Molesto pero inofensivo. Se evita comprobando antes:

Segunda: docker rm -f $(docker ps -aq) es el comando más peligroso de esta lección. Borra absolutamente todos los contenedores de la máquina, incluidos los de otros proyectos, y sin preguntar. Si necesitas hacer limpieza, hazla acotada:

Tercera: mira antes de disparar. La regla de oro es ejecutar primero la versión que solo lista:

Ese medio segundo de más ha salvado muchas bases de datos de desarrollo.

docker rm solo funciona sobre contenedores parados. Con uno en marcha:

Sobre -f, un matiz importante que enlaza con la lección anterior: docker rm -f no es docker stop + docker rm. Envía SIGKILL directamente, sin los diez segundos de gracia. Sobre una base de datos, eso es desenchufar el servidor. La secuencia correcta cuando hay datos de por medio es:

Qué ocurre exactamente al borrar un contenedor:

Borra todos los contenedores parados. Vale la pena repetir el aviso de la lección 02-05: un contenedor parado puede ser algo que estabas depurando o una base de datos de desarrollo que apagaste ayer. Acota siempre que puedas:

Ya viste docker rename en la lección anterior. Su compañero es docker update, que sí puede cambiar cosas de un contenedor en marcha, aunque una lista muy concreta:

El detalle de todas esas opciones de recursos y de las políticas de reinicio es el contenido de la lección 03-07; aquí solo importa retener la frontera: update toca lo que vive en los cgroups; todo lo que vive en los namespaces (red, montajes, entorno) se fija al crear el contenedor.

Uno de los dos lados lleva el prefijo contenedor: y el otro es una ruta del host. Funciona en las dos direcciones y también con contenedores parados.

Ha llegado el momento de llenar la base de datos. Tienes ~/aurora-libros/db/init.sql desde la lección 01-07, con la tabla libros y los ocho títulos:

Y ahora ejecútalo dentro del contenedor:

Comprueba el resultado:

Los ocho libros de Aurora Libros están en una base de datos real, en un contenedor real. Es la primera vez en todo el curso que existen fuera de un fichero .sql. Todavía nadie los puede leer desde la API —eso llega en la lección 03-05—, pero ya están ahí.

Un apunte de método: cargar el esquema a mano con docker cp funciona pero no es la forma correcta, porque hay que repetirlo cada vez que recrees el contenedor y nadie se acuerda de hacerlo. En la lección 03-06 lo resolverás bien, montando init.sql en /docker-entrypoint-initdb.d/ para que PostgreSQL lo ejecute solo al inicializarse.

El sentido inverso es igual de fácil y resulta imprescindible al investigar un incidente:

Y un caso muy habitual: rescatar el log de una aplicación que —contra toda buena práctica— escribe en un fichero en vez de en la salida estándar.

Detalles del comportamiento de docker cp que evitan sorpresas:

Ese último punto muerde a menudo: si copias un fichero a un contenedor que corre con USER node, el fichero pertenecerá a root y la aplicación quizá no pueda leerlo. Y una limitación clara: docker cp no puede copiar de un contenedor a otro directamente; hay que pasar por el host.

docker diff compara el sistema de ficheros actual del contenedor con el de la imagen de la que salió:

Tres letras y su significado:

Es la manifestación visible del copy-on-write de la lección 01-05: lo que ves aquí es exactamente el contenido de la capa de escritura, y por eso docker diff y la columna SIZE de docker ps -s hablan de lo mismo.

Y ahora la observación importante:

Ni una línea. Acabas de crear una tabla y ocho registros, y el directorio de datos de PostgreSQL no aparece en el diff. La razón es que /var/lib/postgresql/data no está en la capa de escritura: la imagen oficial declara ahí un VOLUME, así que Docker creó un volumen anónimo y lo montó en esa ruta. Y docker diff nunca mira dentro de los montajes.

Esto es exactamente lo que anticipaba la lección 02-04 al hablar de por qué VOLUME en un Dockerfile tiene efectos secundarios, y es la puerta de entrada a la lección 03-06: hay datos que no viven ni en la imagen ni en la capa de escritura, sino en un tercer sitio. Un sitio que ahora mismo, para aurora-db, es anónimo y frágil.

Un caso de uso muy práctico de docker diff: descubrir qué escribe una aplicación de la que no te fías.

En diez líneas sabes que Nginx modifica su configuración al arrancar (lo hace su docker-entrypoint.sh), crea un fichero de PID y varios directorios de caché. Es información valiosísima cuando vas a hacer el sistema de ficheros de solo lectura por seguridad, algo que verás en la lección 05-03.

docker commit convierte el estado actual de un contenedor en una imagen nueva:

Funciona. Y precisamente por eso es peligroso. Estos son los motivos por los que no se construyen imágenes así, retomando todo el módulo 2:

En el vocabulario del oficio, una imagen así se llama imagen artesanal o snowflake, y es el equivalente contenedorizado de aquel servidor que nadie se atrevía a reiniciar. Tiene, eso sí, un uso legítimo:

Guardar la escena del crimen antes de limpiarla. Para eso sí, y para nada más.

Cerramos juntando todo lo de la lección en un comando que usarás a diario:

Conviértelo en un alias permanente en tu ~/.bashrc o ~/.zshrc:

Y una versión con salud y tamaño, para cuando algo va mal:

Fíjate en que la capa de escritura de aurora-db ha crecido de 127 kB a 3,14 kB… un momento, ha bajado. Lo que ocurre es que el contenedor es nuevo: lo recreaste al añadirle las etiquetas, y esos 3,14 kB son casi exclusivamente el init.sql que copiaste con docker cp. Los datos de los ocho libros no están ahí, sino en el volumen anónimo del que hablábamos. Un recordatorio más de que hay una pieza del rompecabezas que aún no has colocado.

• Ejecutar docker rm -f $(docker ps -aq) "para limpiar". Se lleva todo lo de la máquina, incluidos contenedores de otros proyectos y bases de datos de desarrollo con semanas de datos. Filtra siempre por label o por name.
• Confiar en --filter name= como si fuera una igualdad. Es una subcadena: name=aurora-db también encuentra aurora-db-backup. Ancla con ^...$ cuando importe.
• Leer la columna CREATED como "arrancado hace". Es la fecha de creación. Para el tiempo en marcha, mira STATUS o {{.RunningFor}}.
• Interpretar el tamaño virtual como espacio ocupado. Diez contenedores de la misma imagen comparten sus capas: el disco real es la suma de las capas de escritura más una copia de la imagen.
• Usar docker rm -f sobre una base de datos. Es un SIGKILL sin gracia. Primero docker stop --time 30, después docker rm.
• Olvidar -v al borrar y acumular volúmenes anónimos huérfanos. Cada contenedor de PostgreSQL borrado sin -v deja atrás su volumen. Se localizan con docker volume ls -f dangling=true (lección 03-06).
• Copiar ficheros con docker cp a un contenedor sin privilegios y no entender el permission denied. El fichero llega como root. Usa -a, o ajusta después con docker exec -u root ... chown.
• Construir imágenes con docker commit. Funciona hoy y te deja sin explicación mañana. El Dockerfile es la fuente de la verdad.
• Consejo: guarda tus formatos favoritos en ~/.docker/config.json con psFormat. Un docker ps legible por defecto es un regalo diario.
• Consejo: antes de cualquier operación masiva, ejecuta la versión que solo lista. Mira la lista, y solo entonces cambia ps por rm.

Crea cinco contenedores de prueba con alpine:3.20 y sleep 300, etiquetados así: dos con proyecto=aurora-libros y entorno=local, dos con proyecto=aurora-libros y entorno=pruebas, y uno con proyecto=otro-cliente. Después escribe un único comando docker ps que muestre solo los de Aurora Libros en entorno de pruebas, en una tabla con las columnas nombre, entorno y tiempo en marcha. Finalmente, para y borra en un solo comando exclusivamente los de otro-cliente, dejando el resto intacto, y demuestra con otro comando que los cuatro de Aurora Libros siguen vivos.

Arranca un contenedor de redis:7-alpine llamado diff-redis. Antes de tocar nada, ejecuta docker diff y anota el resultado. Después escribe 100 claves con redis-cli, fuerza un guardado en disco con redis-cli SAVE, y vuelve a ejecutar docker diff. Responde:

1. ¿Aparece el fichero de datos de Redis en el docker diff? ¿Y en la columna SIZE de docker ps -s?
2. Averigua con docker inspect --format '{{json .Mounts}}' dónde está realmente ese fichero.
3. Cópialo al host con docker cp y comprueba su tamaño con ls -lh.
4. Borra el contenedor con docker rm -f (sin -v) y explica qué ha pasado exactamente con esas 100 claves. ¿Se han perdido? ¿Dónde están?

Simula el final de una jornada de trabajo caótica:

1. Crea seis contenedores que terminen inmediatamente: tres con código 0 (alpine:3.20 true) y tres con código 1 (alpine:3.20 sh -c 'exit 1'), todos con la etiqueta proyecto=pruebas-limpieza.
2. Escribe un comando que liste solo los que fallaron, con su nombre y su estado.
3. De uno de los fallidos, extrae con docker cp el fichero /etc/os-release al host antes de borrarlo.
4. Borra en un solo comando solo los que fallaron, dejando los tres correctos.
5. Finalmente, limpia el resto con docker container prune acotado a la etiqueta, y verifica que ni aurora-db ni aurora-cache se han visto afectados.

Solución al ejercicio 1

El comando del panel, con dos filtros combinados con Y lógico:

Los de entorno=local no aparecen: cumplen el primer filtro pero no el segundo, y ambos deben cumplirse.

Borrado quirúrgico de otro-cliente:

Los cuatro de Aurora Libros siguen en pie. La secuencia mirar → actuar → comprobar es la que convierte un comando peligroso en una operación rutinaria.

Solución al ejercicio 2

Prácticamente nada: Redis recién arrancado solo escribe su fichero de PID. Ahora, carga y guardado:

1. Aquí está la sorpresa del ejercicio: dump.rdb existe (lo acabas de listar con ls -lh, 3,4 kB) pero no aparece en el docker diff, y la capa de escritura sigue midiendo 0 B. Las dos herramientas están de acuerdo entre sí y las dos dicen la verdad: ese fichero no está en la capa de escritura del contenedor.

2. La explicación está en los montajes:

La imagen oficial de Redis declara VOLUME /data, así que Docker creó un volumen anónimo —ese nombre que parece un hash es exactamente eso: un volumen sin nombre— y lo montó en /data. Todo lo que Redis escribe ahí va al volumen, no a la capa de escritura, y por eso docker diff no lo ve.

3.

docker cp sí lee a través de los montajes: para él, /data/dump.rdb es simplemente una ruta del sistema de ficheros del contenedor. Los 3,4 kB coinciden con el ls de dentro; los 5,63 kB que informa Docker son el tamaño del flujo tar con el que se hace la copia, con sus cabeceras y su relleno a bloques.

4.

La respuesta correcta es más interesante que un simple "se han perdido":

• Las claves que estaban en memoria murieron con el proceso, como en el ejercicio de la lección anterior.
• Pero el dump.rdb con las 100 claves sigue existiendo, en un volumen que ahora está huérfano: sin contenedor que lo use, con un nombre que nadie recuerda y ocupando disco indefinidamente. Como usaste docker rm -f sin -v, el volumen no se borró.
• Si mañana arrancas otro redis:7-alpine, Docker creará un volumen anónimo nuevo y vacío: no reutilizará el anterior. Desde el punto de vista práctico, los datos están perdidos aunque los bytes sigan en tu disco.

Eso es exactamente lo que le pasa hoy a aurora-db con los ocho libros que acabas de cargar, y es el problema que resuelve la lección 03-06 poniéndole al volumen un nombre.

Solución al ejercicio 3

2. Listar solo los que fallaron, combinando status y exited:

El filtro exited=1 es el que hace el trabajo fino: distingue "terminó" de "terminó mal", algo que status=exited por sí solo no puede.

3. Rescatar un fichero de un contenedor parado:

Detalle importante: docker cp funciona con el contenedor parado. No hace falta arrancarlo, y eso lo convierte en la herramienta ideal para hacer autopsias de contenedores que ya no levantan.

4. Borrado selectivo de los fallidos:

Los tres correctos siguen ahí. No hizo falta -f porque ya estaban parados.

5. Limpieza final acotada y verificación:

aurora-db y aurora-cache intactos, porque el --filter label= acotó el prune a la etiqueta correcta. Compara mentalmente con lo que habría pasado con un docker container prune -f a secas: los tres ok-* habrían caído igual, pero también cualquier contenedor parado de cualquier otro proyecto de tu máquina. Las etiquetas no son burocracia: son el mecanismo que hace que la limpieza sea selectiva en vez de indiscriminada.

Ya no miras docker ps: lo lees. Sabes qué dice cada una de sus siete columnas y, sobre todo, qué no dice —que CREATED no es la hora de arranque, que IMAGE puede haberse quedado obsoleta si la etiqueta se movió, y que el número virtual de -s no es espacio ocupado sino espacio visto—. Sabes filtrar por estado, nombre, imagen, etiqueta, código de salida y salud, combinando filtros con Y y con O, y sabes dar forma a la salida con plantillas Go hasta convertirla en un panel de control de Aurora Libros que cabe en un alias.

Has aprendido a componer comandos con -q y, más importante, a hacerlo con red: mirar → actuar → comprobar, filtrando siempre por etiqueta para que un borrado masivo no se lleve nunca lo que no era suyo. Conoces la diferencia entre docker rm y docker rm -f —que no es stop + rm, sino un SIGKILL sin gracia—, sabes qué se destruye y qué sobrevive al borrar un contenedor, y usas docker container prune acotado con until y label en vez de a pelo. Has etiquetado la flota con proyecto, componente y entorno, que es exactamente el mecanismo que Docker Compose automatizará por ti en el módulo 4.

Con docker cp mueves ficheros en los dos sentidos, incluso con el contenedor parado, y eso te ha servido para algo memorable: los ocho libros de Aurora Libros están cargados en PostgreSQL, con su tabla, su índice y su INSERT 0 8. Con docker diff sabes ver la capa de escritura convertida en lista de ficheros —A, C y D— y has descubierto la pieza que falta: el directorio de datos de PostgreSQL no aparece en el diff, porque no está en la capa de escritura, sino en un volumen anónimo que la imagen declara y que nadie controla. Y sabes por qué docker commit no sirve para construir imágenes, aunque sea perfecto para congelar la escena de un crimen antes de limpiarla.

Sabes mirar la flota cuando todo va bien. Falta lo otro. En la siguiente lección, Inspección y Depuración de Contenedores, te enfrentarás a los contenedores que no funcionan y no dicen por qué: leerás docker logs a fondo con sus filtros de tiempo y su regla de oro sobre stdout, entrarás con docker exec incluso en imágenes mínimas que no tienen ni ping —con contenedores efímeros que comparten sus namespaces—, exprimirás el JSON de docker inspect con plantillas y jq, y vigilarás en directo con docker top, docker stats y docker events. Y aplicarás todo eso a tres averías reales de Aurora Libros, entre ellas la que lleva dos lecciones esperando: por qué aurora-api no encuentra a aurora-db aunque los dos estén corriendo en la misma máquina.