Kun je een containerimage terugzetten zonder appgegevens te verliezen?

Ja, je kunt een containerimage terugzetten zonder appgegevens te verliezen wanneer de persistente status zich buiten de container bevindt en compatibel blijft met de oudere versie.

Op een thuis-NAS maakt het vervangen van de image normaal gesproken alleen de runtime van de toepassing opnieuw aan, terwijl benoemde volumes of bind mounts databases, instellingen en gebruikersbestanden behouden. De kritieke grens is een schemawijziging: een nieuwere image kan de database migreren of de configuratie herschrijven op een manier die de oudere image niet kan lezen. Leg vóór het terugzetten de huidige mounts, image-identiteit, configuratie, geheimen en een consistente back-up van de gegevens vast.

Bevries de huidige status voordat je de image wijzigt

Stop automatische image-updates en noteer de huidige imagetag, onveranderlijke digest, containerconfiguratie, omgevingsvariabelen, netwerken, poorten, mounts, herstartbeleid en healthcheck. Sla het Compose-bestand of de geëxporteerde configuratie afzonderlijk van de container op.

Bij een rollback-workflow voor NAS-containers wordt aanbevolen een bekende vorige image beschikbaar te houden in plaats van te vertrouwen op een bewegende latest-tag. Het bruikbare herstelpunt is de specifieke vorige imageversie, samen met de configuratie waarmee deze draaide.

Maak een toepassingsconsistente databaseback-up of snapshot voordat je de nieuwere versie stopt. Ga er niet van uit dat het bestaande volume een rollbackkopie is, omdat het mogelijk al schema- of gegevenswijzigingen bevat die door de update zijn aangebracht.

Bevestig dat de appgegevens buiten de schrijfbare laag staan

Breng elk benoemd volume en elke bind mount in kaart en identificeer databases, uploads, plug-ins, certificaten, cachebestanden of configuratie die nog uitsluitend in de schrijfbare laag van de container zijn opgeslagen.

Persistente opslag blijft alleen behouden bij het vervangen van een container wanneer de nieuwe container opnieuw verbinding maakt met dezelfde externe gegevenslocatie. De imageversieworkflow van SynoForum controleert expliciet of volumedata op de NAS-opslag blijft staan voordat een container met een andere image opnieuw wordt aangemaakt.

Als kritieke gegevens alleen in de schrijfbare laag staan, kopieer of exporteer ze dan voordat je de huidige container verwijdert. Beschouw deze extractie als een herstelstap, niet als een reden om een container zonder versiebeheer onbeperkt te blijven gebruiken.

Leg de exacte oudere image vast in plaats van Latest opnieuw te gebruiken

Download of lokaliseer de laatst bekende goed werkende tag of digest en wijzig alleen de imagereferentie. Controleer de architectuur, applicatievariant en vereiste omgevingsvariabelen voordat je de service opnieuw aanmaakt.

Gebruikers die door Compose beheerde services terugzetten, gaan meestal terug naar een eerdere expliciete imageversie in plaats van Docker te vragen een actieve container ter plaatse terug te draaien. Een praktische rollbackdiscussie draait om het wijzigen van de vastgelegde Compose-imagetag en het opnieuw aanmaken van de service.

Gebruik geen oude gecachte image waarvan de identiteit onbekend is. Noteer de digest na het downloaden, zodat een volgende rebuild niet stilletjes een andere binary selecteert onder dezelfde veranderlijke tag.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Controleer of de nieuwere versie de database heeft gewijzigd

Lees de releasenotes en migratielogboeken van de toepassing voor de versies tussen het rollbackdoel en de huidige image. Let op onomkeerbare schemawijzigingen, herschreven configuratie, wijzigingen in versleutelingssleutels of upgrades van plug-ins.

Een database terugzetten is moeilijker dan een image terugzetten, omdat de toepassingscode en het schema compatibel moeten blijven. Octopus beschrijft achterwaarts compatibele migraties als vereiste wanneer oude en nieuwe toepassingsversies naast elkaar kunnen bestaan of worden teruggedraaid. Daarmee wordt schemacompatibiliteit tussen versies de bepalende grens voor een rollback.

Als de oudere image de gemigreerde database niet kan lezen, herstel dan de databaseback-up van vóór de upgrade in plaats van oude code naar de nieuwe status te laten verwijzen. Bewaar de huidige database afzonderlijk voor het geval de rollback zelf moet worden teruggedraaid.

Maak de service opnieuw aan met dezelfde persistente paden

Stop en maak de applicatiecontainer opnieuw aan met de oudere image, terwijl je dezelfde geverifieerde benoemde volumes of bind mounts behoudt. Gebruik geen opdrachten of opties in de gebruikersinterface die volumes verwijderen.

Houd netwerknamen, service-aliases, gepubliceerde poorten, UID/GID-toewijzingen, geheimen en doelen van de reverse proxy consistent, tenzij de oudere versie een gedocumenteerd verschil vereist. Een container die met de verkeerde mounts succesvol start, kan een nieuwe lege app aanmaken en eruitzien als gegevensverlies.

Controleer de mountlijst en toepassingslogboeken voordat je inlogt of achtergrondtaken laat uitvoeren. Als de app een nieuwe database initialiseert, stop dan onmiddellijk en corrigeer het gegevenspad in plaats van gegevens naar de verkeerde locatie te importeren.

Valideer de rollback en behoud een herstelpad vooruit

Test het inloggen, het lezen en schrijven van de database, uploads, geplande taken, integraties en één gecontroleerde herstart. Vergelijk een steekproef van records en bestanden met de inventaris van vóór de rollback.

De ZimaSpace-workflow voor snapshots van appgegevens vóór updates biedt een veiligere voorbereidingsstap voor toekomstige upgrades.

De rollback is pas voltooid wanneer de oude image de bedoelde persistente gegevens gebruikt, het schema compatibel is of is hersteld en de service een nieuwe recreatie overleeft. Bewaar de nieuwere image, de bijbehorende gegevensback-up en de rollbacknotities totdat de oude versie gedurende de normale gebruiksperiode stabiel heeft gedraaid.