É possível restaurar um contentor sem substituir toda a pilha de aplicações?

Sim, é possível restaurar um único contentor de forma independente quando a respetiva configuração, os dados persistentes e os limites das dependências estão claramente separados do resto da stack.

Num NAS doméstico, o contentor visível é normalmente descartável, mas o estado da aplicação pode abranger montagens bind, volumes nomeados, uma base de dados separada, segredos, rotas de proxy e redes partilhadas. Por isso, um restauro seguro de um único serviço não significa copiar um ID de contentor para o lugar; significa congelar o serviço afetado, restaurar apenas o estado que lhe pertence, recriá-lo a partir de uma definição conhecida e confirmar que as dependências partilhadas e os contentores vizinhos saudáveis permanecem inalterados.

Defina a Unidade de Restauro Antes de Parar Qualquer Serviço

Identifique o serviço exato que falhou e liste todos os objetos que lhe pertencem: nome do serviço no Compose, etiqueta ou digest da imagem, ficheiro de ambiente, segredos, montagens bind, volumes nomeados, portas publicadas, aliases de rede, tarefas agendadas e etiquetas do proxy reverso.

Os guias de restauro de volumes Docker separam o runtime do contentor do armazenamento persistente, porque o volume de dados pode ser salvaguardado e restaurado de forma independente. Um guia prático demonstra um restauro separado do contentor e do volume, em vez de considerar o contentor em execução como o único objeto de recuperação.

Se a aplicação escrever numa base de dados ou num volume partilhado, a unidade de restauro inclui essa dependência partilhada e pode deixar de estar devidamente isolada. Pare antes de substituir qualquer elemento, até que a propriedade esteja claramente definida.

Capture a Stack Saudável e o Estado do Serviço com Falhas

Exporte ou guarde o ficheiro Compose atual, o ambiente resolvido, os digests das imagens, a lista de montagens, a participação nas redes, o estado de funcionamento e os registos recentes. Registe quais os serviços vizinhos que estão saudáveis, para que o restauro tenha um limite claro de não intervenção.

Uma operação do Compose ao nível do serviço pode visar um serviço nomeado, em vez de reiniciar tudo. O fluxo de trabalho de serviço único do Linux Handbook distingue um único serviço Compose das ações aplicadas a toda a stack, mas também salienta que as alterações de configuração exigem a recriação, e não apenas um reinício.

Desative as atualizações automáticas e os ciclos de reinício apenas para o serviço com falhas. Mantenha as bases de dados e a infraestrutura partilhada em execução, salvo se a consistência exigir uma paragem coordenada.

Restaure Primeiro os Dados numa Localização Isolada

Restaure a cópia de segurança selecionada para um diretório temporário ou um volume novo, em vez de diretamente sobre o caminho ativo. Compare a contagem de ficheiros, a propriedade, os carimbos de data e hora, os metadados do dump da base de dados e a versão da aplicação com o estado danificado.

Um projeto de cópia de segurança de volumes documenta a utilização de um contentor temporário criado especificamente para montar e repovoar um volume de destino, criando um caminho de restauro de volumes isolado antes de o serviço de produção escrever nele.

Para bases de dados, utilize um método de dump ou restauro compatível com a aplicação sempre que estiver disponível. Uma cópia do sistema de ficheiros de uma base de dados em execução pode, na melhor das hipóteses, ser consistente após uma falha e pode deixar de funcionar depois de o contentor antigo desaparecer.

Valide a cópia isolada antes de trocar as montagens. Se a cópia de segurança não puder ser lida ou o respetivo esquema não corresponder à imagem pretendida, preserve o estado atual e escolha outro ponto de recuperação.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Recrie Apenas o Serviço com Falhas, Mantendo a Identidade Original

Recrie o serviço nomeado a partir da definição Compose guardada, mantendo o mesmo nome de projeto, as redes externas, os aliases de serviço, as portas, os segredos, o mapeamento UID/GID e os caminhos persistentes verificados.

O acesso às montagens pode continuar a falhar depois de um restauro correto dos dados quando a propriedade ou as etiquetas de segurança já não correspondem ao utilizador do runtime. Num caso com um contentor Rocky Linux, o acesso em falta ao volume foi resolvido verificando a propriedade e o contexto de segurança, em vez de copiar novamente os dados.

Inicie o serviço sem eliminar volumes nem executar comandos prune aplicados a toda a stack. Inspecione as montagens efetivas antes de permitir que migrações, análises ou tarefas em segundo plano modifiquem os dados restaurados.

Volte a Ligar as Dependências sem as Restaurar

Teste a resolução DNS e o acesso TCP, a partir do contentor restaurado, à base de dados, à cache, ao fornecedor de identidade, ao armazenamento de objetos e à rede do proxy. Utilize os mesmos nomes de serviço e credenciais definidos na configuração recuperada.

Se uma dependência partilhada permaneceu saudável, não a restaure nem substitua apenas porque a aplicação não consegue estabelecer ligação. Um alias de rede em falta, um segredo alterado, uma incompatibilidade de esquema ou um nome de base de dados incorreto podem fazer com que uma dependência válida pareça indisponível.

Execute migrações apenas quando a versão restaurada da aplicação e a cópia de segurança da base de dados as exigirem. Faça uma cópia de segurança da dependência antes de qualquer migração irreversível e pare se a aplicação tentar inicializar uma base de dados vazia.

Valide o Limite do Serviço Único Antes de Repor o Tráfego

Teste o início de sessão, as leituras, as escritas, os carregamentos, as tarefas agendadas, as chamadas à API, o acesso através do proxy e um reinício controlado. Compare as contagens de reinícios dos contentores vizinhos, os registos, as portas e as somas de verificação dos dados com a captura efetuada antes do restauro.

O guia da ZimaSpace sobre mapeamento do estado persistente de contentores apresenta o mesmo princípio de recuperação: restaure o proprietário do estado, e não uma shell de contentor presumida.

O restauro só está concluído quando o serviço recuperado utiliza os dados e as dependências pretendidos, os elementos saudáveis da stack permanecem intocados e uma nova recriação produz o mesmo resultado. Se o estado partilhado não puder ser isolado, avance para um restauro coordenado da stack em vez de forçar uma reversão parcial.