Jak przenieść Plexa z jednego kontenera do odpornego na awarie stosu usługowego

Przenieś Plexa do stosu usług, najpierw zabezpieczając dane, a następnie rozdzielając role i zależności pojedynczo zamiast przebudowywać wszystko podczas jednego przełączenia.

Migracja powinna zachować działający serwer, a jednocześnie jaśniej określić zakresy odpowiedzialności. Przed rozdzieleniem czegokolwiek zinwentaryzuj dane Plexa, ścieżki do multimediów, obsługę przez serwer proxy, dostęp do GPU, automatyzację i kopie zapasowe. Każda wydzielona usługa potrzebuje własnej ścieżki danych, kontroli kondycji i procedury wycofania zmian. Współdzielone multimedia należy natomiast montować spójnie, aby przeniesienie jednej usługi nie powodowało niepotrzebnego kopiowania.

Inwentaryzacja konfiguracji pojedynczego kontenera

Zanim rozdzielisz usługi, udokumentuj wszystko, za co obecnie niejawnie odpowiada kontener. Porty, punkty montowania, UID/GID, urządzenia GPU, zmienne środowiskowe i kolejność uruchamiania składają się na obowiązującą konfigurację.

stosy wielousługowe do obsługi multimediów mogą umieszczać Plex obok innych usług współdzielących ścieżki do multimediów, pamięć masową i harmonogramy przepływów pracy.

Wyeksportuj bieżącą konfigurację kontenera i przypisz każdą zależność do Plexa, serwera proxy, automatyzacji, monitorowania lub współdzielonej pamięci masowej. Jeśli dane wejściowe nie mają jasno określonego właściciela, pozostaw je przy Plexie, dopóki zależność nie zostanie zrozumiana.

Ujednolicenie ścieżek trwałych danych i identyfikatorów

Niezawodność stosu zależy od zachowania danych po zastąpieniu usługi i uniknięcia rozbieżności uprawnień. Spójne ścieżki hosta i identyfikatory liczbowe ograniczają niespodzianki podczas ponownego tworzenia kontenerów lub ich przenoszenia.

mapowanie UID i GID kontenera wiąże tożsamość usługi z liczbowym właścicielem plików w systemie hosta w punktach montowania bind.

Wybierz stabilne główne ścieżki na hoście dla stanu Plexa i współdzielonych multimediów, a następnie przed migracją zweryfikuj wymagania dotyczące UID/GID dla każdego procesu zapisującego dane. Jeśli kilka usług wymaga różnych uprawnień właściciela dla tej samej ścieżki stanu, przed kontynuacją zmień granice ścieżek.

Przenoś kolejno po jednej powiązanej roli

Proxy, monitorowanie, zarządzanie żądaniami i automatyzację multimediów można zwykle przenieść bez przenoszenia tego samego dnia bazy danych Plex. Dzięki temu potencjalny zakres awarii pozostaje niewielki, a przywrócenie poprzedniej konfiguracji jest proste.

Definicje usług Docker Compose jasno określają wolumeny, trwałe ścieżki i granice usług.

Przenieś jedną rolę, przeprowadź testy kondycji i integracji, a następnie pozostaw ją bez zmian przez typowy cykl użytkowania, zanim przeniesiesz kolejną. Jeśli przeniesienie roli wymaga ukrytych zmian w stanie Plexa, przed kontynuacją udokumentuj ten interfejs i zapewnij mu stabilność. Stabilne ścieżki i identyfikatory na hoście łatwiej zachować, gdy każda usługa korzysta z trwałego układu danych aplikacji zamiast doraźnego stanu przechowywanego w kontenerze.

Featured

ZimaBoard 2 - Miniaturowy serwer domowy dla wielkich pomysłów

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

Sprawdź izolację awarii, a nie tylko pomyślne uruchomienie

Migracja zakończy się powodzeniem, gdy jedna niekrytyczna usługa będzie mogła ulec awarii lub zostać zaktualizowana bez wyłączania Plexa ani uszkadzania współdzielonego stanu. To właśnie ta korzyść w zakresie odporności na awarie musi uzasadniać dodatkową złożoność stosu.

Wdrożenia Compose obejmujące wiele kontenerów opierają się na jawnie określonych zależnościach między usługami, a nie tylko na liczbie kontenerów.

Celowo zatrzymaj jedną usługę towarzyszącą i sprawdź, czy odtwarzanie w Plex, zapisywanie stanu i odzyskiwanie działania przebiegają zgodnie z założeniami. Jeśli każda awaria usługi nadal wymaga ponownego uruchomienia całego stosu, ogranicz wzajemne zależności, zanim uznasz migrację za odporną na awarie.