É possível reverter a imagem de um contentor sem perder os dados da aplicação?
Sim, pode reverter uma imagem de contentor sem perder os dados da aplicação quando o estado persistente está fora do contentor e continua compatível com a versão anterior.
Numa NAS doméstica, substituir a imagem normalmente recria apenas o ambiente de execução da aplicação, enquanto os volumes nomeados ou os bind mounts preservam bases de dados, definições e ficheiros do utilizador. O limite perigoso é a alteração do esquema: uma imagem mais recente pode migrar a base de dados ou reescrever a configuração de uma forma que a imagem anterior não consiga ler. Antes de reverter, registe as montagens atuais, a identidade da imagem, a configuração, os segredos e faça uma cópia de segurança consistente dos dados.
Congele o estado atual antes de alterar a imagem
Interrompa as atualizações automáticas de imagens e registe a tag atual da imagem, o resumo imutável, a configuração do contentor, as variáveis de ambiente, as redes, as portas, as montagens, a política de reinício e a verificação de estado. Guarde o ficheiro Compose ou a configuração exportada separadamente do contentor.
Um fluxo de reversão de contentores numa NAS recomenda manter disponível uma imagem anterior conhecida, em vez de depender de uma tag dinâmica latest. O ponto de recuperação utilizável é a versão específica da imagem anterior, juntamente com a configuração que a executava.
Faça uma cópia de segurança ou um instantâneo consistente da base de dados da aplicação antes de parar a versão mais recente. Não parta do princípio de que o volume existente é uma cópia para reversão, pois pode já conter alterações ao esquema ou aos dados efetuadas pela atualização.
Confirme que os dados da aplicação estão fora da camada gravável
Associe todos os volumes nomeados e bind mounts e identifique quaisquer bases de dados, carregamentos, plug-ins, certificados, caches ou configurações que ainda estejam armazenados apenas na camada gravável do contentor.
O armazenamento persistente só sobrevive à substituição do contentor quando o novo contentor se liga novamente à mesma localização de dados externa. O fluxo de trabalho de alteração da versão da imagem do SynoForum verifica explicitamente se os dados dos volumes permanecem no armazenamento da NAS antes de recriar um contentor a partir de outra imagem.
Se existirem dados críticos apenas na camada gravável, copie-os ou exporte-os antes de remover o contentor atual. Considere essa extração um passo de recuperação, não uma razão para manter indefinidamente um contentor sem versão.
Fixe a imagem anterior exata em vez de reutilizar latest
Transfira ou localize a última tag ou resumo conhecido como funcional e atualize apenas a referência da imagem. Verifique a arquitetura, a edição da aplicação e as variáveis de ambiente necessárias antes de recriar o serviço.
Os utilizadores que revertem serviços geridos pelo Compose costumam regressar a uma versão explícita anterior da imagem, em vez de pedir ao Docker que reverta um contentor em execução. Uma discussão prática sobre reversões centra-se na alteração da tag fixada da imagem no Compose e na recriação do serviço.
Não utilize uma imagem antiga em cache cuja identidade seja desconhecida. Registe o resumo depois de a transferir, para que outra compilação não selecione silenciosamente um binário diferente sob a mesma tag mutável.
Verifique se a versão mais recente alterou a base de dados
Leia as notas de lançamento e os registos de migração da aplicação relativos às versões entre o destino da reversão e a imagem atual. Procure alterações irreversíveis ao esquema, reescritas da configuração, alterações das chaves de encriptação ou atualizações de plug-ins.
A reversão da base de dados é mais difícil do que a reversão da imagem, porque o código da aplicação e o esquema têm de permanecer compatíveis. A Octopus descreve as migrações compatíveis com versões anteriores como um requisito quando versões antigas e novas da aplicação podem coexistir ou ser revertidas, tornando a compatibilidade do esquema entre versões o limite decisivo da reversão.
Se a imagem anterior não conseguir ler a base de dados migrada, restaure a cópia de segurança da base de dados anterior à atualização, em vez de apontar o código antigo para o estado novo. Preserve a base de dados atual separadamente, caso seja necessário anular a própria reversão.
Recrie o serviço com os mesmos caminhos persistentes
Pare e recrie o contentor da aplicação utilizando a imagem anterior, mantendo os mesmos volumes nomeados ou bind mounts verificados. Não utilize comandos ou opções da interface que removam volumes.
Mantenha consistentes os nomes das redes, os aliases dos serviços, as portas publicadas, os mapeamentos UID/GID, os segredos e os destinos do proxy inverso, salvo se a versão anterior exigir uma diferença documentada. Um arranque bem-sucedido do contentor com as montagens erradas pode criar uma aplicação nova e vazia, parecendo uma perda de dados.
Inspecione a lista de montagens e os registos da aplicação antes de iniciar sessão ou permitir a execução de tarefas em segundo plano. Se a aplicação inicializar uma base de dados nova, pare imediatamente e corrija o caminho dos dados, em vez de importar dados para a localização errada.
Valide a reversão e mantenha um caminho de recuperação para a versão mais recente
Teste o início de sessão, as leituras e escritas na base de dados, os carregamentos, as tarefas agendadas, as integrações e um reinício controlado. Compare uma amostra dos registos e ficheiros com o inventário anterior à reversão.
O fluxo de trabalho da ZimaSpace para instantâneos dos dados das aplicações antes das atualizações proporciona o passo de preparação mais seguro para futuras atualizações.
A reversão só está concluída quando a imagem anterior utiliza os dados persistentes pretendidos, o esquema é compatível ou foi restaurado e o serviço sobrevive a outra recriação. Mantenha a imagem mais recente, a respetiva cópia de segurança dos dados e as notas da reversão até a versão anterior permanecer estável durante o período normal de utilização.
Produtos recomendados
Suporte e Dicas
Mais para Ler
O Plex pode partilhar uma GPU com outro contentor Docker?
O Plex e outro contentor conseguem frequentemente aceder à mesma GPU, mas é necessário testar o suporte dos controladores, o mapeamento de dispositivos, a...
Como saber se um erro do Plex vem do cliente ou do servidor
Reproduza o mesmo item noutro cliente, compare o percurso da sessão e, em seguida, recolha provas do servidor apenas depois de o âmbito lhe...
Como configurar a cache do Plex e o armazenamento temporário de transcodificação
Proteja o estado persistente do Plex enquanto coloca os ficheiros temporários de transcodificação num armazenamento local adequado e, em seguida, verifique a limpeza, o...
