1.3Volúmenes: conservar los datos más allá de los contenedores
Lo esencial en 30 segundos
- El contenedor es efímero : todo lo que escribe en sí mismo muere con él (rm = todo perdido) — para una base, es inaceptable: se almacena fuera del contenedor.
- Nombrado para los datos, bind para el código : -v pgdata:/var/lib/postgresql/data (volumen gestionado por Docker, portable) para los datos; -v ./site:/usr/share/nginx/html (carpeta de la máquina) para el código en dev.
- La prueba que salva : eliminar el contenedor, relanzar sobre el mismo volumen — los datos deben estar ahí; docker volume ls inventaría, rm elimina (definitivo).
Minicaso conductor — Idir pierde (casi) una base
Idir lanzó la base de demostración sin volumen « para ir rápido ». Por la noche, elimina el contenedor para empezar limpio — y descubre que los datos de prueba introducidos por la tarde han desaparecido con él. Al día siguiente, relanza con -v pgdata:/var/lib/postgresql/data, recrea los datos, elimina el contenedor, relanza sobre el mismo volumen: todo está ahí. Ha convertido un susto en reflejo: datos = volumen nombrado, verificado con una prueba rm + relanzamiento antes de cada puesta en marcha seria.
Continuación del caso 1.1-1.2 — Idir pasa de los contenedores desechables a los datos que sobreviven.
1. El drama del contenedor efímero
Por defecto, todo lo que un contenedor escribe en sí mismo muere con él (rm = todo perdido). Para una base de datos, es inaceptable. La solución: almacenar fuera del contenedor, en un volumen gestionado por Docker o una carpeta montada de la máquina.
Cuidado con el falso amigo: stop no borra nada, rm borra todo lo no montado. Creer lo contrario es la pérdida de datos más clásica del nivel 1.
2. Volumen nombrado frente a bind mount
El volumen nombrado (-v pgdata:/var/lib/postgresql/data) lo almacena Docker, portable y respaldable: la elección para los datos. El bind mount (-v ./site:/usr/share/nginx/html) enlaza una carpeta de su máquina: la elección para el código en desarrollo (modifique un archivo, el contenedor lo ve al instante).
La trampa es la ruta interna equivocada: montar al lado del directorio donde la aplicación escribe de verdad es persistir vacío. Se verifica la ruta en la documentación de la imagen.
3. El reflejo que salva: probar la eliminación
La prueba de la verdad: elimine el contenedor, relance otro sobre el mismo volumen — los datos deben estar ahí. docker volume ls inventaría, docker volume rm elimina (cuidado, definitivo). Los volúmenes huérfanos se purgan con prune, con prudencia.
Idir lo ha hecho un ritual: ningún servicio de datos sale a demo sin haber pasado la prueba rm + relanzamiento.
🔎 Ejemplo concreto — 🔎 Ejemplo concreto — Postgres que sobrevive al rm
La base de Idir, antes y después: con volumen, nada se pierde.
docker run -d --name bdd -e POSTGRES_PASSWORD=secret -v pgdata:/var/lib/postgresql/data postgres:16.4
# ... créez des données ...
docker rm -f bdd
docker run -d --name bdd2 -e POSTGRES_PASSWORD=secret -v pgdata:/var/lib/postgresql/data postgres:16.4
# les données sont toujours làLectura: el volumen pgdata ha sobrevivido a la eliminación del contenedor.
Lección: sin -v, la misma secuencia lo habría borrado todo.
Vocabulario de la sección
- Volumen nombrado
- Espacio de almacenamiento gestionado por Docker, persistente fuera de los contenedores, portable y respaldable.
Ejemplo sencillo: pgdata conserva la base de Idir entre bdd y bdd2.
Lo que no es: un archivo escrito en el contenedor sin montaje.
Reflejo: datos = volumen nombrado.
- Bind mount
- Carpeta de la máquina montada tal cual en el contenedor; ideal para el código en desarrollo.
Ejemplo sencillo: -v ./site:/usr/share/nginx/html: Idir modifica, el contenedor lo ve al instante.
Lo que no es: un almacenamiento portable para una base de producción.
Reflejo: código dev = bind, datos prod = volumen nombrado.
- Punto de montaje
- La ruta interna donde aparece el volumen en el contenedor; debe ser aquella donde escribe la aplicación.
Ejemplo sencillo: /var/lib/postgresql/data para postgres:16.4.
Lo que no es: una carpeta cualquiera elegida al azar.
Reflejo: verificar la ruta en la doc de la imagen.
- prune
- Limpieza de los recursos sin usar, volúmenes huérfanos incluidos — eliminación definitiva.
Ejemplo sencillo: Idir purga los volúmenes de sus pruebas desechables, nunca pgdata.
Lo que no es: una papelera de la que se puede restaurar el contenido.
Reflejo: verificar la lista antes de todo prune.
En la práctica — En práctica — Probar la persistencia
- Lance postgres CON un volumen nombrado y cree una tabla.
- Elimine el contenedor (rm -f) sin tocar el volumen.
- Relance un contenedor sobre el mismo volumen y verifique la tabla.
- Repita la prueba SIN volumen: constate la pérdida.
Script listo para decir — proteger una base (30 s)
« Mis datos van en un volumen nombrado: -v pgdata:/var/lib/postgresql/data, en la ruta documentada de la imagen. Lo pruebo: elimino el contenedor, relanzo sobre el mismo volumen, los datos están ahí. Sin volumen, la misma secuencia lo borra todo. »
Para decir ejecutando el rm + relanzamiento en directo; mostrar la tabla siempre presente.
Modelo copiar-pegar — base persistente
docker run -d --name bdd \
-e POSTGRES_PASSWORD=secret \
-v pgdata:/var/lib/postgresql/data \
postgres:16.4
# Preuve : docker rm -f bdd, relancer pareil en --name bdd2, vérifier.
# Jamais : docker volume rm pgdata (définitif) ni prune sans vérifier.Base de Idir en demo
Como arriba: pgdata nombrado como el servicio, prueba rm + relanzamiento superada antes de mostrar nada al responsable.
Sitio web en dev
-v ./site:/usr/share/nginx/html: Idir edita sus páginas en su máquina, el contenedor Nginx las sirve al instante — bind mount, no volumen nombrado.
Recuperación tras el susto
Base lanzada sin volumen por error: crear el volumen, relanzar con -v, reintroducir — y grabar el reflejo « datos = volumen nombrado ».
Limpieza de pruebas
docker volume ls para inventariar, rm dirigido para los volúmenes de prueba, prune solo tras verificación — nunca sobre pgdata.
✓ Buenas prácticas
- Datos = volumen nombrado, código dev = bind mount.
- Probar el rm + relanzamiento antes de creer.
- Nombrar los volúmenes como los servicios (pgdata).
✗ Errores frecuentes
- Creer que stop borra (no) y que rm guarda (no).
- Montar en la ruta interna equivocada (datos al lado).
- Purgar los volúmenes (prune) sin verificar.
Puntos clave
- Sin volumen, rm = pérdida total.
- Volumen nombrado para los datos, bind para el código.
- La prueba rm + relanzamiento prueba la persistencia.
- prune con prudencia: eliminación definitiva.
Desafío 48h — aplique mañana
Lance postgres con volumen nombrado, cree una tabla, haga rm -f + relanzamiento y verifique. Luego repita sin volumen: constate la pérdida — y no la olvide más.
- Monto un volumen nombrado para todo dato que cuente.
- Distingo volumen nombrado (datos) y bind mount (código dev).
- Pruebo la persistencia con rm + relanzamiento antes de un uso serio.
Preguntas frecuentes
¿Dónde están los volúmenes en mi disco?
En el espacio de Docker (docker volume inspect pgdata da la ruta). No se manipulan a mano: se pasa por contenedores o respaldos.
¿Bind mount o volumen para una base en prod?
Volumen nombrado: portable, respaldable, independiente del árbol de la máquina. El bind se reserva al dev y a los archivos de config.
Un contenedor postgres sin volumen se elimina (rm). ¿Qué pasa con sus datos?