Der Schwarmmodus selbst macht mit Volumes nichts anderes. Er führt jeden Volume-Mount-Befehl aus, den Sie auf dem Knoten bereitstellen, auf dem der Container ausgeführt wird. Wenn Ihr Volume-Mount lokal für diesen Knoten ist, werden Ihre Daten lokal auf diesem Knoten gespeichert. Es gibt keine integrierte Funktion zum automatischen Verschieben von Daten zwischen Knoten.
Es gibt einige softwarebasierte verteilte Speicherlösungen wie GlusterFS, und Docker hat eine mit dem Namen Infinit, die noch nicht GA ist, und die Entwicklung hat die Integration von Kubernetes in EE in den Hintergrund gerückt.
Das typische Ergebnis ist, dass Sie entweder die Replikation des Speichers in Ihrer Anwendung verwalten müssen (z. B. etcd und andere raftbasierte Algorithmen) oder Ihre Bereitstellungen auf einem externen Speichersystem durchführen (hoffentlich mit einem eigenen HA). Das Mounten eines externen Speichersystems bietet zwei Optionen: block- oder dateibasiert. Blockbasierter Speicher (z. B. EBS) bietet normalerweise eine höhere Leistung, kann jedoch nur auf einem einzelnen Knoten bereitgestellt werden. Zu diesem Zweck benötigen Sie normalerweise einen Volume-Plugin-Treiber eines Drittanbieters, um Ihrem Docker-Knoten Zugriff auf diesen Blockspeicher zu gewähren. Dateibasierter Speicher (z. B. EFS) weist eine geringere Leistung auf, ist jedoch portabler und kann gleichzeitig auf mehreren Knoten bereitgestellt werden, was für einen replizierten Dienst nützlich ist.
Der am häufigsten verwendete dateibasierte Netzwerkspeicher ist NFS (dies ist das gleiche Protokoll, das von EFS verwendet wird). Und Sie können dies ohne Plugin-Treiber von Drittanbietern bereitstellen. Der leider als "lokal" bezeichnete Volume-Plugin-Treiber, mit dem Docker geliefert wird, bietet Ihnen die Möglichkeit, beliebige Werte mit Treiberoptionen an den Befehl mount zu übergeben. Ohne Optionen werden standardmäßig Volumes im Docker-Verzeichnis / var / lib / gespeichert. Docker / Volumes. Mit Optionen können Sie die NFS-Parameter übergeben, und es wird sogar eine DNS-Suche für den NFS-Hostnamen durchgeführt (etwas, das Sie normalerweise mit NFS nicht haben). Hier ist ein Beispiel für die verschiedenen Möglichkeiten zum Mounten eines NFS-Dateisystems mithilfe des lokalen Volume-Treibers:
# create a reusable volume
$ docker volume create --driver local \
--opt type=nfs \
--opt o=nfsvers=4,addr=192.168.1.1,rw \
--opt device=:/path/to/dir \
foo
# or from the docker run command
$ docker run -it --rm \
--mount type=volume,dst=/container/path,volume-driver=local,volume-opt=type=nfs,\"volume-opt=o=nfsvers=4,addr=192.168.1.1\",volume-opt=device=:/host/path \
foo
# or to create a service
$ docker service create \
--mount type=volume,dst=/container/path,volume-driver=local,volume-opt=type=nfs,\"volume-opt=o=nfsvers=4,addr=192.168.1.1\",volume-opt=device=:/host/path \
foo
# inside a docker-compose file
...
volumes:
nfs-data:
driver: local
driver_opts:
type: nfs
o: nfsvers=4,addr=192.168.1.1,rw
device: ":/path/to/dir"
...
Wenn Sie am Ende das Beispiel für die Erstellungsdatei verwenden, beachten Sie, dass Änderungen an einem Volume (z. B. Aktualisieren des Serverpfads oder der Serveradresse) nicht in vorhandenen benannten Volumes berücksichtigt werden, solange sie vorhanden sind. Sie müssen Ihr Volume entweder umbenennen oder löschen, damit Swarm es mit neuen Werten neu erstellen kann.
Das andere häufige Problem, das ich bei den meisten NFS-Anwendungen sehe, ist das Aktivieren von "Root Squash" auf dem Server. Dies führt zu Berechtigungsproblemen, wenn Container, die als Root ausgeführt werden, versuchen, Dateien auf das Volume zu schreiben. Sie haben auch ähnliche Probleme mit UID / GID-Berechtigungen, bei denen die Container-UID / GID Berechtigungen zum Schreiben auf das Volume benötigt, für die möglicherweise Verzeichnisbesitz und Berechtigungen auf dem NFS-Server angepasst werden müssen.