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.
La recréation d'un conteneur ne restaure pas automatiquement ses données. Identifiez les limites de stockage et ce qu'une opération supprime précisément. Cet exercice, basé sur la documentation, a été testé le 7 septembre 2026 ; aucun conteneur ni volume de production n'a été utilisé pour les tests.
Trois emplacements de stockage
| Emplacement | Limite de propriété | Après la suppression du conteneur |
|---|---|---|
| Couche accessible en écriture | Conteneur individuel | Les modifications apportées à cette couche sont perdues |
| Volume nommé | Stockage indépendant géré par Docker | Conservé sauf si le volume est supprimé |
| Point de montage | Chemin Docker spécifié | Conservé sous forme de fichiers hôtes |
L'arrêt/le redémarrage diffère de la suppression/recréation. La documentation des volumes explique le cycle de vie. Les volumes anonymes ont des règles de nettoyage différentes, notamment en ce qui concerne le comportement avec --rm ; cet exercice utilise un volume nommé.
Exercice de création d'un volume nommé jetable
Cet exemple suppose l'utilisation de Docker Engine, de conteneurs Linux et de alpine:3.21. Notez la version de Docker et le condensé de l'image téléchargée ; les étiquettes peuvent changer. Vérifiez avec docker volume ls que duskcoil-lifetime-demo n'est pas utilisé avant de continuer :
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'
Résultat attendu : le deuxième conteneur lit les données sauvegardées depuis /data/note.txt, tandis que son /tmp/note.txt est absent. La suppression du premier conteneur laisse le volume nommé intact. Le deuxième montage est en lecture seule. N'utilisez pas les noms de services ou les données de production dans cet exercice.
Quel hôte un montage de liaison utilise-t-il ?
Les montages de liaison font référence à des chemins sur l'hôte du démon Docker. Un démon distant peut ne pas accéder aux fichiers de votre PC local. Docker Desktop introduit également une limite de machine virtuelle.
Inspectez les points de montage dans docker inspect <container> pour vérifier le type, la source, la destination et les droits d'écriture et de lecture (RW). Corrigez un point de montage /data incorrect avant de modifier les paramètres de l'application. Un point de montage peut masquer des fichiers existants ; distinguez les données manquantes de celles masquées par un autre répertoire monté.
Consultez la documentation sur le nettoyage de Compose
docker compose down diffère de docker compose down --volumes. Ce dernier cible également les volumes nommés déclarés dans Compose ; les volumes externes sont gérés séparément. Consultez la référence ci-dessous.
Modifier le nom d'un projet Compose peut sélectionner un volume nouvellement nommé et donner l'impression que l'application est vide. Vérifiez les noms réels avant de conclure à une corruption. Supprimez le volume d'exercice uniquement par son nom spécifique après avoir confirmé qu'il n'est plus nécessaire ; le nettoyage global des volumes ne fait pas partie de cette procédure.
La persistance n'est pas une sauvegarde
Un volume sépare les données du cycle de vie du conteneur, mais ne les protège pas nécessairement contre une panne de disque ou la suppression d'une application. Conservez une copie distincte et testez la restauration. La copie de fichiers de base de données actifs peut être incohérente : utilisez les procédures de sauvegarde prises en charge par l'application ou des conditions d'arrêt/instantané appropriées.
Les images et les fichiers Compose seuls peuvent omettre les chargements utilisateur et les bases de données. Une base de données seule peut omettre la configuration requise, les clés ou les versions compatibles. Vérifiez que l'application restaurée peut bien lire ses données.
Créer un inventaire du stockage
Pour chaque service, enregistrez le chemin dans le conteneur, le point de montage actuel, le propriétaire/les permissions, la méthode de sauvegarde, la destination de restauration et la date du dernier test de restauration. Poursuivez ensuite avec l'exercice de restauration de serveur domestique pour vérifier que les données essentielles sont bien présentes.
Commentaires
Veuillez vous connecter.
Aucune entrée pour le moment.