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

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

A Pre-Upgrade Checklist for Jellyfin Containers and Dependencies - Zima Store Online

Przed aktualizacją kontenera Jellyfin zabezpiecz obie strony wdrożenia: trwały stan Jellyfin oraz dokładną definicję kontenera, która określa sposób uzyskiwania do niego dostępu. Nowy obraz można łatwo pobrać, ale odzyskanie zmigrowanej bazy danych, zmienionego montowania lub zapomnianego mapowania urządzenia już nie.

Skorzystaj z listy kontrolnej uporządkowanej według zależności. Najpierw upewnij się, że potrafisz odzyskać dane, następnie zapisz bieżący obraz i ustawienia środowiska uruchomieniowego, potem zapoznaj się ze ścieżką wydania i dopiero wtedy zastąp obraz. Po aktualizacji przetestuj te same biblioteki, użytkowników, tryby odtwarzania, zaplanowane zadania i zachowanie po ponownym uruchomieniu, zanim usuniesz kopię umożliwiającą wycofanie zmian.

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

Zapisz bieżący tag obrazu Jellyfin oraz, jeśli to możliwe, jego skrót. Wyeksportuj lub skopiuj plik Compose albo definicję aplikacji zawierającą porty, sieci, montowania, wartości zmiennych środowiskowych, zasadę ponownego uruchamiania, mapowanie użytkownika, dodatkowe grupy, urządzenia GPU oraz ewentualne powiązanie z odwrotnym serwerem proxy.

Oficjalna dokumentacja kontenera Jellyfin rozróżnia ruchome tagi, takie jak latest, od jawnie określonych tagów głównych, drugorzędnych i poprawek. Zachowanie tagów obrazu Jellyfin Wycofanie zmian jest łatwiejsze, 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ę przed modyfikacją trwałych danych, zachowany obraz i definicja zapewnią najmniej inwazyjną ścieżkę odzyskiwania.

Utwórz możliwą do odzyskania kopię zapasową stanu Jellyfin

Zabezpiecz katalogi danych i konfiguracji Jellyfin przed zmianą obrazu. Kopia zapasowa musi znajdować się poza aktywną ścieżką aplikacji i być niezależnie od niej odczytywalna; druga kopia lub migawka na tym samym zbiorze danych jest przydatna tylko wtedy, gdy rozumiesz, przed jaką awarią chroni.

Dokumentacja tworzenia kopii zapasowych Jellyfin ostrzega, że aktualizacje mogą wymagać przywrócenia danych, ponieważ po zastosowaniu migracji nie istnieje ogólny mechanizm obniżania wersji. Dokumentuje także wbudowane kopie zapasowe oraz wymóg czystego zatrzymania aplikacji podczas ręcznego kopiowania plików. Wskazówki Jellyfin dotyczące tworzenia kopii zapasowych i przywracania

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

Zarejestruj montowania, UID/GID i zależności sprzętowe

Wyświetl wszystkie montowania wiązane i nazwane wolumeny oraz zanotuj, czy są tylko do odczytu, czy z możliwością zapisu. Zapisz identyfikator UID/GID środowiska uruchomieniowego, członkostwo w grupach oraz właściciela katalogów danych należących do Jellyfin. Zarejestruj także mapowania GPU lub urządzeń renderujących, jeśli włączone jest przyspieszanie sprzętowe.

Przewodnik Jellyfin dotyczący kontenerów pokazuje, że multimedia, konfiguracja i pamięć podręczna są montowane oddzielnie oraz że kontener może działać z określonym UID/GID. trwałe ścieżki i mapowanie użytkownika Te wartości są zależnościami, a nie ozdobnikami: odtworzony kontener może uruchomić się poprawnie, jednocześnie widząc pusty katalog konfiguracji lub tracąc uprawnienia 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 środowisko uruchomieniowe zawiera ręczne zmiany nieuwzględnione w Compose lub definicji aplikacji NAS, usuń te rozbieżności przed aktualizacją, aby można było odtworzyć stare wdrożenie.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

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

Przeczytaj informacje o wydaniu dla każdej głównej granicy między bieżącą a docelową wersją. Poszukaj wymaganych wersji pośrednich, migracji bazy danych, zmienionej konfiguracji, zgodności wtyczek, wymagań FFmpeg lub długotrwałych operacji podczas uruchamiania.

Dokumentacja aktualizacji Jellyfin wielokrotnie podkreśla znaczenie kopii zapasowych i wyjaśnia, dlaczego zmiany schematu mogą uniemożliwić proste obniżenie wersji. granice aktualizacji i obniżania wersji Informacje o wydaniu głównych wersji mogą zawierać wymagania wstępne zależne od konkretnej wersji, dlatego nie zakładaj bezpiecznego przejścia tylko dlatego, że obraz kontenera istnieje.

Jeśli wtyczka jest niezbędna, przed aktualizacją serwera potwierdź dostępność zgodnej wersji. Jeśli wtyczka jest opcjonalna i wcześniej blokowała uruchamianie, zapisz jej bieżącą wersję i przygotuj się do wyłączenia wyłącznie tej wtyczki, jeśli nowe logi serwera wskażą ją jako źródło problemu.

Wykonaj aktualizację bez zmiany granicy stanu

Poprawnie zatrzymaj Jellyfin, pobierz zamierzony obraz i odtwórz wyłącznie usługę Jellyfin, używając tych samych zweryfikowanych trwałych ścieżek i zależności środowiska uruchomieniowego. Nie łącz aktualizacji z migracją pamięci masowej, zmianą projektu UID/GID, przebudową odwrotnego serwera proxy ani rekonfiguracją GPU, chyba że właśnie te zmiany są celem prac serwisowych.

Obserwuj log pierwszego uruchomienia. Migracja może prawidłowo trwać długo w przypadku dużej biblioteki, natomiast natychmiastowy komunikat „permission denied”, pusta baza danych, brak ścieżki lub niezgodny schemat wskazuje na inną przyczynę. Nie uruchamiaj wielokrotnie migracji tylko dlatego, że interfejs nie jest od razu dostępny.

Jeśli kontener otworzy się jako nowy serwer, zatrzymaj go przed rozpoczęciem konfiguracji. Ten objaw zwykle oznacza, że nowa usługa wskazuje niewłaściwy trwały stan. Najpierw popraw mapowanie montowania; konfigurowanie nowej, pustej instancji może utworzyć nowe pliki utrudniające odzyskanie danych.

Zweryfikuj nową wersję przed usunięciem zasobów umożliwiających wycofanie zmian

Sprawdź tożsamość oryginalnego serwera, użytkowników, biblioteki, metadane i ważne ustawienia. Odtwórz jeden element w trybie Direct Play oraz jeden reprezentatywny materiał transkodowany, a następnie uruchom lub obserwuj istotne dla swojej konfiguracji zaplanowane zadanie. Sprawdź logi pod kątem powtarzających się błędów migracji, bazy danych, uprawnień i FFmpeg.

Po pierwszej udanej sesji uruchom ponownie kontener. Nowa wersja nie jest w pełni zweryfikowana, dopóki nie potrafi ponownie otworzyć tych samych danych i urządzeń po czystym odtworzeniu lub ponownym uruchomieniu. Pozwala to wykryć przypadkową zależność od tymczasowego montowania lub stanu środowiska uruchomieniowego.

Zachowaj kopię zapasową sprzed aktualizacji, odwołanie do poprzedniego obrazu i zapisaną definicję, dopóki serwer nie przejdzie zwykłego okresu obciążenia. Jeśli po migracji bazy danych konieczne będzie wycofanie zmian, postępuj zgodnie z udokumentowaną przez Jellyfin granicą przywracania, zamiast kierować starszy obraz na już zmigrowany stan.