Warum hängt ein Compose-Stack nach der erneuten Bereitstellung ein neues leeres benanntes Volume ein?
Ein Compose-Stack kann ein neues leeres benanntes Volume einbinden, wenn sich der projektbezogene Volume-Name bei der erneuten Bereitstellung ändert oder das ursprüngliche Volume nicht gefunden wird.
Die alten Daten können noch in einem anderen Docker-Volume vorhanden sein, während der neu erstellte Dienst am selben Container-Pfad ein neu generiertes Volume einbindet. Häufige Auslöser sind ein geänderter Stack- oder Projektname, ein umbenannter Volume-Schlüssel, das Entfernen mit einem Volume-löschenden Befehl, der Verlust einer externen Deklaration, die Bereitstellung über einen anderen Manager oder ein expliziter Volume-Name, der nun anders aufgelöst wird. Erfassen Sie sowohl das eingebundene Volume als auch verwaiste Kandidaten, bevor Sie Daten wiederherstellen oder die App initialisieren.
Das exakt vom neuen Container eingebundene Volume identifizieren
Untersuchen Sie die Mounts des laufenden Containers und notieren Sie den Volume-Namen, Treiber, Einhängepunkt, Labels, Erstellungszeitpunkt, das Ziel im Container sowie den Lese-/Schreibmodus. Vergleichen Sie diese Angaben mit den Aufzeichnungen vor der erneuten Bereitstellung.
Der Ubuntu-Befehl docker volume inspect stellt Informationen zur Volume-Identität bereit. So lässt sich das neue leere Volume von einem älteren, nicht eingebundenen Volume mit ähnlicher Namensgebung unterscheiden.
Kopieren Sie keine Daten in das neue Volume, bevor das ursprüngliche Volume gefunden wurde. Beim Start der App kann eine neue Datenbank erstellt werden, wodurch das Ziel absichtlich initialisiert wirken kann.
Prüfen, ob sich der Compose-Projektname geändert hat
Vergleichen Sie den alten und neuen Projektnamen, Stack-Namen, das Compose-Verzeichnis, die Option -p, COMPOSE_PROJECT_NAME, den Eintrag name: auf oberster Ebene sowie den Bereitstellungsmanager.
Docker erklärt, dass Compose ein Volume normalerweise als Projektname plus Volume-Schlüssel mit einem Bereich versieht, sofern kein expliziter Name oder die Suche nach einem externen Volume konfiguriert ist.
Wenn dieselbe Compose-Datei in ein anderes Verzeichnis verschoben wird, kann dadurch ein zweites Projekt und ein zweites Volume entstehen, selbst wenn Dienst- und Volume-Schlüssel unverändert bleiben.
Stabile Namen und Einstellungen für externe Volumes überprüfen
Vergleichen Sie die Volume-Definition auf oberster Ebene vor und nach der erneuten Bereitstellung. Prüfen Sie name:, external:, Treiberoptionen, Interpolationsvariablen und ob das erwartete Volume vorhanden ist.
Das Docker-Compose-Tutorial von Microsoft weist darauf hin, dass benannte Volumes unabhängig vom Austausch von Containern bestehen bleiben. Ein neuer leerer Zustand bedeutet daher normalerweise, dass eine andere Volume-Identität eingebunden wurde oder das alte Volume entfernt wurde.
Markieren Sie ein Volume nur dann als extern, wenn sein Lebenszyklus absichtlich außerhalb des Stacks verwaltet wird. Compose sollte eindeutig fehlschlagen, wenn ein externes Volume fehlt, statt stillschweigend ein Ersatz-Volume zu erstellen.
Prüfen, ob eine Bereinigung das ursprüngliche Volume entfernt hat
Überprüfen Sie Bereitstellungsprotokolle, Skripte, UI-Aktionen, Bereinigungsjobs und Befehle auf das Löschen von Volumes. Vergleichen Sie den Erstellungszeitpunkt des Volumes mit dem Ereignis der erneuten Bereitstellung.
Red Hat dokumentiert, dass von Containern verwaltete benannte Volumes separate Speicherorte von den beschreibbaren Container-Layern haben. Deshalb sind das Entfernen eines Containers und das Entfernen seines benannten Volumes unterschiedliche Ereignisse im Lebenszyklus.
Wenn das ursprüngliche Volume fehlt, stoppen Sie automatische Starts und stellen Sie nur aus einem verifizierten Backup wieder her. Gehen Sie nicht davon aus, dass ein leeres Ersatz-Volume eine wiederherstellbare gelöschte Layer enthält.
Identität des Stack-Managers und Bereitstellungsmethode vergleichen
Notieren Sie, ob der Stack über die CLI, Portainer, einen NAS-App-Store, eine Git-Bereitstellung oder ein anderes Automatisierungstool gestartet wurde. Vergleichen Sie den Stack-Namen und die von diesem Manager gespeicherten Umgebungswerte.
Portainer erfordert bei der Bereitstellung einen aussagekräftigen Stack-Namen. Die vom Manager kontrollierte Identität kann sich vom verzeichnisbasierten Projektnamen unterscheiden, den ein manueller Compose-Befehl verwendet.
Ein manueller Notfallstart kann daher Ressourcen unter einem anderen Projektpräfix erstellen. Legen Sie einen einzigen Verantwortlichen für die Bereitstellung fest und dokumentieren Sie die aufgelösten Volume-Namen, die dieser erstellt.
Daten unter dem neuen Volume-Mount ausschließen
Stoppen Sie den Container und untersuchen Sie das Image oder den Bind-Pfad ohne das benannte Volume in einem temporären Test. Ermitteln Sie, ob der Start Daten in die Container-Layer geschrieben hat, bevor das Volume eingebunden wurde.
Das Linux-Handbuch zum Mounten erklärt, dass ein Mount vorhandene Verzeichnisinhalte verbirgt. Dadurch können Daten scheinbar fehlen, wenn ein neues leeres Volume Dateien überdeckt, die im Image oder in der beschreibbaren Layer erstellt wurden.
Führen Sie die verborgene Layer und das alte persistente Volume nicht blind zusammen. Bestimmen Sie, welcher Zustand maßgeblich ist, und verwenden Sie die vom jeweiligen Programm unterstützte Wiederherstellungsmethode.
Das ursprüngliche Volume in einem kontrollierten Test erneut einbinden
Stoppen Sie den Stack, sichern Sie beide möglichen Volumes, binden Sie das ursprüngliche Volume in einen temporären Container oder einen temporären Dienstpfad ein und überprüfen Sie Anwendungsdateien, Datenbankidentität, Besitzrechte und Zeitstempel.
Der ZimaSpace-Leitfaden zum Verschieben von Containerdaten, ohne Mounts zu beschädigen, beschreibt den angrenzenden Workflow zur Pfadzuordnung. Dieser Artikel konzentriert sich auf die Identität projektbezogener benannter Volumes.
Das Problem ist gelöst, wenn das gewünschte alte Volume unter einem stabilen expliziten oder externen Namen eingebunden ist und wiederholte Bereitstellungen es erneut verwenden, ohne einen weiteren leeren Kandidaten zu erstellen.
Häufig gestellte Fragen
Bedeutet ein leeres benanntes Volume, dass die alten Daten gelöscht wurden?
Nicht unbedingt. Das alte Volume kann noch unter einem anderen Projektpräfix oder expliziten Namen vorhanden sein, während der neue Container ein anderes leeres Volume verwendet.
Kann eine Änderung des Compose-Ordnernamens ein neues Volume erstellen?
Ja. Wenn kein Projektname festgelegt ist, kann Compose ihn aus dem Projektverzeichnis ableiten und Ressourcen mit einem anderen Präfix erstellen.
Sollten wichtige Volumes als extern markiert werden?
Externe Volumes können verhindern, dass das Entfernen eines Stacks ihren Lebenszyklus verwaltet. Sie erfordern jedoch eine bewusste Erstellung, Benennung, Sicherung und Überprüfung bei der Bereitstellung.
Empfohlene Produkte
Support & Tipps
Mehr zum Lesen
Leitfaden zur Speicherkapazität, Aufbewahrung und Bereinigung von Live-TV-Aufnahmen
Messen Sie echte Aufzeichnungen, halten Sie Headroom frei, kombinieren Sie Alters- und Kapazitätslimits und weisen Sie nach, dass das älteste geeignete Programm entfernt wird,...
Workflow zur Wiederherstellung von Metadaten für Heimmedien nach der Wiederherstellung einer Datenbank
Schützen Sie den wiederhergestellten Zustand, überprüfen Sie die Medienidentität und die Pfade und reparieren Sie anschließend fehlende Grafiken oder Übereinstimmungen in einer Pilotbibliothek, bevor...
Jellyfin-Client-Kompatibilitätscheckliste für Audio, Video und Untertitel
Testen Sie repräsentative Dateien mit jeweils nur einer veränderten Variable und protokollieren Sie für jeden Client Direct Play, Remux, Audiokonvertierung, Videotranskodierung oder einen Fehler.
