Porque é que uma stack do Compose associa um novo volume nomeado vazio após a reimplementação?

Eva Wong

IceWhale author

Eva Wong é a Redatora Técnica e e entusiasta residente na ZimaSpace. Uma geek de longa data com paixão por homelabs e software de código aberto, ela é especialista em traduzir conceitos técnicos complexos em guias acessíveis e práticos . Eva acredita que o auto-hospedagem deve ser divertida, não intimidante. Através dos seus tutoriais, ela capacita a comunidade adesmistificar configurações de hardware , desde a construção do seu primeiro NAS até dominar os contêineres Docker., from building their first NAS to mastering Docker containers.

Why Does a Compose Stack Attach a New Empty Named Volume After Redeployment?

Uma stack do Compose pode associar um novo volume nomeado vazio quando uma nova implementação altera o nome do volume associado ao projeto ou não consegue encontrar o volume original.

Os dados antigos podem ainda existir noutro volume do Docker, enquanto o serviço recriado monta um volume recém-gerado no mesmo caminho do contentor. As causas comuns incluem a alteração do nome da stack ou do projeto, a mudança da chave do volume, a remoção através de um comando que elimina volumes, a perda de uma declaração externa, a implementação através de outro gestor ou um nome de volume explícito que agora é resolvido de forma diferente. Faça um inventário do volume montado e dos candidatos órfãos antes de restaurar dados ou inicializar a aplicação.

Identificar o Volume Exato Montado pelo Novo Contentor

Inspecione as montagens do contentor em execução e registe o nome do volume, o controlador, o ponto de montagem, as etiquetas, a data de criação, o destino no contentor e o modo de leitura e escrita. Compare-os com os registos anteriores à nova implementação.

O comando docker volume inspect do Ubuntu expõe a identidade do volume, permitindo distinguir o novo volume vazio de um volume antigo não montado com uma nomenclatura semelhante.

Não copie dados para o novo volume até encontrar o original. Iniciar a aplicação pode criar uma nova base de dados e fazer com que o destino pareça ter sido inicializado intencionalmente.

Verificar se o Nome do Projeto Compose Mudou

Compare o nome antigo e o novo do projeto, o nome da stack, o diretório do Compose, a opção -p, COMPOSE_PROJECT_NAME, o name: de nível superior e o gestor de implementação.

A Docker explica que o Compose normalmente associa um volume ao projeto como nome-do-projeto mais chave-do-volume, a menos que esteja configurado um nome explícito ou uma pesquisa de volume externo.

Assim, mover o mesmo ficheiro Compose para outro diretório pode criar um segundo projeto e um segundo volume, mesmo quando o serviço e as chaves do volume não mudam.

Verificar as Definições de Nome Estável e de Volume Externo

Compare a definição de volume de nível superior antes e depois da nova implementação. Verifique name:, external:, as opções do controlador, as variáveis de interpolação e se o volume esperado existe.

O tutorial da Microsoft sobre Docker Compose indica que os volumes nomeados persistem independentemente da substituição do contentor; por isso, um novo estado vazio normalmente significa que foi associada uma identidade de volume diferente ou que o volume antigo foi removido.

Marque um volume como externo apenas quando o seu ciclo de vida for gerido intencionalmente fora da stack. O Compose deve falhar claramente quando um volume externo não existe, em vez de criar silenciosamente um substituto.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

Verificar se uma Limpeza Removeu o Volume Original

Consulte os registos de implementação, os scripts, as ações da interface, as tarefas de limpeza e os comandos relativos à eliminação de volumes. Compare a data de criação do volume com o evento de nova implementação.

A Red Hat documenta que os volumes nomeados geridos por contentores têm localizações de armazenamento separadas das camadas graváveis dos contentores, razão pela qual remover um contentor e remover o seu volume nomeado são eventos diferentes no ciclo de vida.

Se o volume original estiver ausente, interrompa os arranques automáticos e restaure apenas a partir de uma cópia de segurança verificada. Não presuma que um volume de substituição vazio contém uma camada eliminada recuperável.

Comparar a Identidade do Gestor da Stack e o Método de Implementação

Registe se a stack foi iniciada pela CLI, pelo Portainer, por uma loja de aplicações NAS, por uma implementação Git ou por outra ferramenta de automatização. Compare o nome da stack e os valores do ambiente armazenados por esse gestor.

O Portainer exige um nome descritivo para a stack durante a implementação, e a identidade controlada por esse gestor pode diferir do nome do projeto baseado no diretório, utilizado por um comando Compose manual.

Assim, um arranque manual de emergência pode criar recursos com outro prefixo de projeto. Escolha um único responsável pela implementação e documente os nomes de volume resolvidos que este cria.

Excluir a Possibilidade de Dados Ocultos Sob a Nova Montagem do Volume

Pare o contentor e inspecione a imagem ou o caminho associado sem o volume nomeado, utilizando um teste descartável. Determine se o arranque escreveu dados na camada do contentor antes de o volume ser montado.

O manual de montagem do Linux explica que uma montagem oculta os conteúdos pré-existentes do diretório; por isso, os dados podem parecer desaparecidos quando um novo volume vazio cobre ficheiros criados na imagem ou na camada gravável.

Não misture cegamente a camada oculta com o volume persistente antigo. Identifique qual dos estados é a fonte de verdade e utilize o método de recuperação suportado pela aplicação.

Voltar a Associar o Volume Original com um Teste Controlado

Pare a stack, faça uma cópia de segurança de ambos os volumes candidatos, associe o original a um contentor descartável ou a um caminho de serviço temporário e verifique os ficheiros da aplicação, a identidade da base de dados, a propriedade e as marcas temporais.

O guia da ZimaSpace sobre mover dados de contentores sem quebrar as montagens apresenta o fluxo de trabalho adjacente de mapeamento de caminhos; este artigo centra-se na identidade dos volumes nomeados associados ao projeto.

O problema fica resolvido quando o volume antigo pretendido é montado com um nome explícito estável ou um nome externo e as novas implementações reutilizam-no sem criar outro candidato vazio.

Perguntas Frequentes

Um volume nomeado vazio significa que os dados antigos foram eliminados?

Não necessariamente. O volume antigo pode ainda existir com outro prefixo de projeto ou nome explícito, enquanto o novo contentor utiliza um volume vazio diferente.

Mudar o nome da pasta do Compose pode criar um novo volume?

Sim. Quando não é fixado um nome de projeto, o Compose pode obtê-lo a partir do diretório do projeto e criar recursos com prefixos diferentes.

Os volumes importantes devem ser marcados como externos?

Os volumes externos podem impedir que a remoção da stack faça a gestão do seu ciclo de vida, mas exigem criação, atribuição de nome, cópias de segurança e verificações de implementação deliberadas.