Jellyfin migreren van één container naar een veerkrachtige service-stack

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.

Migreer Jellyfin door eerst het huidige gedrag vast te leggen, persistente gegevens te beschermen en vervolgens diensten toe te voegen in omkeerbare, geteste stappen.

Deze procedure is bedoeld voor een werkende Docker-container die een ongedocumenteerde opdracht of alles-in-éénindeling is ontgroeid. Het doel is niet het maximale aantal containers, maar een reproduceerbare Jellyfin-dienst met expliciete mounts, netwerken, apparaten, gezondheidssignalen, back-upbereik en rollback. Houd mediaopslag onafhankelijk van applicatiestatus, bewaar de oude instantie totdat de acceptatietests zijn geslaagd en voeg alleen afhankelijkheden toe die het huishouden kan beheren.

Bepaal wat veerkracht moet afdekken

Kies welke storingen de nieuwe stack moet kunnen opvangen: een crash van het Jellyfin-proces, een slechte image-update, verloren configuratieopslag, een onbeschikbare proxy, een herstart van de host of volledig verlies van de host. Elke storing vereist een andere beheersmaatregel. Een herstartbeleid helpt na het beëindigen van een proces; het herstelt geen verwijderde volume en repareert geen ontoegankelijke mediamount.

Stel meetbare hersteldoelen vast voor configuratie, kijkstatus en beschikbaarheid van de dienst. Bepaal hoeveel downtime en gegevensverlies aanvaardbaar zijn, wie een melding ontvangt en welke onderdelen opnieuw kunnen worden opgebouwd. Deze afbakening voorkomt dat een kleine thuismigratie databases, proxies, dashboards en automatisering verzamelt die geen geïdentificeerd risico verminderen.

Breng de actieve container in kaart

Leg de exacte imageverwijzing, opdracht, omgevingsvariabelen, gepubliceerde poorten, netwerken, het herstartbeleid, gebruikers- en groeps-ID's, apparaattoewijzingen, DNS-instellingen, labels, configuratiemount, cachemount, mediamounts en geheimen vast. Leg ook eigenaarschap en rechten op elk hostpad vast. Een schermafbeelding van een containerinterface is geen volledig implementatierecord.

Vertaal die inventaris naar een Compose-definitie zonder het gedrag te wijzigen. De stapsgewijze methode in deze migratiehandleiding van Docker run naar Compose is waardevol omdat het eerste mijlpaalpunt reproduceerbaarheid is, niet uitbreiding van functies. Leg voor de eerste omschakeling de momenteel actieve image-digest of versie vast.

Scheid persistente status, cache en media

Koppel de Jellyfin-configuratie en databasestatus aan een duidelijk benoemd persistent pad. Plaats wegwerpbare cache- en transcodebestanden op een afzonderlijk pad, zodat ze niet worden aangezien voor kritieke back-upgegevens. Mount media waarvan je eigenaar bent afzonderlijk en indien mogelijk alleen-lezen; een veerkrachtige applicatielaag mag de beschermingsgrens van een grote mediabibliotheek niet vervagen.

Stop Jellyfin of breng het tijdelijk tot rust voordat je de eerste consistente statuskopie maakt, tenzij de back-upmethode applicatieconsistentie garandeert. Leg rechten, checksums of bestandstellingen, back-uptijd en herstellocatie vast. Ga er nooit van uit dat de containerimage gebruikersgegevens bevat: de implementatiedefinitie, geheimen, persistente status en mediaverwijzingen zijn afzonderlijke invoer voor herstel.

Bewijs het herstel voordat je het netwerk wijzigt

Maak een tijdelijke herstellocatie, kopieer de beschermde applicatiestatus daarin en start de vastgezette Jellyfin-dienst op een alternatieve poort, met media alleen-lezen gemount. Controleer gebruikers, bibliotheken, kijkgeschiedenis, metadata, plug-ins en representatieve weergave. Vernietig de tijdelijke instantie en herhaal de procedure op basis van de geschreven instructies als een stap afhankelijk was van je geheugen.

Een praktische Compose-back-up moet het implementatiebestand, omgevingsinvoer, volumes en elke applicatieconsistente database-export bewaren. Deze handleiding voor het back-uppen en upgraden van een Compose-stack legt uit waarom alleen een image of actieve databasebestanden kopiëren geen volledig herstelpad is.

Schakel over naar de declaratieve Jellyfin-dienst

Kies een onderhoudsvenster, stop de oude container, maak de laatste consistente statusback-up en voorkom dat de oude instantie automatisch opnieuw start. Start de equivalente Compose-dienst met dezelfde persistente paden en apparaattoegang. Houd de openbare route pas ongewijzigd nadat lokale gezondheids- en afspeelcontroles zijn geslaagd.

Controleer de containergezondheid, logs, zichtbaarheid van bibliotheken, toegang tot hardwareapparaten, direct afspelen, één representatieve transcodering, ondertitelverwerking en een herstart. Als de dienst een apparaat of mount niet kan zien, stop dan en herstel de oude container in plaats van onder druk meerdere lagen tegelijk te bewerken. De rollback bestaat uit de vorige vastgezette image plus de status van vóór de omschakeling en de oorspronkelijke uitvoerparameters.

Voeg aangrenzende diensten één grens tegelijk toe

Introduceer een reverse proxy alleen wanneer externe toegang een afzonderlijk beheerde route vereist. Voeg monitoring toe wanneer er een gedefinieerd gezondheidssignaal is en iemand erop zal reageren. Voeg een waarschuwingskanaal toe wanneer herstartlussen, opslagverlies of mislukte back-ups moeten worden opgemerkt. Elke dienst heeft een eigenaar, een beslissing over persistente status, een netwerkbereik, een updatemethode en een beschrijving van het effect bij uitval nodig.

De architecturale reden voor deze grenzen wordt afzonderlijk behandeld in ZimaSpace's uitleg over waarom Jellyfin-implementaties servicestacks gebruiken. Pas dat model tijdens de migratie voorzichtig toe: groepeer componenten die samen moeten herstellen en voorkom dat afspelen afhankelijk wordt van optionele dashboards of automatisering.

Maak gezondheid, updates en back-ups zichtbaar

Definieer gezondheid op basis van het gebruikerspad, niet alleen als een actief proces. Controleer of Jellyfin lokaal antwoordt, de mediamount aanwezig is, de openbare route indien ingeschakeld de bedoelde dienst bereikt en één bekend bestand kan worden gelezen. Stuur mislukte controles naar een meldingskanaal dat de beheerder al gebruikt, met voldoende context om een applicatiefout te onderscheiden van opslag- of netwerkverlies.

Beheer de Compose-definitie met versiebeheer, houd geheimen buiten de repository en beoordeel imagewijzigingen vóór implementatie. Automatiseer back-ups pas nadat een handmatig herstel werkt. De werkwijze in deze handleiding voor Jellyfin-gezondheidscontroles en monitoring laat zien hoe declaraties, controles, meldingen en back-ups samenhangen; behoud een goedkeurings- en rollbackpunt voor updates die opgeslagen status kunnen wijzigen.

Voer storingsoefeningen uit voordat je het oude pad buiten gebruik stelt

Herstart de host, stop Jellyfin onverwacht, maak de proxy onbeschikbaar, verbreek een testmediapad en herstel de applicatiestatus naar een schone tijdelijke locatie. Bevestig voor elke oefening de verwachte melding, herstelvolgorde en het gedrag voor gebruikers. Simuleer geen destructief opslagverlies tegen de enige mediakopie.

Leg de hersteltijd en eventuele handmatige opdrachten vast. Een container die snel opnieuw start maar met een lege bibliotheek terugkomt, is niet geslaagd voor de diensttest. Een back-up die bestaat maar niet binnen het doelvenster kan worden hersteld, is niet geslaagd voor de hersteltest. Herstel die grenzen voordat je meer diensten toevoegt.

Sluit de migratie af met een stabiele operationele afspraak

Stel de oorspronkelijke container pas buiten gebruik nadat de nieuwe Jellyfin-dienst normaal huishoudelijk gebruik, een geplande update, een herstart van de host en een schone herstelrepetitie heeft doorstaan. Archiveer de oude parameters, de definitieve back-up van vóór de omschakeling, de huidige Compose-definitie, de herstelmethode voor geheimen, de mountkaart en de rollbackstappen volgens het gekozen bewaarbeleid.

Stop met uitbreiden wanneer de stack reproduceerbaar, gemonitord, herstelbaar en begrijpelijk is voor de beheerder. Voeg alleen een extra node of afhankelijkheid toe wanneer een gemeten vereiste op het gebied van capaciteit, vertrouwen of storingsdomein dat noodzakelijk maakt. Veerkracht ontstaat door bekende status en geoefend herstel, niet door het aantal containers in het diagram.

NAS- en serverconfiguratie

Meer om te lezen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.