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 ricreazione di un container non ripristina automaticamente i suoi dati. Identifica i limiti di archiviazione e cosa viene rimosso esattamente da un'operazione. Questo esercizio si basa sulla documentazione ed è stato verificato il 07/09/2026; non sono stati utilizzati container o volumi di produzione per i test.
Tre posizioni di archiviazione
| Posizione | Limite di proprietà | Dopo la rimozione del container |
|---|---|---|
| Livello scrivibile | Contenitore singolo | Le modifiche in questo livello vengono perse |
| Volume denominato | Archiviazione indipendente gestita da Docker | Rimane a meno che il volume non venga rimosso |
| Bind mount | Percorso host Docker specificato | Rimane come file host |
Arrestare/riavviare è diverso da rimuovere/ricreare. La documentazione sui volumi spiega il ciclo di vita. I volumi anonimi hanno regole di pulizia diverse, incluso il comportamento con --rm ; questo esercizio utilizza un volume denominato.
Creazione di un esercizio con volume denominato usa e getta
L'esempio presuppone Docker Engine, container Linux e alpine:3.21 . Annotare la versione di Docker e il digest dell'immagine scaricata; i tag possono cambiare. Verificare con docker volume ls che duskcoil-lifetime-demo non sia inutilizzato prima di procedere:
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'
Risultato previsto: il secondo container legge i dati salvati da /data/note.txt , mentre il suo /tmp/note.txt è assente. La rimozione del primo container lascia il volume denominato intatto. Il secondo mount è di sola lettura. Non sostituire i nomi dei servizi o i dati di produzione in questo esercizio.
Quale host utilizza un bind mount?
I bind mount si riferiscono ai percorsi sull'host del demone Docker. Un demone remoto potrebbe non visualizzare i file del PC locale. Docker Desktop introduce anche un confine di macchina virtuale.
Verificare i punti di montaggio in docker inspect <container> per tipo, origine, destinazione e permessi di lettura/scrittura. Risolvere un punto di montaggio /data errato prima di modificare le impostazioni dell'applicazione. Un punto di montaggio può nascondere i file esistenti al di sotto di esso; distinguere i dati mancanti dai dati nascosti da un'altra directory montata.
Leggere la semantica di pulizia di Compose
docker compose down differisce da docker compose down --volumes. Quest'ultimo si applica anche ai volumi denominati dichiarati in Compose; i volumi esterni vengono gestiti separatamente. Consultare il riferimento successivo.
La modifica del nome di un progetto Compose può selezionare un volume appena denominato e far apparire l'applicazione vuota. Verificare i nomi effettivi prima di presumere la presenza di errori. Rimuovere il volume di prova solo tramite il suo nome specifico dopo aver confermato che non è più necessario; la pulizia generale del volume non fa parte di questa procedura.
La persistenza non è un backup
Un volume separa i dati dal ciclo di vita del container, ma non protegge necessariamente da guasti del disco o dalla cancellazione dell'applicazione. Conservare una copia separata ed eseguire test di ripristino. La copia dei file di database attivi potrebbe non essere coerente: utilizzare procedure di backup supportate dall'applicazione o condizioni di arresto/snapshot appropriate.
Le immagini e i file Compose da soli potrebbero omettere i caricamenti degli utenti e i database. Un database da solo potrebbe omettere la configurazione necessaria, le chiavi o le versioni compatibili. Verificare che l'applicazione ripristinata sia effettivamente in grado di leggere i propri dati.
Creare un inventario dello storage
Per ogni servizio, registrare il percorso all'interno del container, il mount effettivo, la proprietà/i permessi, il metodo di backup, la destinazione del ripristino e la data dell'ultimo test di ripristino. Quindi, procedere con l'esercizio di ripristino del server home per verificare che i dati essenziali siano presenti.
Commenti
Accedi per continuare.
Nessun dato disponibile.