Kann man ein Container-Image zurücksetzen, ohne App-Daten zu verlieren?

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Can You Roll Back a Container Image Without Losing App Data? - Zima Store Online

Ja, Sie können ein Container-Image zurücksetzen, ohne App-Daten zu verlieren, sofern der persistente Zustand außerhalb des Containers gespeichert ist und mit der älteren Version kompatibel bleibt.

Auf einem Heim-NAS wird beim Ersetzen des Images normalerweise nur die Laufzeitumgebung der Anwendung neu erstellt, während benannte Volumes oder Bind-Mounts Datenbanken, Einstellungen und Benutzerdateien beibehalten. Die kritische Grenze bilden Schemaänderungen: Ein neueres Image kann die Datenbank migrieren oder die Konfiguration so umschreiben, dass die ältere Version sie nicht mehr lesen kann. Sichern Sie vor dem Zurücksetzen die aktuellen Mounts, die Image-Identität, die Konfiguration, Geheimnisse und eine konsistente Datensicherung.

Aktuellen Zustand vor der Image-Änderung einfrieren

Deaktivieren Sie automatische Image-Aktualisierungen und dokumentieren Sie den aktuellen Image-Tag, den unveränderlichen Digest, die Container-Konfiguration, Umgebungsvariablen, Netzwerke, Ports, Mounts, die Neustartrichtlinie und den Healthcheck. Speichern Sie die Compose-Datei oder die exportierte Konfiguration separat vom Container.

Ein Rollback-Workflow für NAS-Container empfiehlt, ein bekanntes vorheriges Image verfügbar zu halten, statt sich auf einen sich ändernden latest-Tag zu verlassen. Der verwendbare Wiederherstellungspunkt ist die spezifische vorherige Image-Version zusammen mit der Konfiguration, mit der sie ausgeführt wurde.

Erstellen Sie vor dem Stoppen der neueren Version eine anwendungskonsistente Datenbanksicherung oder einen Snapshot. Gehen Sie nicht davon aus, dass das vorhandene Volume eine Rollback-Kopie ist, da es möglicherweise bereits Schema- oder Datenänderungen enthält, die durch das Update vorgenommen wurden.

Bestätigen, dass die App-Daten außerhalb der beschreibbaren Ebene liegen

Ordnen Sie jedes benannte Volume und jeden Bind-Mount zu und ermitteln Sie, ob Datenbanken, Uploads, Plugins, Zertifikate, Caches oder Konfigurationen noch ausschließlich in der beschreibbaren Ebene des Containers gespeichert sind.

Persistenter Speicher überlebt den Austausch eines Containers nur, wenn der neue Container wieder mit demselben externen Speicherort verbunden wird. Der Image-Versions-Workflow von SynoForum prüft ausdrücklich, dass die Volume-Daten auf dem NAS bleiben, bevor ein Container aus einem anderen Image neu erstellt wird.

Wenn sich wichtige Daten ausschließlich in der beschreibbaren Ebene befinden, kopieren oder exportieren Sie sie, bevor Sie den aktuellen Container entfernen. Betrachten Sie diese Extraktion als Wiederherstellungsschritt und nicht als Grund, einen nicht versionierten Container dauerhaft beizubehalten.

Das exakte ältere Image festlegen, statt Latest wiederzuverwenden

Laden Sie den letzten bekannten funktionierenden Tag oder Digest herunter oder suchen Sie ihn, und aktualisieren Sie nur die Image-Referenz. Überprüfen Sie Architektur, Anwendungsversion und erforderliche Umgebungsvariablen, bevor Sie den Dienst neu erstellen.

Benutzer, die von Compose verwaltete Dienste zurücksetzen, wechseln üblicherweise zu einer zuvor festgelegten Image-Version zurück, statt Docker aufzufordern, einen laufenden Container direkt zurückzusetzen. Eine praktische Rollback-Diskussion konzentriert sich darauf, den festgelegten Compose-Image-Tag zu ändern und den Dienst neu zu erstellen.

Verwenden Sie kein altes zwischengespeichertes Image mit unbekannter Identität. Dokumentieren Sie den Digest nach dem Herunterladen, damit ein erneuter Build nicht stillschweigend eine andere Binärdatei unter demselben veränderlichen Tag auswählt.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

Prüfen, ob die neuere Version die Datenbank geändert hat

Lesen Sie die Versionshinweise und Migrationsprotokolle der Anwendung für die Versionen zwischen dem Rollback-Ziel und dem aktuellen Image. Achten Sie auf irreversible Schemaänderungen, neu geschriebene Konfigurationen, Änderungen an Verschlüsselungsschlüsseln oder Upgrades von Plugins.

Ein Datenbank-Rollback ist schwieriger als ein Image-Rollback, da Anwendungscode und Schema kompatibel bleiben müssen. Octopus beschreibt rückwärtskompatible Migrationen als Voraussetzung, wenn alte und neue Anwendungsversionen gleichzeitig bestehen oder zurückgesetzt werden können. Damit wird die Schema-Kompatibilität zwischen Versionen zur entscheidenden Grenze für das Rollback.

Wenn das ältere Image die migrierte Datenbank nicht lesen kann, stellen Sie stattdessen die Datenbanksicherung vor dem Upgrade wieder her, anstatt den alten Code auf den neuen Zustand zu verweisen. Bewahren Sie die aktuelle Datenbank separat auf, falls das Rollback selbst rückgängig gemacht werden muss.

Den Dienst mit denselben persistenten Pfaden neu erstellen

Stoppen Sie den Anwendungscontainer und erstellen Sie ihn mit dem älteren Image neu, wobei Sie dieselben überprüften benannten Volumes oder Bind-Mounts beibehalten. Verwenden Sie keine Befehle oder Optionen der Benutzeroberfläche, die Volumes entfernen.

Behalten Sie Netzwerknamen, Dienst-Aliase, veröffentlichte Ports, UID/GID-Zuordnungen, Geheimnisse und Ziele des Reverse-Proxys unverändert bei, sofern die ältere Version keine dokumentierte Abweichung erfordert. Ein erfolgreich gestarteter Container mit den falschen Mounts kann eine neue leere App erstellen und wie ein Datenverlust aussehen.

Überprüfen Sie die Mount-Liste und die Anwendungsprotokolle, bevor Sie sich anmelden oder Hintergrundaufgaben ausführen lassen. Wenn die App eine neue Datenbank initialisiert, stoppen Sie sie sofort und korrigieren Sie den Datenpfad, statt Daten am falschen Ort zu importieren.

Rollback validieren und einen Weg zur Wiederherstellung nach vorn offenhalten

Testen Sie Anmeldung, Datenbanklese- und -schreibvorgänge, Uploads, geplante Aufgaben, Integrationen und einen kontrollierten Neustart. Vergleichen Sie eine Auswahl von Datensätzen und Dateien mit dem Inventar vor dem Rollback.

Der ZimaSpace-Workflow für Snapshots von App-Daten vor Updates bietet die sicherere Vorbereitung für künftige Upgrades.

Das Rollback ist erst abgeschlossen, wenn das alte Image die vorgesehenen persistenten Daten verwendet, das Schema kompatibel oder wiederhergestellt ist und der Dienst eine weitere Neuerstellung übersteht. Bewahren Sie das neuere Image, seine Datensicherung und die Rollback-Notizen auf, bis die alte Version den normalen Belastungszeitraum stabil durchlaufen hat.