Contents — find the section you need
Change parameters and verify
Open the panel, then press Run to load Python. You can stop execution and reset parameters. Results are computed on this device. No Python installation is required.
Local execution steps below are optional for reproducing the source results; they are not required for the browser experiment.
The experiment controls are in English.
Explore storage boundaries in the browser
The panel models storage ownership and container connections. It does not run Docker or access your files. Choose a storage location and operation, then compare the stage diagram and evidence table. Local Docker commands below are optional follow-up work.
Each run starts from the same prepared fixture: /data/note.txt contains saved in the selected store, and /tmp/note.txt contains temporary in the container's writable layer. The image has no initial files at /data; application startup creates no files. The selected mount's read-only setting is applied after preparation. At the end, the model attempts to write a different file, /data/probe.txt. That marker never recreates the original note.
The named volume uses the default project-scoped name alpha_data. The external volume is pre-existing shared_data; the bind mount always uses the same absolute daemon-host path /srv/demo-data. Both fixed sources remain the same when changing projects. No custom volume name, anonymous volumes, tmpfs, driver options, image-to-volume population, permissions beyond the read-only mount, or other containers are modeled.
“Switch project” means alpha is taken down without deleting volumes, then beta is started. “Switch back” repeats that operation to return to alpha. A new empty beta_data can hide access to the original note without deleting alpha_data. The diagram distinguishes retained data from a readable connection. The read-only control applies only to mounts and has no effect in the writable-layer case.
Try these comparisons: restart versus recreate for the writable layer; ordinary down versus down --volumes for a managed named volume; project switching versus switching back; and managed versus external volumes during cleanup. Each removal scenario includes starting the service again. Metrics are binary outcomes (1 = yes, 0 = no), not probabilities, timings, or recovery guarantees.
Rules were checked against Docker storage, volume lifecycle, bind mounts, Compose down and Compose volume names/external volumes on 2026-09-20. This is a documentation-based state model, not a live Engine conformance test. It models neither host failure nor application/database consistency. Continue to the restore Lab to examine separate recovery checks.
Recrear un contenedor no restaura automáticamente sus datos. Identifique los límites de almacenamiento y qué elimina exactamente una operación. Este es un ejercicio basado en la documentación, revisado el 7 de septiembre de 2026; no se utilizaron contenedores ni volúmenes de producción para las pruebas.
Tres ubicaciones de almacenamiento
| Ubicación | Límite de propiedad | Tras la eliminación del contenedor |
|---|---|---|
| Capa de escritura | Contenedor individual | Los cambios en esa capa se pierden |
| Volumen con nombre | Almacenamiento independiente gestionado por Docker | Permanece a menos que se elimine el volumen |
| Montaje de enlace | Ruta especificada en el host de Docker | Permanece como archivos del host |
Detener/reiniciar es diferente de eliminar/recrear. La documentación de volúmenes (https://docs.docker.com/engine/storage/volumes/) explica su ciclo de vida. Los volúmenes anónimos tienen reglas de limpieza diferentes, incluido el comportamiento con --rm; este ejercicio utiliza un volumen con nombre.
Ejercicio de creación de un volumen con nombre desechable
Este ejemplo asume Docker Engine, contenedores Linux y alpine:3.21. Registre la versión de Docker y el resumen de la imagen descargada; las etiquetas pueden cambiar. Antes de continuar, verifique con docker volume ls que duskcoil-lifetime-demo no esté en uso:
docker volume create duskcoil-lifetime-demo
docker run --rm --mount type=volume,source=duskcoil-lifetime-demo,target=/data alpine:3.21 sh -c 'echo saved > /data/note.txt; echo temporary > /tmp/note.txt'
docker run --rm --mount type=volume,source=duskcoil-lifetime-demo,target=/data,readonly alpine:3.21 sh -c 'cat /data/note.txt; test ! -e /tmp/note.txt'
Resultado esperado: el segundo contenedor lee los datos guardados desde /data/note.txt, mientras que su /tmp/note.txt no está presente. Al eliminar el primer contenedor, el volumen con nombre permanece intacto. El segundo montaje es de solo lectura. No sustituya los nombres ni los datos de los servicios de producción en este ejercicio.
¿Qué host utiliza un montaje de enlace?
Los montajes de enlace hacen referencia a rutas en el host del demonio de Docker. Un demonio remoto podría no ver los archivos de tu PC local. Docker Desktop también introduce un límite de máquina virtual.
Inspecciona los montajes en docker inspect <container> para ver el tipo, origen, destino y permisos de lectura/escritura. Resuelve un montaje incorrecto en /data antes de cambiar la configuración de la aplicación. Un montaje puede ocultar archivos existentes debajo; distingue los datos faltantes de los datos ocultos por otro directorio montado.
Consulta la semántica de limpieza de Compose
docker compose down difiere de docker compose down --volumes. Este último también se dirige a volúmenes con nombre declarados en Compose; los volúmenes externos se gestionan por separado. Consulta la referencia inferior.
Cambiar el nombre de un proyecto de Compose puede seleccionar un volumen con un nombre nuevo y hacer que la aplicación parezca vacía. Inspecciona los nombres reales antes de asumir que hay corrupción. Elimina el volumen de ejercicio solo por su nombre específico después de confirmar que ya no es necesario; la limpieza general del volumen no forma parte de este procedimiento.
La persistencia no es una copia de seguridad
Un volumen separa los datos del ciclo de vida del contenedor, pero no necesariamente protege contra fallos de disco o la eliminación de la aplicación. Mantenga una copia independiente y pruebe la restauración. La copia de archivos de bases de datos en producción puede ser inconsistente: utilice los procedimientos de copia de seguridad compatibles con la aplicación o las condiciones de apagado/instantánea adecuadas.
Las imágenes y los archivos de Compose por sí solos pueden omitir las cargas de usuario y las bases de datos. Una base de datos por sí sola puede omitir la configuración necesaria, las claves o las versiones compatibles. Confirme que la aplicación restaurada pueda leer sus datos.
Cree un inventario de almacenamiento
Para cada servicio, registre la ruta dentro del contenedor, el punto de montaje real, la propiedad/permisos, el método de copia de seguridad, el destino de la restauración y la fecha de la última prueba de restauración. A continuación, continúe con el ejercicio de restauración del servidor principal para comprobar que los datos esenciales estén incluidos.
Comentarios
Inicia sesión para continuar.
Todavía no hay datos.