Frage Wie kann ich zwischen einem Andock-Volume-Container und einem Andock-Volume entscheiden?


Nachdem ich die Dokumente gelesen hatte, war ich etwas verwirrt darüber, wie produktive Anwendungs- / Servicedaten am besten verwaltet werden sollten.

Es scheint 3 Möglichkeiten zu geben:

  1. Einfach Volume dem Host-Verzeichnis zuordnen (d. H. -v Argument für docker run)
  2. Erstellen Sie ein Andock-Container-Image für Daten (d. H. Separaten Container und --volumes-from)
  3. Erstellen eines Andockvolumes (d. H. docker volume create)

Nun, es scheint, dass die akzeptierte Praxis Option # 2 ist, aber dann frage ich mich, was der Zweck von # 3 ist.

Vor allem wie gehen Sie mit diesen Szenarien richtig um? docker volume Und ist es besser, für jede Situation einen Datenvolumen-Container zu verwenden?

  • Sie benötigen Anwendungsdaten in einem separaten Volume und / oder einer Speicherebene in Ihrem Server
  • Sichern
  • Wiederherstellen von Daten

22
2018-01-21 19:57


Ursprung


serverfault.com/q/576490/126632 - Michael Hampton♦
@MichaelHampton Ich erkannte, dass ich meine Frage neu formulieren sollte - dukeofgaming
# 1 ist keine ernsthafte Option für die Produktion; Es sollte grundsätzlich nie gemacht werden, wenn eine Alternative existiert. - Michael Hampton♦
@MichaelHampton Why ?, Daten werden möglicherweise nicht gedownloadet, aber das Host-Betriebssystem wird weiterhin von einem Infrastrukturteam verwaltet, das überwacht und sichert - dukeofgaming
@dukeofgaming Nicht zu erwähnen, dass Sie laufen können btrfs scrub darauf, beschädigte Dateien zu finden und zu korrigieren. Ich bin mir nicht sicher, wie funktioniert dockerized Zeug, aber ich denke, es schützt nicht vor Datenfäule, so dass ich immer eine vollständige Wiederherstellung, wenn etwas Schlimmes passiert, anstatt nur einzelne Dateien wiederherzustellen. Ein anderer Gedanke, dass es eine weitere Ebene der Abstraktion hinzufügt, so verlangsamt es das Lesen und Schreiben von Dateien noch mehr. Ich sehe irgendwie nicht die Vorteile von # 2 und # 3, aber ich habe keine Erfahrung mit Docker, also könnte sich das ändern. - inf3rno


Antworten:


Ich denke, # 2 und # 3 sind ziemlich genau das Gleiche, der Hauptunterschied ist, dass es keinen angehaltenen Container mit # 3 gibt (es ist buchstäblich nur ein benanntes Volumen). Zum Beispiel können Sie einen benannten Datenträger erstellen und auf ähnliche Weise tun, was Sie mit # 2 tun würden -v stattdessen.

Erstellen Sie ein benanntes Volume:

$ docker volume create --name test

Bereitstellen und Schreiben einiger Daten von einem Container auf dieses Volume:

$ docker run -v test:/opt/test alpine touch /opt/test/hello

Sie können dann dasselbe montieren test Datenträger in einem anderen Container und lesen Sie die Daten:

$ docker run -v test:/opt/test alpine ls -al /opt/test     
total 8
drwxr-xr-x    2 root     root          4096 Jan 23 22:28 .
drwxr-xr-x    3 root     root          4096 Jan 23 22:29 ..
-rw-r--r--    1 root     root             0 Jan 23 22:28 hello

Der Vorteil hierbei ist, dass das Volume nicht versehentlich verschwindet, wenn Sie den Nur-Daten-Container entfernen. Sie schaffen es jetzt mit dem docker volume Unterbefehl.

$ d volume ls
DRIVER              VOLUME NAME
local               test

Es eröffnet auch die Möglichkeiten für Volume-Treiber, sodass Sie möglicherweise freigegebene Volumes zwischen Hosts ausführen können (z. B. benannte Volumes über NFS). Beispiele hierfür könnten sein Flocker und Konvoi. Zu Ihrem spezifischen Punkt über das Verschieben oder Sichern von Daten verfügt Convoy über spezifische Unterbefehle zum Sichern von Daten und ermöglicht das Speichern auf NFS oder EBS extern von Ihrem Host.

Aus diesem Grund denke ich, dass der neuere Weg (Docker 1.9+) darin besteht, einen benannten Datenträger anstelle eines reinen Datencontainers zu verwenden.


16
2018-01-23 22:31



Danke, Sie haben die meisten meiner Fragen beantwortet, aber der Punkt bei der Verwaltung von Containerdaten in einer anderen physischen Datenträgerstufe ist immer noch unbeantwortet und das ist der kritische ... angenommen, dies ist eine git-repo-Managementlösung und ich brauche diesen Teil des Containers Daten (ein Volume, das in einer Dockerdatei definiert ist) in Tier 0-Speicher, der sich auf einem anderen physischen Host-Volume befindet (dh auf einer anderen Partition, einer physischen CD oder was auch immer) - dukeofgaming
ich irgendwie tat mit der Erwähnung von Volume-Treibern. Um jetzt Daten außerhalb des physischen lokalen Speichertreibers zu speichern, müssen Sie einen verwenden, der genau das erledigt, was Sie tun möchten. Aus meinem Kopf ist da github.com/rancher/convoy und github.com/ClusterHQ/flocker. Convoy unterstützt momentan NFS und GlusterFS, was dem, was Sie suchen, näher kommt. Ich werde die Antwort ändern, um dies zu verdeutlichen. - Andy Shinn
Die Verwendung des Treibers devicemapper scheint meine Frage zu beantworten, danke! docs.docker.com/engine/userguide/storagefahrer/... - dukeofgaming
the volume won't accidentally disappear if you remove the data-only container. Könnten Sie das näher ausführen? Vielen Dank. - Stephane


Erstellen von benannten Volumes mit Docker 1.9 Volumen API (docker volume create --name mydata) werden gegenüber einem Data Volume Container bevorzugt. Ab Februar 2016 der Docker Volumen Dokumentation ist bedauerlicherweise veraltet. Leute bei Docker selbst schlagen vor, dass Datenvolumen-Container "gelten nicht mehr als empfohlenes Muster""benannte Volumes sollten in den meisten Fällen (wenn nicht alle) Datenvolumes ersetzen können," und "Ich kann keinen Grund sehen, Daten-Only-Container zu verwenden. "


18
2018-02-27 20:46