La plataforma funciona. curl http://localhost:3000/libros devuelve los ocho títulos y la web carga en el navegador. Pero hay una grieta en los cimientos que ya has tropezado dos veces sin darle importancia: cada vez que recreas aurora-db, el catálogo desaparece y tienes que volver a cargar init.sql a mano con docker cp. En una máquina de desarrollo eso es una molestia. En el servidor donde vive el catálogo real de una librería, es una catástrofe.

Esta lección resuelve el segundo gran problema de los contenedores, después de la red: los datos. Vas a demostrar la pérdida con un experimento que da un poco de miedo, vas a conocer los tres tipos de montaje que ofrece Docker y cuándo usar cada uno, vas a entender dónde viven de verdad los volúmenes y por qué no debes tocarlos a mano, y vas a dar a PostgreSQL un volumen con nombre para que el catálogo de Aurora Libros sobreviva a la destrucción de su contenedor. Al final repetirás el experimento del principio y el resultado será el contrario.

1. El problema, demostrado
2. Los tres tipos de montaje
3. Volúmenes gestionados por Docker
4. Volúmenes anónimos y el problema de los huérfanos
5. Bind mounts: ficheros de tu máquina dentro del contenedor
6. -v frente a --mount
7. Montajes de solo lectura
8. tmpfs: datos en memoria
9. Práctica: aurora-datos y la prueba de destrucción
10. Copias de seguridad y restauración
11. Buenas prácticas

Empecemos por mirar el desastre a la cara. Añade un libro nuevo al catálogo:

Nueve libros. La API los sirve. Ahora simula lo que ocurre en cualquier operación normal: actualizar la imagen de PostgreSQL, cambiar una variable de entorno, añadir un límite de memoria... todo eso obliga a recrear el contenedor, como sabes desde la lección 03-01.

No es que falte El Aleph: es que ya no existe la tabla. Todo el catálogo de Aurora Libros se ha evaporado. Y la API, coherente:

Esto no es un fallo de Docker: es su diseño, y ya lo conocías desde la lección 01-05. Un contenedor escribe en una capa de escritura que nace con él y muere con él. Las nueve filas estaban en un volumen anónimo que Docker creó automáticamente —lo descubriste en el ejercicio 2 de la lección 03-03— y que al recrear el contenedor fue sustituido por otro nuevo y vacío.

La solución es sacar los datos del contenedor. Vamos a ello.

Docker ofrece tres formas de que una ruta dentro del contenedor apunte a algo que no está en su capa de escritura:

La regla de decisión, en una frase: si los datos importan y los gestiona la aplicación, un volumen; si el fichero es tuyo y quieres editarlo desde tu editor, un bind mount; si no debe tocar el disco jamás, tmpfs.

Ese segundo nombre ilegible es un volumen anónimo huérfano, resto de alguno de los aurora-db que has borrado. Volveremos a él.

Mountpoint es la ruta en el host. Y aquí va el aviso más importante del apartado:

No entres ahí a tocar ficheros. Esa ruta es propiedad del demonio de Docker: pertenece a root, sus permisos y su contexto de seguridad los gestiona Docker, y en Docker Desktop (macOS y Windows) ni siquiera existe en tu máquina, sino dentro de una máquina virtual Linux a la que no tienes acceso directo. Escribir ahí a mano es una forma excelente de corromper una base de datos.

La forma correcta de mirar dentro de un volumen es con un contenedor:

Vacío, recién creado. Este patrón —un contenedor efímero de Alpine que monta el volumen— es la navaja suiza para inspeccionar, copiar y restaurar volúmenes, y lo usarás en el apartado 10.

Igual que con los contenedores, etiquetar permite limpiar de forma selectiva:

Un volumen anónimo es el que Docker crea por su cuenta, sin que se lo pidas, en dos situaciones:

1. Cuando la imagen declara VOLUME /ruta en su Dockerfile (lo hacen postgres, redis, mysql, mongo…).
2. Cuando montas con -v /ruta indicando solo el destino, sin origen.

Ese nombre de 64 caracteres es el volumen anónimo. Y aquí está su problema:

El volumen sigue ahí, huérfano. Sin contenedor que lo use, con un nombre que nadie puede recordar, y ocupando disco indefinidamente. Cada postgres que has borrado en este módulo dejó atrás uno de estos, con sus datos dentro, irrecuperables en la práctica.

Limpia los huérfanos ahora, comprobando antes qué te vas a llevar por delante:

Cuidado con este comando: docker volume prune borra datos de verdad y no hay papelera. Un volumen "sin usar" puede ser el de una base de datos cuyo contenedor está simplemente parado. Desde Docker 23, prune solo toca los anónimos por defecto; para incluir los que tienen nombre hace falta --all, lo cual es una red de seguridad que conviene no desactivar a la ligera.

Un bind mount conecta una ruta concreta de tu host con una ruta del contenedor. Ya lo usaste en la lección 01-06 con tu index.html.

Es el mismo fichero visto desde dos sitios: los cambios van en las dos direcciones y en tiempo real. Ese es su superpoder para desarrollo —editas en tu IDE y el contenedor lo ve al instante— y su peligro en producción.

Reglas y trampas:

Este es el dolor de cabeza clásico de los bind mounts:

En este caso funciona por casualidad: tu usuario del host tiene UID 1000 y el usuario node de la imagen también. Pero prueba con un usuario distinto:

El kernel compara números, no nombres. Dentro del contenedor no existe ningún "usuario del host": solo hay UID y GID, y los permisos del fichero son los que tenga en tu máquina. Las tres soluciones habituales:

Y de ahí sale una regla que conviene memorizar: los bind mounts son para desarrollo y para ficheros de configuración; los datos de producción van en volúmenes.

Docker ofrece dos sintaxis para lo mismo:

Ese "si el origen no existe" es la diferencia práctica más importante. Con -v, un error de tecleo en la ruta te deja un directorio vacío y un contenedor que arranca sin sus datos; con --mount, obtienes un error claro y el contenedor no arranca.

Tabla de equivalencias para tenerla a mano:

src y source son sinónimos, igual que dst, destination y target.

Un fichero de configuración no tiene por qué ser escribible por el contenedor. Marcarlo como solo lectura es una defensa barata y eficaz:

El kernel lo impide, no Docker. Es el mismo mecanismo que usaste con index.html y nginx.conf en la lección anterior. Úsalo siempre que montes:

• Ficheros de configuración (nginx.conf, redis.conf, postgresql.conf).
• Scripts de inicialización (init.sql).
• Certificados y claves públicas.
• Contenido estático que la aplicación no debe modificar.

Un montaje tmpfs crea un sistema de ficheros en la RAM del host. Nada toca el disco y todo desaparece al parar el contenedor:

Casos de uso reales: secretos desencriptados en tiempo de ejecución, ficheros de sesión, directorios temporales de aplicaciones que se ejecutan con el sistema de ficheros raíz en solo lectura, y cualquier dato que por normativa no deba quedar escrito en disco. Solo funciona en Linux.

Es el momento de arreglar aurora-db de una vez.

La segunda fila usa una convención de la imagen oficial de PostgreSQL: todo lo que haya en /docker-entrypoint-initdb.d/ (ficheros .sql, .sql.gz o .sh) se ejecuta automáticamente, en orden alfabético, la primera vez que se inicializa la base de datos. Es exactamente el trabajo que llevas dos lecciones haciendo a mano con docker cp.

El chmod 644 no es decorativo: el proceso de PostgreSQL corre como el usuario postgres (UID 70), y si el fichero solo fuera legible por tu usuario, el script no podría ejecutarse. Es el choque de UID del apartado 5, aplicado.

Comprueba qué ha pasado en el arranque:

Los ocho libros se han cargado solos. Sin docker cp, sin psql -f, sin acordarse de nada.

Verifica los montajes:

Un volumen escribible para los datos y un bind mount de solo lectura para el script. Exactamente el plan.

Añade otra vez El Aleph:

Y ahora, destruye el contenedor. Sin miedo:

El contenedor ya no existe. El volumen sigue ahí. Recréalo con exactamente el mismo comando de antes:

El Aleph sigue ahí. Has borrado el contenedor de la base de datos por completo y el catálogo ha sobrevivido intacto, con sus nueve libros. Compara con el apartado 1 de esta misma lección, donde el mismo experimento destruyó hasta la tabla.

Y hay un detalle en los logs que merece una mirada:

El init.sql no se ha vuelto a ejecutar. La imagen detecta que el directorio de datos ya contiene una base de datos y se salta la inicialización. Eso es exactamente lo que quieres: si se ejecutara siempre, el CREATE TABLE IF NOT EXISTS no haría daño, pero un script menos cuidadoso podría borrar datos reales en cada arranque. Y la consecuencia práctica: si cambias init.sql, no bastará con reiniciar; tendrás que borrar el volumen para que vuelva a inicializarse desde cero.

(No lo ejecutes ahora: lo necesitas para la siguiente lección.)

El contenedor de Nginx que creaste en la lección anterior ya usa bind mounts; ahora puedes leer aquel comando con otros ojos:

Bind mounts de solo lectura para dos ficheros que viven en tu repositorio de Git. Edita index.html en tu editor, recarga el navegador, y el cambio está ahí sin reconstruir ninguna imagen: ese es el flujo de desarrollo que se convierte en el protagonista de la lección 04-07.

Un volumen que no se copia es un volumen que se perderá. Hay dos estrategias y sirven para cosas distintas.

El patrón universal: un contenedor efímero que monta el volumen y un directorio del host, y ejecuta tar.

Qué hace cada parte:

La restauración es la operación inversa:

El ..?* del rm es para incluir los ficheros ocultos; sin él quedarían restos de la instalación anterior mezclados con la copia.

Para una base de datos, casi siempre es mejor una copia lógica: un fichero SQL con el esquema y los datos.

Y la restauración, con -i para que psql lea de la entrada estándar:

Comparación de las dos estrategias:

La regla: usa la herramienta nativa del servicio si la tiene (pg_dump, mysqldump, redis-cli BGSAVE), y el truco del contenedor con tar para todo lo demás.

Estado actual del almacenamiento de Aurora Libros:

Un solo volumen, con nombre, y 0 B recuperables: ni un huérfano. Ese es el objetivo.

Lo que esta lección no cubre y dónde se ve: los storage drivers del demonio (overlay2 y compañía), los drivers de volumen para NFS, SMB o almacenamiento en la nube, y las opciones avanzadas de rendimiento se estudian en la lección 05-02. Cómo se declaran los volúmenes en un fichero compose.yaml, en la lección 04-02.

• Confiar en la capa de escritura para datos que importan. Muere con el contenedor, y recrear un contenedor es una operación rutinaria.
• Usar volúmenes anónimos sin saberlo. Toda imagen con VOLUME en su Dockerfile crea uno. Si no le pones nombre, tus datos dependen de un hash que nadie recuerda.
• Ejecutar docker volume prune sin mirar. Borra datos reales sin confirmación por segunda vez y sin papelera. Lista antes con docker volume ls -f dangling=true.
• Escribir a mano en /var/lib/docker/volumes/.... Permisos incorrectos, corrupción, y en Docker Desktop ni siquiera existe esa ruta.
• Rutas relativas en un bind mount. Usa rutas absolutas o $(pwd); con -v, una ruta mal escrita se convierte en un directorio vacío creado como root.
• Montar un directorio vacío sobre uno que tenía contenido. El montaje oculta lo de la imagen: Nginx devolverá 403 y PostgreSQL se reinicializará.
• Esperar que init.sql se ejecute en cada arranque. Solo corre cuando el directorio de datos está vacío. Si lo cambias, borra el volumen.
• Copiar un volumen de base de datos en caliente con tar. Puede salir corrupto. Para el contenedor, o usa pg_dump.
• Consejo: escribe el docker run de tus servicios con datos en un fichero de notas. Es largo y hay que reproducirlo exactamente para no perder el volumen... hasta el módulo 4, donde eso se resuelve del todo.
• Consejo: nombra las copias con la fecha y automatiza su rotación. Y restaura al menos una vez, para saber que funciona.

Crea un contenedor de alpine:3.20 llamado tres-montajes con sleep 600 y tres montajes a la vez: un volumen con nombre prueba-vol en /vol, un bind mount de ~/aurora-libros/pruebas en /bind, y un tmpfs de 8 MB en /mem. Escribe un fichero distinto en cada ruta. Después:

1. Reinicia el contenedor con docker restart y comprueba cuáles de los tres ficheros siguen.
2. Bórralo con docker rm -f (sin -v), crea uno nuevo con los mismos montajes y comprueba de nuevo los tres.
3. Explica los resultados y di qué montaje usarías para: el catálogo de libros, el nginx.conf, y un token de sesión que no debe tocar el disco.

Redis guarda su instantánea en /data, que la imagen oficial declara como VOLUME y por tanto hoy es un volumen anónimo. Arregla eso:

1. Comprueba con docker inspect que el aurora-cache actual usa un volumen anónimo.
2. Recréalo con un volumen con nombre aurora-cache-datos y activando la persistencia con el comando redis-server --appendonly yes.
3. Escribe una clave, fuerza un guardado, destruye el contenedor y recréalo. Comprueba si la clave sobrevive.
4. Responde: ¿tiene sentido persistir una caché? Argumenta a favor y en contra.

Con la plataforma funcionando y los nueve libros en su sitio:

1. Haz una copia de seguridad lógica con pg_dump y otra física con tar, anotando el tamaño de cada una.
2. Provoca el desastre: borra el contenedor aurora-db y el volumen aurora-datos.
3. Comprueba qué responde la API en ese momento.
4. Recupérate por el camino más rápido y explica cuál elegiste y por qué. Verifica que los nueve libros —incluido El Aleph, que no está en init.sql— vuelven a estar disponibles a través de curl http://localhost:8080/api/libros.

Solución al ejercicio 1

1. Tras docker restart:

El tmpfs ya se ha perdido con el simple reinicio: vivía en RAM y el montaje se recrea vacío en cada arranque.

2. Tras borrar y recrear:

3. Resultados y decisiones:

Y las tres decisiones: el catálogo de libros → volumen con nombre (dato de producción que debe sobrevivir y del que Docker gestiona los permisos); el nginx.conf → bind mount de solo lectura (fichero versionado en Git que quieres editar en tu IDE y que el contenedor solo lee); el token de sesión → tmpfs (no debe quedar escrito en disco ni siquiera un instante, y debe evaporarse al parar el contenedor).

Solución al ejercicio 2

Volumen anónimo confirmado: nombre de 64 caracteres, creado por el VOLUME /data del Dockerfile oficial de Redis.

La clave sobrevive. Nota que hicieron falta dos cosas: el volumen con nombre (para que los ficheros persistan) y --appendonly yes (para que Redis escriba en ellos). Un volumen sin persistencia activada guardaría un fichero que nunca se actualiza.

4. ¿Tiene sentido persistir una caché?

A favor:

• Arranque en caliente. Tras un reinicio, la caché ya tiene datos y no hay una avalancha de peticiones contra PostgreSQL (el fenómeno conocido como thundering herd).
• Si Redis se usa también para sesiones de usuario o colas de trabajo, ahí ya no es una caché: son datos que perder tiene consecuencias visibles.

En contra:

• Una caché, por definición, debe poder perderse sin consecuencias. Si tu sistema no funciona sin ella, no es una caché: es una base de datos disfrazada, y debería tratarse como tal.
• La persistencia cuesta: E/S de disco en cada escritura y un arranque más lento.
• Los datos persistidos pueden quedar obsoletos: al recuperarse, Redis sirve un catálogo antiguo hasta que expire el TTL.

Para Aurora Libros, con un TTL de 60 segundos y un catálogo pequeño, no compensa: es más limpio dejar aurora-cache sin persistencia y que se rellene sola en la primera petición. Ese es el criterio que se aplicará en el compose.yaml del módulo 4.

Solución al ejercicio 3

1. Las dos copias:

Dos mil veces más pequeña la lógica que la física, para exactamente los mismos nueve libros.

2 y 3. El desastre:

Interesante: el error no es de base de datos, sino de DNS. Al no existir el contenedor, el nombre aurora-db no se resuelve en aurora-net. Es el mismo ENOTFOUND de la lección 03-04, ahora con una causa distinta: allí faltaba la red, aquí falta el contenedor.

4. La recuperación:

Ocho, no nueve. init.sql restauró el catálogo original, pero El Aleph no está ahí: se insertó después. Aquí es donde la copia de seguridad deja de ser un trámite y pasa a ser lo único que te salva:

Elegí la copia lógica, y por tres motivos:

1. Es más rápida de aplicar: un psql de 4 kB frente a parar el servicio, vaciar el volumen y desempaquetar 8,4 MB.
2. No exige parar nada: se restaura sobre la base de datos en marcha, mientras la copia física obliga a detener el contenedor.
3. Es portable: si al recuperarme hubiera aprovechado para subir a PostgreSQL 17, el tar del volumen no habría servido —el formato del directorio de datos es específico de cada versión mayor— y el .sql sí.

La copia física sigue teniendo su papel: es la única opción para volúmenes de aplicaciones que no tienen una herramienta de volcado propia, y es una copia bit a bit que incluye configuración y estado que pg_dump no recoge.

El segundo gran problema está resuelto. Has visto con tus propios ojos que un contenedor destruido se lleva sus datos —la primera vez ni siquiera quedaba la tabla libros— y sabes por qué: la capa de escritura nace y muere con el contenedor, y los volúmenes anónimos que crean por su cuenta imágenes como postgres o redis no se reutilizan, sino que quedan huérfanos con sus datos dentro, inalcanzables en la práctica.

Conoces los tres tipos de montaje y cuándo usar cada uno: volúmenes gestionados por Docker para los datos que importan, bind mounts para configuración y desarrollo, y tmpfs para lo que no debe tocar el disco. Sabes dónde viven realmente los volúmenes —/var/lib/docker/volumes/…, territorio del demonio, invisible en Docker Desktop— y que la forma correcta de mirar dentro es un contenedor efímero de Alpine, nunca tu editor. Entiendes el choque de UID de los bind mounts, porque el kernel compara números y no nombres, y tienes las tres formas de resolverlo. Y prefieres --mount a -v en scripts por una razón muy concreta: falla ruidosamente en vez de crear un directorio vacío que arruina el arranque en silencio.

Aurora Libros ha cambiado de categoría. aurora-db guarda su estado en el volumen con nombre aurora-datos y recibe init.sql como bind mount de solo lectura en /docker-entrypoint-initdb.d/, así que el catálogo se carga solo la primera vez y nunca más se pisa. La prueba definitiva salió como debía: insertaste El Aleph, destruiste el contenedor entero, lo recreaste con el mismo comando y los nueve libros seguían ahí. Y aurora-web sirve index.html y nginx.conf desde tu repositorio en :ro, editables desde tu IDE sin reconstruir nada. Además sabes copiar y restaurar: con un contenedor auxiliar y tar para cualquier volumen, y con pg_dump —más pequeña, en caliente y portable entre versiones— para la base de datos.

Quedan dos riesgos en pie, y son los últimos de este módulo. El primero lo viste en docker stats en la lección 03-04: ninguno de tus contenedores tiene límite de memoria, así que una consulta desbocada en PostgreSQL o una fuga en Node pueden dejar sin RAM a toda la máquina. El segundo es que si un contenedor muere de madrugada, nadie lo levanta. En la siguiente lección, Límites de Recursos y Políticas de Reinicio, pondrás cerco a ambos: límites de memoria y CPU con sus tablas de combinaciones, el OOM killer provocado a propósito para verlo con OOMKilled: true y su código 137, --pids-limit como defensa ante una fork bomb, y las cuatro políticas de reinicio con la diferencia sutil entre always y unless-stopped. Y al terminar, tendrás delante la lista completa de comandos que hace falta para levantar Aurora Libros desde cero... y entenderás por qué existe Docker Compose.