Uma lista de verificação pré-atualização para contentores Jellyfin e respetivas dependências

Antes de atualizar um contentor Jellyfin, preserve ambos os lados da implementação: o estado persistente do Jellyfin e a definição exata do contentor que sabe como aceder-lhe. É fácil obter uma nova imagem; recuperar uma base de dados migrada, um ponto de montagem alterado ou um mapeamento de dispositivo esquecido não é.

Utilize a lista de verificação pela ordem das dependências. Primeiro, confirme que consegue recuperar os dados; depois, registe a imagem atual e as definições de execução; em seguida, consulte o percurso de lançamento; só então substitua a imagem. Depois, teste as mesmas bibliotecas, utilizadores, modos de reprodução, tarefas agendadas e comportamento após reinício antes de eliminar a cópia de reversão.

Registe a Última Imagem Funcional e a Definição do Contentor

Guarde a etiqueta da imagem Jellyfin atual e, quando possível, o respetivo digest. Exporte ou copie o ficheiro Compose ou a definição da aplicação que contém portas, redes, pontos de montagem, valores de ambiente, política de reinício, mapeamento de utilizadores, grupos suplementares, dispositivos GPU e qualquer relação com um proxy inverso.

A documentação oficial do contentor Jellyfin distingue etiquetas móveis, como latest, de etiquetas explícitas de versão principal, secundária e de correção. comportamento das etiquetas da imagem Jellyfin Uma reversão é mais fácil quando conhece a versão funcional exata, em vez de se lembrar apenas de que a “mais recente funcionava ontem”.

Não elimine a imagem antiga nem apague a definição guardada até a nova versão passar o período completo de validação. Se a atualização falhar antes de alterar os dados persistentes, a imagem e a definição retidas oferecem o caminho de recuperação menos invasivo.

Crie uma Cópia de Segurança Recuperável do Estado do Jellyfin

Proteja os diretórios de dados e configuração do Jellyfin antes de alterar a imagem. A cópia de segurança deve estar fora do caminho da aplicação em funcionamento e ser legível de forma independente; uma segunda cópia ou instantâneo no mesmo conjunto de dados só é útil se compreender contra que falha oferece proteção.

A documentação de cópia de segurança do Jellyfin alerta para o facto de as atualizações poderem exigir a restauração dos dados, uma vez que não existe um mecanismo geral de reversão depois de as migrações serem aplicadas. Também documenta as cópias de segurança integradas e o requisito de paragem limpa para cópias manuais de ficheiros. orientações do Jellyfin sobre cópia de segurança e restauro

Num fluxo de trabalho com contentores, o mesmo princípio é abrangido pelo fluxo de trabalho da ZimaSpace para criar um ponto de reversão antes da atualização. Pare aqui se não conseguir identificar os caminhos persistentes ou verificar o conteúdo da cópia de segurança.

Registe os Pontos de Montagem, UID/GID e Dependências de Hardware

Liste todos os pontos de montagem de ligação e volumes nomeados e indique se são só de leitura ou graváveis. Registe o UID/GID de execução, as associações a grupos e o proprietário dos diretórios de dados pertencentes ao Jellyfin. Capture também os mapeamentos da GPU ou dos dispositivos de renderização se a aceleração por hardware estiver ativada.

O guia de contentores do Jellyfin mostra que os conteúdos multimédia, a configuração e a cache são montados separadamente e que o contentor pode ser executado com um UID/GID especificado. caminhos persistentes e mapeamento de utilizadores Estes valores são dependências, não meros detalhes: um contentor recriado pode iniciar corretamente e, ainda assim, ver um diretório de configuração vazio ou perder permissões para aceder a um dispositivo.

Compare a definição guardada com o contentor em execução efetivo, não apenas com um modelo que pensa estar atualizado. Se o ambiente de execução tiver alterações manuais ausentes do Compose ou da definição da aplicação NAS, corrija essa divergência antes de atualizar, para que a implementação antiga possa ser reproduzida.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verifique o Percurso de Atualização Suportado e os Riscos dos Plugins

Leia as notas de lançamento de cada transição de versão principal entre a versão atual e a versão pretendida. Procure versões intermédias obrigatórias, migrações da base de dados, alterações de configuração, compatibilidade de plugins, requisitos do FFmpeg ou operações de arranque demoradas.

A documentação de atualização do Jellyfin realça repetidamente a importância das cópias de segurança e explica por que motivo as alterações ao esquema podem impossibilitar uma reversão simples. limites de atualização e reversão As notas de lançamento das versões principais podem acrescentar pré-requisitos específicos, por isso não presuma que uma transição é segura apenas porque a imagem do contentor existe.

Se um plugin for essencial, confirme que existe uma versão compatível antes de atualizar o servidor. Se um plugin for opcional e tiver um historial de impedir o arranque, registe a versão atual e esteja preparado para desativar apenas esse plugin se os registos do novo servidor o identificarem como a origem da falha.

Faça a Atualização sem Alterar a Fronteira do Estado

Pare o Jellyfin de forma limpa, obtenha a imagem pretendida e recrie apenas o serviço Jellyfin com os mesmos caminhos persistentes verificados e as mesmas dependências de execução. Não combine a atualização com uma migração de armazenamento, uma reformulação de UID/GID, uma reconfiguração do proxy inverso e uma reconfiguração da GPU, a menos que essas alterações sejam o verdadeiro objetivo da manutenção.

Observe o primeiro registo de arranque. Uma migração pode legitimamente demorar algum tempo numa biblioteca grande, enquanto uma mensagem imediata de “permissão negada”, base de dados vazia, caminho em falta ou esquema incompatível aponta para outro ramo de diagnóstico. Não reinicie repetidamente uma migração apenas porque a interface de utilizador não ficou imediatamente disponível.

Se o contentor abrir como um servidor novo, pare-o antes de configurar qualquer coisa. Normalmente, esse sintoma significa que o novo serviço está a apontar para o estado persistente errado. Corrija primeiro o mapeamento do ponto de montagem; configurar uma nova instância vazia pode criar ficheiros novos que dificultam o caminho de recuperação.

Valide a Nova Versão Antes de Remover os Recursos de Reversão

Verifique a identidade do servidor original, os utilizadores, as bibliotecas, os metadados e as definições importantes. Reproduza um item em Reprodução Direta e uma transcodificação representativa e, em seguida, execute ou observe uma tarefa agendada relevante para a sua configuração. Verifique nos registos a existência de erros recorrentes de migração, base de dados, permissões e FFmpeg.

Reinicie o contentor uma vez após a primeira sessão bem-sucedida. A nova versão só está totalmente validada quando consegue reabrir os mesmos dados e dispositivos após uma recriação ou reinício limpo. Isto deteta uma dependência acidental de um ponto de montagem temporário ou de um estado de execução transitório.

Conserve a cópia de segurança anterior à atualização, a referência da imagem anterior e a definição guardada até o servidor ter passado o período normal de carga de trabalho. Se for necessária uma reversão depois de uma migração da base de dados, siga o limite de restauro documentado pelo Jellyfin, em vez de apontar uma imagem antiga para um estado já migrado.