Een checklist vóór de upgrade voor Jellyfin-containers en afhankelijkheden

Eva Wong

IceWhale author

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

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

Bewaar voordat je een Jellyfin-container bijwerkt beide kanten van de implementatie: de persistente Jellyfin-status en de exacte containerdefinitie die weet hoe deze moet worden bereikt. Een nieuwe image ophalen is eenvoudig; een gemigreerde database, gewijzigde mount of vergeten devicekoppeling herstellen niet.

Gebruik de checklist in afhankelijkheidsvolgorde. Controleer eerst of je de gegevens kunt herstellen, leg daarna de huidige image en runtime-instellingen vast, lees vervolgens het upgradepad en vervang pas daarna de image. Test daarna dezelfde bibliotheken, gebruikers, afspeelmodi, geplande taken en het herstartgedrag voordat je de rollbackkopie verwijdert.

Leg de laatst werkende image en containerdefinitie vast

Bewaar de huidige Jellyfin-imagetag en, indien praktisch, de digest. Exporteer of kopieer het Compose-bestand of de appdefinitie met poorten, netwerken, mounts, omgevingswaarden, restartbeleid, gebruikerskoppeling, aanvullende groepen, GPU-devices en eventuele relatie met een reverse proxy.

De officiële documentatie van de Jellyfin-container maakt onderscheid tussen meebewegende tags zoals latest en expliciete tags voor major-, minor- en patchversies. Gedrag van Jellyfin-imagetags Een rollback is eenvoudiger wanneer je de exacte werkende versie kent in plaats van je alleen te herinneren dat ‘latest gisteren werkte’.

Verwijder de oude image niet en verwijder de opgeslagen definitie niet totdat de nieuwe versie de volledige validatieperiode heeft doorstaan. Als de upgrade mislukt voordat persistente gegevens worden gewijzigd, bieden de bewaarde image en definitie de minst ingrijpende herstelroute.

Maak een herstelbare back-up van de Jellyfin-status

Bescherm de gegevens- en configuratiemappen van Jellyfin voordat de image wordt gewijzigd. De back-up moet buiten het live applicatiepad staan en onafhankelijk leesbaar zijn; een tweede kopie of snapshot op dezelfde dataset is alleen nuttig als je begrijpt tegen welke fout deze bescherming biedt.

De back-updocumentatie van Jellyfin waarschuwt dat upgrades herstel van gegevens kunnen vereisen omdat er na toegepaste migraties geen algemeen downgrade-mechanisme bestaat. De documentatie beschrijft ook ingebouwde back-ups en de vereiste om de service volledig te stoppen voor handmatige bestandskopieën. Richtlijnen van Jellyfin voor back-up en herstel

Voor een containerworkflow wordt hetzelfde principe behandeld in ZimaSpace's workflow voor een rollbackpunt vóór een update. Stop hier als je de persistente paden niet kunt identificeren of de inhoud van de back-up niet kunt verifiëren.

Leg mounts, UID/GID en hardwareafhankelijkheden vast

Noteer elke bind-mount en benoemde volume en vermeld of deze alleen-lezen of beschrijfbaar is. Leg de runtime-UID/GID, groepslidmaatschappen en eigenaarschap van gegevensmappen van Jellyfin vast. Leg ook GPU- of render-devicekoppelingen vast als hardwareversnelling is ingeschakeld.

De containerhandleiding van Jellyfin laat zien dat media, configuratie en cache afzonderlijk worden gemount en dat de container onder een opgegeven UID/GID kan draaien. persistente paden en gebruikerskoppeling Dit zijn afhankelijkheden, geen versiering: een opnieuw gemaakte container kan succesvol starten terwijl deze een lege configuratiemap ziet of geen toegang meer heeft tot een device.

Vergelijk de opgeslagen definitie met de effectief draaiende container, niet alleen met een template waarvan je denkt dat deze actueel is. Als de runtime handmatige wijzigingen bevat die ontbreken in Compose of de NAS-appdefinitie, verhelp die afwijking dan vóór de upgrade, zodat de oude implementatie reproduceerbaar is.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

Controleer het ondersteunde upgradepad en het risico van plug-ins

Lees de releaseopmerkingen voor elke major-grens tussen de huidige en de doelversie. Let op vereiste tussenversies, databasemigraties, gewijzigde configuratie, compatibiliteit van plug-ins, FFmpeg-vereisten en langdurige werkzaamheden bij het opstarten.

De upgradedocumentatie van Jellyfin benadrukt herhaaldelijk het belang van back-ups en legt uit waarom schemaveranderingen een eenvoudige downgrade onmogelijk kunnen maken. Upgrade- en downgradegrenzen In de releaseopmerkingen van majorversies kunnen versiegebonden vereisten staan. Leid daarom geen veilig sprongupgradepad af uit het feit dat de containerimage bestaat.

Als een plug-in essentieel is, controleer dan vóór de serverupgrade of er een compatibele versie beschikbaar is. Als een plug-in optioneel is en eerder het opstarten heeft geblokkeerd, noteer dan de huidige versie en wees voorbereid om alleen die plug-in uit te schakelen als de nieuwe serverlogs deze als oorzaak van de fout aanwijzen.

Voer de upgrade uit zonder de statusgrens te wijzigen

Stop Jellyfin netjes, haal de beoogde image op en maak alleen de Jellyfin-service opnieuw aan met dezelfde geverifieerde persistente paden en runtimeafhankelijkheden. Combineer de upgrade niet met een opslagmigratie, een herontwerp van UID/GID, een wijziging van de reverse proxy en een nieuwe GPU-configuratie, tenzij die wijzigingen het werkelijke doel van het onderhoud zijn.

Bekijk het logboek bij de eerste start. Een migratie kan bij een grote bibliotheek terecht enige tijd duren, terwijl een onmiddellijke melding als ‘permission denied’, een lege database, een ontbrekend pad of een incompatibel schema op een andere oorzaak wijst. Start een migratie niet herhaaldelijk opnieuw alleen omdat de gebruikersinterface niet direct beschikbaar is.

Als de container opent als een nieuwe server, stop deze dan voordat je iets configureert. Dat verschijnsel betekent meestal dat de nieuwe service naar de verkeerde persistente status verwijst. Corrigeer eerst de mountkoppeling; het configureren van een nieuwe lege instantie kan nieuwe bestanden aanmaken die het herstel bemoeilijken.

Valideer de nieuwe versie voordat je rollbackmiddelen verwijdert

Controleer de identiteit van de oorspronkelijke server, gebruikers, bibliotheken, metadata en belangrijke instellingen. Speel één item af met Direct Play en één representatieve transcodering, en voer een geplande taak uit die voor jouw configuratie belangrijk is of observeer deze. Controleer de logs op terugkerende fouten met migraties, databases, rechten en FFmpeg.

Herstart de container eenmaal na de eerste geslaagde sessie. De nieuwe versie is pas volledig gevalideerd wanneer deze dezelfde gegevens en devices na een schone hercreatie of herstart opnieuw kan openen. Hiermee ontdek je afhankelijkheid van een tijdelijke mount of runtime-status.

Bewaar de back-up van vóór de upgrade, de verwijzing naar de vorige image en de opgeslagen definitie totdat de server de normale werklastperiode heeft doorstaan. Als na een databasemigratie een rollback nodig is, volg dan de door Jellyfin gedocumenteerde herstelgrens in plaats van een oudere image naar een al gemigreerde status te laten verwijzen.