APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
A camada gravável de um contentor acompanha essa instância; removê-la pode remover dados que nunca foram guardados fora dela. Um volume nomeado permite separar o ciclo de vida dos dados do contentor. Isso não constitui backup nem recuperação entre anfitriões. Define propriedade, retenção, consistência e teste de restauro segundo a aplicação. Um bind mount liga um caminho específico do anfitrião do daemon ao contentor e cria dependência dessa estrutura. Num daemon remoto, o caminho não é procurado no portátil que executa a CLI. Confirma sempre origem e destino reais antes de interpretar ficheiros em falta ou criar diretórios para fazer o arranque passar.
Aplicação guiada
Num caso fictício, a imagem contém /app/config, mas um bind mount vazio é montado nesse caminho. O mount oculta o conteúdo anterior; isso não prova que a build o apagou. Compara a configuração e a imagem numa instância de diagnóstico isolada antes de corrigir a origem. Volumes vazios podem receber conteúdo inicial da imagem por omissão, comportamento diferente deste bind mount. Quando a aplicação só lê configuração, um mount read-only pode limitar alterações ao anfitrião. Não resolves permissões concedendo escrita global: relaciona o utilizador do processo, os identificadores e as permissões necessárias. Uma cópia de ficheiros de uma base ativa também exige um método de consistência, não apenas um destino persistente.
Novo contentor com volume correto preserva dados; nova camada gravável não recupera a anterior removida.
Armadilhas comuns
Persistência como backup; caminho do cliente como caminho do daemon; mount como remoção de ficheiros.
Tópicos relacionados: Processos e imagens · Build e distribuição · Rede e acesso
Documenta onde os dados vivem e como regressam a um estado consistente.
Referência: Volume lifecycle and mount behavior · Docker Engine Linux containers, BuildKit and Compose; official documentation consulted 2026-09-30; version-dependent behavior explicitly scoped