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.
Recriar um contêiner não restaura automaticamente seus dados. Identifique os limites de armazenamento e exatamente o que uma operação remove. Este é um exercício baseado em documentação, verificado em 07/09/2026; nenhum contêiner ou volume de produção foi usado para teste.
Três locais de armazenamento
| Local | Limite de propriedade | Após a remoção do contêiner |
|---|---|---|
| Camada gravável | Contêiner individual | Alterações nessa camada são perdidas |
| Volume nomeado | Armazenamento independente gerenciado pelo Docker | Permanece a menos que o volume seja removido |
| Montagem vinculada | Caminho especificado pelo host Docker | Permanece como arquivos do host |
Parar/reiniciar difere de remover/recriar. A documentação do volume explica o ciclo de vida. Volumes anônimos têm regras de limpeza diferentes, incluindo o comportamento com --rm ; este exercício usa um volume nomeado.
Exercício de criação de um volume nomeado descartável
O exemplo pressupõe o uso do Docker Engine, contêineres Linux e alpine:3.21. Registre a versão do Docker e o resumo da imagem baixada; as tags podem mudar. Verifique com docker volume ls se duskcoil-lifetime-demo está desocupado antes de prosseguir:
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'
Esperado: o segundo contêiner lê o valor salvo de /data/note.txt, enquanto seu /tmp/note.txt está ausente. A remoção do primeiro contêiner mantém o volume nomeado intacto. A segunda montagem é somente leitura. Não substitua nomes ou dados de serviços de produção neste exercício.
Qual host é usado em uma montagem de vinculação?
Montagens de vinculação referem-se a caminhos no host do daemon do Docker. Um daemon remoto pode não ver os arquivos do seu computador local. O Docker Desktop também introduz um limite de máquina virtual.
Inspecione as montagens em docker inspect <container> para verificar Tipo, Origem, Destino e Leitura/Leitura. Resolva uma montagem /data incorreta antes de alterar as configurações do aplicativo. Uma montagem pode ocultar arquivos existentes abaixo dela; distinga dados ausentes de dados ocultos por outro diretório montado.
Leia a semântica de limpeza do Compose
docker compose down difere de docker compose down --volumes. Este último também tem como alvo volumes nomeados declarados no Compose; volumes externos são gerenciados separadamente. Consulte a referência abaixo.
Alterar o nome de um projeto do Compose pode selecionar um volume recém-nomeado e fazer com que o aplicativo pareça vazio. Inspecione os nomes reais antes de presumir corrupção. Remova o volume de exercício apenas pelo seu nome específico, após confirmar que ele não é mais necessário; a limpeza geral do volume não faz parte deste procedimento.
Persistência não é backup
Um volume separa os dados do ciclo de vida do contêiner, mas não necessariamente protege contra falhas de disco ou exclusão de aplicativos. Mantenha uma cópia separada e teste a restauração. Copiar arquivos de banco de dados ativos pode ser inconsistente: use procedimentos de backup suportados pelo aplicativo ou condições apropriadas de desligamento/snapshot.
Imagens e arquivos Compose, por si só, podem omitir uploads de usuários e bancos de dados. Um banco de dados, por si só, pode omitir configurações, chaves ou versões compatíveis necessárias. Confirme se o aplicativo restaurado consegue realmente ler seus dados.
Crie um inventário de armazenamento
Para cada serviço, registre o caminho no contêiner, a montagem real, a propriedade/permissões, o método de backup, o destino da restauração e a data do último teste de restauração. Em seguida, continue com o exercício de restauração do servidor doméstico para verificar se os dados essenciais estão cobertos.
Comentários
Entre na sua conta para continuar.
Ainda não há dados.