Einer der am häufigsten beantworteten Beiträge im offiziellen Docker-Forum ist „Daten in Datencontainern aktualisieren“.

Einer der am häufigsten beantworteten Beiträge im offiziellen Docker-Forum „Upgrade von Daten innerhalb eines Datencontainers“

matlehmann
Ich habe einen Container mit Daten, er hat ein Volumen ( z.B. Persistente Daten in /var/data). Der Container enthält persistente Daten für die Software in einem anderen Container.
Für neue Versionen der Software müssen diese permanenten Daten aktualisiert werden (Struktur- oder Layoutänderungen usw.). Aus diesem Grund möchte ich einen weiteren Datencontainer (in /var/data) mit den aktualisierten Daten am selben Ort erstellen und den alten Datencontainer mit seinen Daten weiterhin intakt halten.
Auf diese Weise kann ich den alten Datencontainer und die alte Version der Software verwenden, falls etwas schief geht.
Aber wie kann ich das machen? Die notwendigen Schritte, um das gewünschte Ergebnis zu erzielen, waren für mich nicht offensichtlich.
Ich kann einen Befehl ausführen, um den Container zu aktualisieren, z. B. docker run -i -t --name temp --volumes-from data -v /upgraded image /upgrade_script.sh
Aber wie kann ich später das Upgrade wiederherstellen? Daten an den ursprünglichen Speicherort kopieren, ohne die alten Daten zu überschreiben? Wenn ich docker run -i -t --volumes-from temp image cp /upgraded /var/data ausführe, werden meine alten Daten überschrieben. Muss ich für die aktualisierten Daten ein vom Host bereitgestelltes Volume verwenden, oder gibt es eine bessere Lösung?

sam
Nur eine Vermutung, da ich hier im Allgemeinen lieber direkt vom Host bereitgestellte Volumes verwende und Schwierigkeiten habe, den Nutzen von Datencontainern zu finden.
Aber... können Sie Ihren Datencontainer festschreiben und dann das Bild usw. speichern?
Sven
Oh, denken Sie bitte auch über den Vorschlag nach, Docker-Commit-Snapshot-Container zu verwenden. SAM ist großartig.
Keeb
Ich verwende tatsächlich Datencontainer wie UNIX-Pipes. Ich habe das Gefühl, dass sie natürlicher in das Paradigma passen.
docker run -name some_pipe_storage some_container_which_generates_data
docker run --volumes-from some_pipe_storage Something_that_operates_on_data
Die Syntax ist ziemlich umständlich. Sehr kraftvoll und doch primitiv.

sven
hat einige interessante Arbeiten darüber, was mit Docker, dem Verwaltungstool zum Verbinden von Volumes, los ist – ich denke, sie sind auf dem Weg zu 1.4, ich werde einige Nachforschungen anstellen. (Es gäbe eine Docker-Volume-Liste und etwas zum Bearbeiten)
Ich würde wahrscheinlich ein Backup-Daten-Volume im Container erstellen und dann eine Datenmigration des Images ausführen, das ich ausführen möchte, verbunden mit den Daten und Backup-Daten – das würde wahrscheinlich reichen Das erste ist, dass die Daten von „backup_data“ nach „backup_data“ kopiert werden und dann die Datenmigration durchgeführt wird.
Sie können dann die alte und die neue Version ausführen, verbunden mit dem jeweiligen Daten-Backend (möglicherweise mit Anhängen einer schreibgeschützten Sicherung?)
Dadurch sollte die Installation weitgehend gleich sein, unabhängig davon, welchen Host Sie verwenden eine Stildarstellung direkt oder über einen Datencontainer.

matlehmann
Ihr Vorschlag ist meine erste Ideenlinie, aber er entspricht nicht meinen Erwartungen, da nach dem Prozess die migrierten Daten und die Originaldaten einen anderen Weg haben, glaube ich Ich sehe keine Möglichkeit, dies zu ändern, da Nicht-Host-Volumes nicht auf einem anderen Pfad erneut bereitgestellt werden können. Der Pfad zu einem Volume von einem Datencontainer ist statisch – auch für Volume-Container, die von „--volumes-from“ geerbt wurden.
Dies ist für das Host-Volume anders, da ich deren Mount-Standorte bei jedem Docker-Run-Aufruf ändern kann.
Ich denke, es ist sehr wichtig, dass Sie über diese Volume-Management-Tools sprechen. Für mich fühlt sich diese Docker-Sprache für Datencontainer eher wie eine Problemumgehung an.
Entschuldigung, sagen Sie „Docker-Commit ist großartig“, weil ich es jedoch nicht sehen kann? Zumindest mit dem vorliegenden Anwendungsfall. Soweit ich weiß, enthält ein Docker-Commit für mich ein neues Bild des aktuellen Status des Containers. Dies umfasst alle Betriebssystemdaten, die mich interessieren, mit Ausnahme der persistenten Daten.

sven
Oh Mist. Sie haben Recht, der Volume-Pfad ist derzeit statisch. Sie benötigen also einen Schritt
1. Sie haben einen vorhandenen Datencontainer in /data
2. Migrieren Sie zum temporären Datencontainer in /migration (wenn Sie eine Originalinstallation haben)
3./migrate Migrieren Sie die Daten nach Der neu aktualisierte Datencontainer/die neu aktualisierten Daten (das zweite Migrationsimage muss nicht in der ursprünglichen Datenkapazität installiert werden
@cpuguy83 kann Ihnen möglicherweise mehr über das neue Tool smile
WRT Docker Commit sagen – wenn Sie es begehen erstellen Sie nicht eine einzelne Bildebene, die alles enthält, sondern eine neue Bildebene, die alle im Container vorgenommenen Änderungen enthält (die beim Starten des Bildcontainers verwendet werden). Wenn Sie also anstelle eines Containers persistente Daten verwenden und Dinge wie Protokolle ausrollen, Sie könnten Docker verwenden, um Snapshots/Backups nur Ihrer persistenten Daten zu übertragen – und mit den Exporten von Docker könnten Sie diese Ebenen speichern
cpuguy83

Ja, darauf würde ich mich nicht verlassen. commit“, da Sie auf 127 Commits beschränkt sind, es sei denn, Sie reduzieren das Image

@matlehmann siehe github.com/cpuguy83/ docker-volumesDies ist alles andere als eine perfekte Lösung, funktioniert aber in der Zwischenzeit ziemlich gut

matlehmann
@Sven Danke für deine Antwort und für weitere Informationen. Ich verstehe Schritt 3 von „/Migration von Daten in den neu aktualisierten Datencontainer, der in /data installiert ist (das zweite Migrationsimage erfordert nicht die Installation der ursprünglichen Datenkapazität) immer noch nicht in der aktuellen Form (mit Docker1.2 und ( kein spezieller Volume-Befehl), ich sehe nicht, wie ich einen Container mit dem Volume eines anderen Containers haben kann – ein Teil davon ist gemountet und ein Teil davon ist nicht gemountet. Nach dem, was ich gesehen habe, ist es entweder alles oder nichts oder „- -“. volumes-from other_container“ oder nicht. Wenn also für den migrierten Container aus Schritt 2 die Originaldaten gemountet sind, wurde der Container in Schritt 3 gemountet, und daher überschreibt der Kopiervorgang von /mifrated nach /data die Originaldaten. Dennoch Ich habe etwas verloren?
Danke für den Tipp, ich muss noch etwas darüber nachdenken, um mich vorzubereiten

matlehmann
@keeb Das ist ein guter Modus, aber Soweit ich sehen kann, löst es nicht das Problem, worüber ich spreche. Alle diese „Pipe“-Container werden am Ende immer noch das Volumen von „some_pipe_storage“ haben, ohne dass zu einem bestimmten Zeitpunkt ein anderer Container erstellt werden kann Pfad. Andere Daten, ohne die ursprünglichen Daten zu überschreiben.

Sven
Hmm, mal sehen, ob ich das hinbekomme. Die Erklärung ist ein Beispiel:
Angenommen, jemand hat einige Docker-Images erstellt, webappv10, webappv11, webapp_migratorv10_to_v11.
Zunächst haben Sie ein 1.0-basiertes System ausgeführt.
docker run -v /data --name datav10 busybox true
docker run -p 80:80 --volumes-from datav10 --name webv10 webappv10
dann aktualisieren, fragen Sie mich nach dem Upgrade, Sie werden Schritt 2 ausführen (wie Sie bereits betont haben, können wir nicht zwei Volumes in der Datei enthalten gleiches Verzeichnis)
docker run -v /migration --name datav10-to-v11 busybox true
docker run --volumes-from datav10-to-v11 --volumes-from datav10 - -name migration webapp_migratorv10_to_v11
Dann Schritt 3, migrieren Sie die kopierten Daten in einen neuen Datencontainer und bereiten Sie die Daten im Verzeichnis /data mit
docker run -v /data --volumes-from datav10-to -v11 --name datav11 busybox cp vor -r /migration /data
und dann die Webanwendung der Version 1.1 ausführen
docker run -p 80:80 --volumes-from datav11 --name webv11 webappv11
und mehr Zu Ihrer Ehre, Sie sollten besser ein Skript erstellen alles.
Die Aktualisierung der Container-Volumenerhöhung von datav10 auf V11 erfolgt aufgrund der folgenden Diskussion

matlehmann
@sven Nochmals vielen Dank für Ihre ausführliche Antwort. Ich schätze Ihre Gedanken und Zeit.
Die von Ihnen beschriebene Vorgehensweise funktioniert jedoch nicht. Es ruft Volumes mit „-v“ auf und widerlegt damit die Annahme, dass ein Volume denselben Pfad wie „--volumes-from“ erbt. Ich habe es gerade noch einmal getestet, um sicherzugehen, aber das ist nicht der Fall. Deshalb führt Docker -v / data aus --volumes-from migration --name datav11 busybox cp -r /migration /data überschreibt meinen ursprünglichen Datencontainer datav10

sam
, der Ihnen gefällt Der Datencontainer befindet sich aus einem bestimmten Grund in einem einfachen Band (z. B. weil es leichter zu verstehen/zu verarbeiten ist)

sven
Ich bin verwirrt über die Schritte, die es auszuarbeiten gilt. Nicht 2 Bände von enthält /data dils-Anweisung. Wir migrieren einen Puffer und kopieren ihn dann in den neuen Daten-v11-Container
@sam – Es gibt einen kleinen konzeptionellen Unterschied – Sie sind Ich mache immer noch die gleichen 3 Schritte – der größte Unterschied besteht für mich darin, dass das Binden von Mounts nur lokal funktioniert, und das setzt voraus, dass Sie über den Speicherplatz dafür verfügen (nicht, dass ich das getan hätte), während die Volume-Container-Methode davon ausgeht, dass Ihre Docker-Datenpartition groß ist reicht aus, um den Docker-Container auszuführen, und funktioniert genauso wie die lokale Fernbedienung, wenn Sie die Zeilen „docker run -v /data ...“ in „docker run -v /local/data ...“ ändern und dann „bind mounts to“ verwenden bind mount, im Auftrag von

matlehmann@SAM Ich wechsle jetzt zur Verwendung von bind-mounted bind mount (oder jeder offizielle Begriff ist „-v /host:/container“) für Volumes, und anstatt Datencontainer aufgrund der in diesem Thread aufgeführten Nachteile zu verwenden, habe ich aufgrund der im Internet verwendeten und empfohlenen Redewendung begonnen, Datencontainer zu verwenden. Scheint der „offizielle Weg“ zu sein

matlehmann@sven
?"datav10" has ?"/data" (via -v /data)

?"migration" has ?"/ data" (via --volumes from datav10)?"/migration" (via `-v /migration')

?"datav11" has ?"/data" ( via -v /data)?"/migration" (via --volumes from migration)
?"/data" (via --volumes -from migration)

Wir haben also den „/data“-Container „datav11“ mit zwei definierten Volumes – für mich sieht es aus wie --volumes-from win one .

sam @sven Ich denke, ich versuche nur herauszufinden, warum Sie die Daten in AUFS speichern. Es scheint das falsche Dateisystem für dieses Problem zu sein . BTRFS wäre in Ordnung, aber aufs scheint eine seltsame Wahl für Protokolldateien, die Verwendung von Postgres-Datenbanken usw. zu sein. Verstehe ich die Mechanik von Datencontainern falsch?

@matlehmann Wir verwenden „Volumen“ häufig.
Wir speichern auf dem Host bereitgestellte Volumes in handelsüblichen Containern, um eine einfache Rotation und Persistenz aller Protokolle zu gewährleisten. (Hier ist eine weitere Option, die das Streamen aus dem Container wäre, aber der Mechanismus ist nicht trivial. Denken Sie beispielsweise an einen NGINX-Container. Verwenden Sie Protokolle?)
Wir speichern einige Konfigurationen auf einem bereitgestellten GlusterFS-Volume, also was wir kann auf der ganzen Farm absorbieren

matlehmann
@sven Dies wird ein Thema für einen anderen Thread sein: Ich würde wirklich gerne etwas über Ihr GlusterFS-Setup hören. Gibt es ein gebrauchsfertiges Image, das als repräsentatives Volume in GlusterFS verwendet werden kann, oder wie macht man das?

sam
@supermathie wäre am besten für Details zu unserem GlusterFS-Setup geeignet, aber das gesamte Setup erfolgt auf sehr traditionelle Weise und wir verwenden keinen vertrauenswürdigen Docker-Container aktiviert Gluster.

sven
OH(*&^, du hast recht.
Ich dachte, ich wäre so schlau, einen Schritt zu löschen.
Du musst das /migrate verschieben Ordner zum eigenen Datencontainer, damit Sie das Problem vermeiden, das Sie im letzten Schritt bemerkt haben
Ich habe die einstufigen Beispielschritte aktualisiert, um dies widerzuspiegeln

Sven

Ja, es gibt einige Dinge bezüglich Dateisystemen Um das herauszufinden – auf meinen Dockern läuft größtenteils BTRFS Ich denke, die Installation funktioniert auch – aber ich werde trotzdem eine Verknüpfung zu ihnen herstellen und dann den gleichen Prozess wie oben verwenden

matlehmann

@sven Ich habe das noch nicht ausprobiert, aber es macht Sinn. Es ist ein seltsamer, verrückter Hühnertanz, aber es könnte funktionieren. Ich warte sehnsüchtig auf die Brötchenbestellung

sven

Ja, ich konzentriere mich auf das tollpatschige Hähnchen – ich freue mich auf diese Versionen und die gegrillten Hähnchenschenkel zum Verschlingen

Dieser Artikel wurde aus dem offiziellen Docker-Forum übersetzt:

https://forums.docker.com/t/upgrade-data-within-data -container/205/20 Das Obige stellt einen der am häufigsten beantworteten Beiträge im offiziellen Docker-Forum vor, „Upgrading Data in Data Containers“, einschließlich relevanter Inhalte. Ich hoffe, dass er für Freunde hilfreich sein wird, die sich für PHP-Tutorials interessieren.