Lista kontrolna przed aktualizacją kontenerów Jellyfin i zależności

Przed aktualizacją kontenera Jellyfin zabezpiecz oba elementy wdrożenia: trwały stan Jellyfin oraz dokładną definicję kontenera, która określa, jak uzyskać do niego dostęp. Pobranie nowego obrazu jest łatwe. Odzyskanie zmigrowanej bazy danych, zmienionego punktu montowania lub zapomnianego mapowania urządzeń już nie.

Wykonuj czynności z listy kontrolnej w kolejności uwzględniającej zależności. Najpierw upewnij się, że możesz odzyskać dane, następnie zapisz aktualny obraz i ustawienia uruchomieniowe, potem sprawdź ścieżkę aktualizacji i dopiero wtedy zastąp obraz. Następnie przetestuj te same biblioteki, konta użytkowników, tryby odtwarzania, zaplanowane zadania i zachowanie po restarcie, zanim usuniesz kopię umożliwiającą powrót do poprzedniej wersji.

Zapisz ostatni działający obraz i definicję kontenera

Zapisz aktualny tag obrazu Jellyfin, a jeśli to możliwe, również jego digest. Wyeksportuj lub skopiuj plik Compose albo definicję aplikacji zawierającą porty, sieci, punkty montowania, wartości zmiennych środowiskowych, zasady restartu, mapowanie użytkowników, grupy dodatkowe, urządzenia GPU oraz ewentualne powiązanie z odwrotnym serwerem proxy.

Oficjalna dokumentacja kontenerów Jellyfin rozróżnia zmienne tagi, takie jak latest, od tagów wskazujących konkretną wersję główną, poboczną lub poprawkową. Zasady działania tagów obrazów Jellyfin Powrót do poprzedniej wersji jest łatwiejszy, gdy znasz dokładną działającą wersję, zamiast tylko pamiętać, że „wczoraj działało latest”.

Nie usuwaj starego obrazu ani zapisanej definicji, dopóki nowa wersja nie przejdzie pełnego okresu weryfikacji. Jeśli aktualizacja nie powiedzie się, zanim dojdzie do zmian w trwałych danych, zachowany obraz i definicja zapewnią najmniej inwazyjną ścieżkę odzyskiwania.

Utwórz kopię zapasową stanu Jellyfin, którą można przywrócić

Zabezpiecz katalogi danych i konfiguracji Jellyfin przed zmianą obrazu. Kopia zapasowa musi znajdować się poza ścieżką używaną przez działającą aplikację i być niezależnie od niej dostępna. Druga kopia lub migawka na tym samym zbiorze danych jest przydatna tylko wtedy, gdy wiesz, przed jakim rodzajem awarii chroni.

Dokumentacja kopii zapasowych Jellyfin ostrzega, że aktualizacja może wymagać przywrócenia danych, ponieważ po zastosowaniu migracji nie ma ogólnego sposobu na powrót do poprzedniej wersji. Opisuje też wbudowane kopie zapasowe oraz wymóg czystego zatrzymania aplikacji przed ręcznym kopiowaniem plików. Wskazówki Jellyfin dotyczące tworzenia i przywracania kopii zapasowych

W przypadku kontenerów tę samą zasadę opisuje procedura ZimaSpace tworzenia punktu przywracania przed aktualizacją. Zatrzymaj się tutaj, jeśli nie potrafisz wskazać trwałych ścieżek lub zweryfikować zawartości kopii zapasowej.

Zapisz informacje o podłączonych zasobach, UID/GID i zależnościach sprzętowych

Wymień wszystkie podłączone katalogi i nazwane woluminy, zaznaczając, czy są tylko do odczytu, czy też można w nich zapisywać. Zapisz identyfikatory UID/GID środowiska uruchomieniowego, członkostwo w grupach oraz właściciela katalogów danych Jellyfin. Jeśli włączono akcelerację sprzętową, zapisz również mapowania procesora graficznego lub urządzeń renderujących.

Przewodnik Jellyfin dotyczący kontenerów pokazuje, że katalogi z multimediami, konfiguracją i pamięcią podręczną są podłączane osobno, a kontener może działać z określonym identyfikatorem UID/GID. trwałe ścieżki i mapowanie użytkowników Te wartości są zależnościami, a nie ozdobnikami: odtworzony kontener może uruchomić się poprawnie, ale zobaczyć pusty katalog konfiguracji lub utracić dostęp do urządzenia.

Porównaj zapisaną definicję z faktycznie działającym kontenerem, a nie tylko z szablonem, który uważasz za aktualny. Jeśli konfiguracja środowiska uruchomieniowego zawiera ręczne zmiany, których brakuje w Compose lub definicji aplikacji NAS, usuń te rozbieżności przed aktualizacją, aby można było odtworzyć poprzednie wdrożenie.

Featured

Osobista chmura i domowy NAS ZimaCube 2

ZimaCube2

$799.00 - $2,499.00

Buy Now

Sprawdź obsługiwaną ścieżkę aktualizacji i ryzyko związane z wtyczkami

Przeczytaj informacje o wydaniu dla każdej głównej wersji pośredniej między wersją bieżącą a docelową. Sprawdź wymagane wersje pośrednie, migracje baz danych, zmiany konfiguracji, zgodność wtyczek, wymagania FFmpeg oraz długotrwałe zadania wykonywane podczas uruchamiania.

Dokumentacja aktualizacji Jellyfin wielokrotnie podkreśla znaczenie kopii zapasowych i wyjaśnia, dlaczego zmiany schematu mogą uniemożliwić proste przywrócenie starszej wersji. granice aktualizacji i przywracania starszej wersji Informacje o głównych wydaniach mogą zawierać wymagania wstępne dotyczące konkretnych wersji, więc nie zakładaj, że można bezpiecznie pominąć wersje pośrednie tylko dlatego, że istnieje obraz kontenera.

Jeśli wtyczka jest niezbędna, przed aktualizacją serwera upewnij się, że dostępna jest zgodna wersja. Jeśli wtyczka jest opcjonalna i wcześniej blokowała uruchamianie, zanotuj jej bieżącą wersję i przygotuj się na wyłączenie tylko tej wtyczki, jeśli dzienniki nowego serwera wskażą ją jako źródło problemu.

Przeprowadź aktualizację bez zmiany granicy stanu

Zatrzymaj Jellyfin w prawidłowy sposób, pobierz wybrany obraz i odtwórz wyłącznie usługę Jellyfin, zachowując te same zweryfikowane ścieżki trwałych danych i zależności środowiska uruchomieniowego. Nie łącz aktualizacji z migracją pamięci masowej, zmianą projektu UID/GID, przebudową konfiguracji odwrotnego serwera proxy ani zmianą konfiguracji GPU, chyba że właśnie te zmiany są celem prac serwisowych.

Obserwuj dziennik przy pierwszym uruchomieniu. Migracja dużej biblioteki może zgodnie z oczekiwaniami zająć trochę czasu, natomiast natychmiastowy komunikat „permission denied”, informacja o pustej bazie danych, brakującej ścieżce lub niezgodnym schemacie wskazuje na inny problem. Nie uruchamiaj wielokrotnie ponownie migracji tylko dlatego, że interfejs nie jest od razu dostępny.

Jeśli kontener uruchomi się jako nowy serwer, zatrzymaj go przed rozpoczęciem konfiguracji. Taki objaw zwykle oznacza, że nowa usługa wskazuje niewłaściwy trwały stan. Najpierw popraw mapowanie montowań; konfiguracja nowej, pustej instancji może utworzyć pliki, które utrudnią odzyskanie poprzedniego stanu.

Zweryfikuj nową wersję przed usunięciem zasobów umożliwiających przywrócenie poprzedniego stanu

Sprawdź, czy zachowano tożsamość oryginalnego serwera, użytkowników, bibliotek, metadanych i ważnych ustawień. Odtwórz jeden materiał w trybie Direct Play i jeden reprezentatywny materiał transkodowany, a następnie uruchom zaplanowane zadanie ważne dla Twojej konfiguracji lub sprawdź, jak przebiega. Przejrzyj dzienniki pod kątem powtarzających się błędów migracji, bazy danych, uprawnień i FFmpeg.

Po pierwszej udanej sesji raz uruchom ponownie kontener. Nowa wersja nie jest w pełni zweryfikowana, dopóki po czystym odtworzeniu lub ponownym uruchomieniu nie potrafi otworzyć tych samych danych i urządzeń. Pozwala to wykryć przypadkowe poleganie na tymczasowym montowaniu lub stanie środowiska uruchomieniowego.

Zachowaj kopię zapasową sprzed aktualizacji, odwołanie do poprzedniego obrazu i zapisaną definicję do czasu, aż serwer przejdzie normalny okres obciążenia. Jeśli po migracji bazy danych konieczne będzie przywrócenie poprzedniej wersji, zastosuj udokumentowane przez Jellyfin granice przywracania zamiast uruchamiać starszy obraz ze stanem po migracji.