Fluxo de migração de volumes nomeados do Docker entre dois servidores domésticos

A abordagem segura consiste em tratar um arquivo arquivado em estado quiescente ou uma cópia sincronizada para um volume de destino explicitamente identificado, seguida de validação por checksum e pela aplicação, como uma sequência de etapas observáveis, não como um único comando.

Em dois servidores domésticos Linux a executar Docker Compose, o risco prático é um contentor com estado ter de ser movido para outro anfitrião sem copiar um volume ativo ou com um nome incorreto. Registe a identidade atual e o ponto de recuperação, comece pelo discriminador menos intrusivo, interprete os resultados aprovados e reprovados antes de alterar outra variável e pare quando o armazenamento ficar instável ou quando a única cópia recuperável puder ficar exposta. O fluxo de trabalho abaixo só termina depois de a carga de trabalho original funcionar ou de as evidências atingirem um limite de escalada.

Identifique os contratos dos volumes de origem e de destino

Registe o digest da imagem do contentor de origem, o nome do projeto Compose, o serviço, a chave do volume, o nome real do volume Docker, o destino da montagem, o controlador do volume e a versão da aplicação. Use docker inspect e docker volume inspect; não deduza o caminho físico apenas a partir de um rótulo YAML.

Normalmente, o Compose acrescenta o nome do projeto aos volumes nomeados, exceto quando é usado um nome explícito ou um volume externo. No destino, apresente a configuração do Compose e crie explicitamente o volume vazio pretendido, para que a migração não termine num volume enquanto o serviço inicia outro.

Se o volume contiver uma base de dados, use a exportação nativa ou a cópia de segurança suportada como principal via portátil de recuperação e trate a cópia do volume como um ponto de recuperação da mesma versão. Pare se o controlador for remoto, se o armazenamento de origem estiver instável ou se o estado da aplicação abranger volumes adicionais que não estejam no âmbito.

Coloque os processos de escrita em estado quiescente e crie uma cópia que preserve os metadados

Coloque a aplicação em modo de manutenção, pare as tarefas em segundo plano e, em seguida, pare corretamente a aplicação e a base de dados. Confirme que nenhum contentor monta o volume com acesso de leitura e escrita. Crie um arquivo através de um contentor temporário ou use uma cópia controlada do sistema de ficheiros que preserve a propriedade numérica, as permissões, as ligações simbólicas, os atributos estendidos quando necessários e os ficheiros esparsos.

Um guia independente em migração de volumes Docker com rsync demonstra como mover dados de volumes Docker com rsync. O limite importante é que a origem deve estar em estado quiescente e o comando de cópia deve operar sobre o conteúdo do volume identificado, não manipular cegamente o diretório interno do Docker enquanto o daemon o utiliza.

Gere um manifesto com a contagem de ficheiros, o total de bytes, hashes representativos e o checksum do arquivo. Mantenha o volume de origem e a cópia de segurança nativa intactos; a fase de cópia só passa quando o artefacto transferido puder ser lido no anfitrião de destino.

Restaure no volume de destino explícito

Verifique a capacidade do sistema de ficheiros de destino, a disponibilidade de inodes, as expectativas de UID e GID e a mesma versão da imagem da aplicação. Restaure o arquivo no volume de destino vazio sem nivelar a estrutura do diretório de nível superior e, em seguida, compare a propriedade, as contagens, os tamanhos e os hashes selecionados.

Uma discussão da comunidade sobre um caso de falha na migração de volumes nomeados mostra por que motivo a substituição direta de ficheiros dentro dos componentes internos dos volumes Docker pode falhar ou deixar um estado confuso. Use o runtime para montar o volume num contentor auxiliar e efetue a restauração através dessa interface controlada.

Ligue primeiro apenas uma cópia descartável do serviço, utilizando portas alternativas e sem acesso aos pares de produção. Se a aplicação indicar atualizações do esquema ou um estado corrompido, pare e restaure novamente o volume a partir do artefacto inalterado depois de resolver a compatibilidade entre versões.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Faça a mudança e mantenha um anfitrião para reversão

Inicie as dependências antes da aplicação, verifique os registos, o início de sessão, os registos recentes, os anexos, as tarefas agendadas e uma escrita descartável. Reinicie a stack de destino e confirme que esta volta a anexar o mesmo volume nomeado. Atualize o proxy ou o DNS apenas depois de estas verificações passarem.

O artigo relacionado da ZimaSpace sobre cópias de segurança consistentes dos dados de contentores é útil se o destino iniciar vazio apesar de uma cópia bem-sucedida. Compare a origem da montagem em runtime com o volume pretendido antes de copiar novamente os dados; cópias repetidas para o destino errado apenas aumentam a ambiguidade.

Mantenha a aplicação de origem parada e o volume antigo apenas para leitura até que uma nova cópia de segurança e um teste de restauração sejam bem-sucedidos no destino. Faça a reversão devolvendo o tráfego à origem inalterada apenas se não tiverem sido aceites novas escritas no destino; caso contrário, pare e reconcilie os dados deliberadamente.