Uma lista de verificação pré-atualização para contentores Jellyfin e 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 imagem nova; recuperar uma base de dados migrada, uma montagem alterada ou um mapeamento de dispositivos esquecido não é.

Siga 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; a seguir, consulte o percurso de atualização e só então substitua a imagem. Depois, teste as mesmas bibliotecas, os mesmos utilizadores, modos de reprodução, tarefas agendadas e comportamento de 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, sempre que possível, o respetivo digest. Exporte ou copie o ficheiro Compose ou a definição da aplicação que contém as portas, as redes, as montagens, os valores de ambiente, a política de reinício, o mapeamento de utilizadores, os grupos suplementares, os dispositivos GPU e qualquer ligação a um proxy inverso.

A documentação oficial dos contentores Jellyfin distingue etiquetas móveis, como latest, de etiquetas explícitas de versão principal, secundária e de correção. Comportamento das etiquetas de imagem do Jellyfin É mais fácil reverter se souber qual era a versão exata que funcionava, em vez de apenas se lembrar de que «ontem a latest funcionava».

Não remova a imagem antiga nem elimine a definição guardada até a nova versão passar todo o período de validação. Se a atualização falhar antes de afetar os dados persistentes, manter a imagem e a definição dá-lhe o caminho de recuperação menos intrusivo.

Crie uma cópia de segurança recuperável do estado do Jellyfin

Proteja os diretórios de dados e de configuração do Jellyfin antes de alterar a imagem. A cópia de segurança tem de ficar fora do caminho da aplicação em execução e ser legível de forma independente; uma segunda cópia ou um instantâneo no mesmo conjunto de dados só é útil se souber que tipo de falha permite resolver.

A documentação de cópias de segurança do Jellyfin alerta que as atualizações podem exigir a reposição de dados, uma vez que não existe um mecanismo geral para reverter a atualização depois de aplicadas migrações. Também documenta as cópias de segurança integradas e a necessidade de parar corretamente o serviço antes de copiar ficheiros manualmente. Orientações do Jellyfin para cópias de segurança e restauro

Num fluxo de trabalho com contentores, o mesmo princípio é abordado pelo processo de criação de um ponto de reversão antes da atualização do ZimaSpace. 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, o UID/GID e as dependências de hardware

Registe todos os volumes montados, por ligação ou nome, e indique se são só de leitura ou se permitem escrita. Registe o UID/GID de execução, as associações a grupos e a propriedade dos diretórios de dados do Jellyfin. Registe também os mapeamentos da GPU ou dos dispositivos de renderização, caso a aceleração por hardware esteja ativada.

O guia de contentores do Jellyfin mostra que os diretórios de multimédia, configuração e 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 elementos decorativos: um contentor recriado pode arrancar corretamente, mas encontrar um diretório de configuração vazio ou perder o acesso a um dispositivo.

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

Featured

NAS de nuvem pessoal doméstica ZimaCube 2

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verifique o caminho de atualização suportado e os riscos para os plug-ins

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

A documentação de atualização do Jellyfin insiste repetidamente na importância das cópias de segurança e explica porque as alterações ao esquema podem impossibilitar uma simples regressão. limites entre atualizações e regressões As notas das versões principais podem acrescentar pré-requisitos específicos da versão, por isso não presuma que é seguro saltar versões só porque a imagem do contentor existe.

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

Faça a atualização sem alterar os limites do estado

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

Acompanhe o registo do primeiro arranque. Uma migração pode demorar legitimamente numa biblioteca grande, enquanto mensagens imediatas como «permission denied», base de dados vazia, caminho inexistente ou esquema incompatível apontam para outro problema. Não reinicie repetidamente uma migração só porque a interface ainda não está disponível.

Se o contentor abrir como um servidor novo, pare-o antes de configurar seja o que for. Esse sintoma costuma indicar que o novo serviço está a apontar para o estado persistente errado. Corrija primeiro o mapeamento das montagens; configurar uma nova instância vazia pode criar ficheiros que dificultam o processo de recuperação.

Valide a nova versão antes de remover os recursos de reversão

Verifique a identidade original do servidor, os utilizadores, as bibliotecas, os metadados e as definições importantes. Reproduza um conteúdo com Direct Play e outro que represente uma transcodificação; em seguida, execute ou observe uma tarefa agendada importante para a sua configuração. Verifique os registos à procura 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 dependências acidentais de uma montagem temporária ou do estado do runtime.

Mantenha 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 pelo período normal de carga de trabalho. Se for necessário reverter após uma migração da base de dados, siga os limites de restauro documentados pelo Jellyfin, em vez de apontar uma imagem mais antiga para um estado já migrado.