Checklist voor het upgraden van een Plex-container: maak een back-up, zet een versie vast, test en rol veilig terug

Bescherm vóór een upgrade van een Plex-container de persistente status, leg de bekende goede image vast, controleer afhankelijkheden en zorg dat terugdraaien mogelijk is voordat je iets nieuws binnenhaalt.

Een upgrade moet een gecontroleerde wijziging zijn en geen gewoonte om images te vernieuwen. De container zelf is vervangbaar, maar de Plex-database, metadata, mounts, GPU-toegang, netwerkmodus en omliggende services zijn dat mogelijk niet. Leg voldoende informatie vast om de vorige werkende status te herstellen en valideer de nieuwe versie vervolgens telkens met dezelfde kleine set tests.

Bescherm persistente status voordat je de image vervangt

De snelste rollback is nutteloos als de nieuwe container status beschadigt of migreert waarvan geen back-up is gemaakt. Back-ups moeten het duurzame Plex-datapad en een bekende herstelprocedure omvatten, niet alleen een kopie van de Compose-YAML.

planning van een containerupgrade moet persistente status beschermen, rollback definiëren en het resultaat valideren.

Stop Plex of zet het tijdelijk stil wanneer je back-upmethode dat vereist, leg de persistente status vast en controleer of de back-up kan worden gelezen. Als de back-up niet op een testlocatie kan worden hersteld, stel de upgrade dan uit.

Leg de exacte werkende image en configuratie vast

Als je alleen een zwevende latest-tag gebruikt, wordt het moeilijker om na een regressie de laatst goed werkende status te reproduceren. De imageverwijzing, omgeving, mounts, apparaten en netwerkinstellingen moeten samen worden vastgelegd.

Docker Compose-servicedefinities maken volumes, persistente paden en servicegrenzen expliciet.

Sla de huidige image-digest of expliciete versie op, samen met het deploymentbestand en alle omgevingswaarden die Plex nodig heeft. Als je de oude container niet zonder giswerk opnieuw kunt maken, is rollback nog niet voorbereid. De image kan alleen wegwerpbaar blijven wanneer persistente containergegevens en het mountcontract onafhankelijk zijn beschermd.

Controleer afhankelijkheden van de host en begeleidende services

Een update van een Plex-image kan een afhankelijkheid van een driver, GPU-apparaat, bestandssysteem, proxy of begeleidende service blootleggen die door de oude versie niet duidelijk werd gemaakt. Deze interfaces verdienen vóór de wijziging een snelle voorbereidende controle.

mediasteken met meerdere services kunnen Plex naast andere services plaatsen die mediapaden, opslag en de timing van workflows delen.

Controleer mounts, UID/GID, toegang tot hardwareapparaten, DNS en bereikbaarheid van de proxy vóór en direct na de upgrade. Wanneer één afhankelijkheid tegelijk met Plex verandert, voer de wijzigingen dan afzonderlijk uit, zodat de oorzaak van een fout zichtbaar blijft.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Valideer met een vaste testset na de upgrade

Een actieve container bewijst niet dat een upgrade succesvol is. Controleer inloggen, bladeren door de bibliotheek, Direct Play, één verwachte transcodering, het schrijven van metadata, externe toegang en achtergrondtaken.

controles van gebruik, verzadiging en fouten maken onderscheid tussen een drukke resource en een resource die daadwerkelijk beperkt is of faalt.

Voer na elke upgrade dezelfde korte rooktest uit en vergelijk het resourcegebruik met de vorige versie. Als een kritieke test mislukt of de resourcebehoefte aanzienlijk verandert, voer dan eerst een rollback uit en onderzoek daarna de release.