wake-up-neo.com

Wie teile ich Volumes auf mehreren Hosts im Docker-Engine-Schwarmmodus?

Können wir im Docker-Engine-Schwarmmodus ein gemeinsames/einzelnes benanntes Volume für mehrere Hosts freigeben, wie geht das am einfachsten?

16
vivekyad4v

Wenn Sie über ein NFS-Server-Setup verfügen, können Sie einige nfs-Ordner als Volume aus dem Docker-Composer verwenden.

volumes:
    grafana:
      driver: local
      driver_opts:
        type: nfs
        o: addr=192.168.xxx.xx,rw
        device: ":/PathOnServer"
2
herm

Von Grund auf unterstützt Docker dies nicht für sich. Sie müssen zusätzliche Komponenten verwenden, entweder ein Docker-Plugin, mit dem Sie einen neuen Layer-Typ für Ihre Volumes erhalten, oder ein Synchronisierungstool direkt auf Ihrem FS, das die Daten für Sie synchronisiert.

Aus meiner Sicht ist die einfachste Lösung rsync oder genauer lsyncdn der Daemon-Version von rsync. Aber ich habe es nie für Docker-Volumes ausprobiert, daher kann ich nicht sagen, ob es damit zurechtkommt. Andere Lösungen werden mit Infinit.sh angeboten. Es macht im Grunde dasselbe wie lsyncd. Es ist eine Einweg-Synchronisierung. Wenn Ihr Docker-Container also RWs in seinen Volumes hat, entspricht dies nicht Ihren Erwartungen. Ich habe diese Lösung ausprobiert und sie funktioniert ziemlich gut für RO -Operationen. Und nicht in der Produktion. Es ist immer noch eine Alpha-Version. Infinit ist auch unterwegs, um einen Docker-Treiber bereitzustellen. Noch nicht veröffentlicht. Also habe ich es nicht einmal probiert. Zu riskant.

Andere Lösungen, die ich gefunden habe, aber nicht installiert werden konnte (und so versucht wurde), sind Flocker und GlusterFS. Beide sind so konzipiert, dass sie FS Volume basierend auf mehreren Festplatten von mehreren Maschinen erstellen. Aber in den letzten Wochen hat keines ihrer Repositories funktioniert.

Es tut mir leid, dass ich Ihnen nur schwache Lösungen gebe, aber ich stehe vor demselben Problem und habe noch keine perfekte Lösung gefunden.

Prost, Olivier

0
Olivier

Im großen Schema der Dinge

Die anderen Antworten sind definitiv richtig. Wenn Sie das Gefühl haben, dass Sie immer noch etwas vermissen oder zu dem Schluss kommen, dass sich die Dinge in diesem Bereich möglicherweise nicht wirklich verbessern, sollten Sie die Verwendung der typischen POSIX-ähnlichen hierarchischen Dateisystem-Abstraktion überdenken. Nicht alle Anwendungen brauchen es wirklich (ich könnte sagen, dass nur wenige es tun). Vielleicht auch nicht.

Zur Verteidigung von Dateisystemen

Es ist in vielen Kreisen immer noch sehr verbreitet, aber normalerweise kennen diese Leute ihre dezentralen/verteilten Dateisysteme sehr gut und wissen, wie sie eingerichtet und richtig eingesetzt werden müssen (und es kann auch sein, dass sie sehr gute Systeme sind, obwohl sie oft nicht mit den vorhandenen Docker-Volume-Treibern arbeiten) ). Manchmal liegt es auch daran, dass sie dazu gezwungen werden (Codebases, die nicht neu geschrieben werden können oder sollen, um andere Speicher-Backends zu unterstützen). Das Verwenden, Konfigurieren oder sogar das Schreiben beliebiger Docker-Volume-Treiber wäre nur ein zweitrangiges Anliegen.

Alternativen

Wenn Sie jedoch die Option haben, sollten Sie andere Persistenzlösungen für Ihre Anwendungen auswerten. Bei vielen Implementierungen werden keine POSIX-Dateisystemschnittstellen verwendet, sondern Netzwerkschnittstellen, die in Clustern wie Docker Swarm keine besonderen Probleme auf Infrastrukturebene darstellen.

Von Dritten verwaltete Lösungen (z. B. Cloud-Anbieter)

Wenn es Ihnen gelingt, alle Abhängigkeiten zu Dateisystemen für persistente und gemeinsam genutzte Daten zu entfernen (dies ist immer noch für transient local zustand), können Sie behaupten, vollständig "zustandslose" Anwendungen zu haben. Natürlich gibt es oft immer noch irgendwo einen Staat, aber die Idee ist, dass Sie nicht selbst damit umgehen. Viele Cloud-Anbieter (wenn Sie dort Hosting betreiben) bieten vollständig verwaltete Lösungen für den Umgang mit persistenten Zuständen, sodass Sie sich überhaupt nicht darum kümmern müssen. Berücksichtigen Sie auf dieser Route Managed Services, die APIs verwenden, die mit Implementierungen kompatibel sind, die Sie lokal zum Testen verwenden können (z. B. durch Ausführen eines Docker-Containers basierend auf einem Image für diese Implementierung, das von einem Drittanbieter oder einem Drittanbieter bereitgestellt wird) du kannst dich selbst pflegen).

DIY-Lösungen

Wenn Sie den persistenten Status innerhalb eines Docker Swarm-Clusters selbst verwalten möchten, ist die Abstraktion des Dateisystems oft unvermeidlich (und Sie hätten wahrscheinlich mehr Schwierigkeiten, Blockgeräte direkt anzusprechen). Sie sollten mit Knoten- und Diensteinschränkungen spielen, um sicherzustellen, dass die Anforderungen der von Ihnen verwendeten Daten zum Behalten von Daten erfüllt werden. Bei bestimmten Dingen wie einem zentralen DBMS-Server könnte dies einfach sein ("Task immer nur auf diesem bestimmten Knoten ausführen"), bei anderen kann es wesentlich komplizierter sein.

Das Einrichten, Skalieren und Überwachen eines solchen Setups ist definitiv nicht trivial, weshalb viele Anwendungsentwickler dies gerne von einem anderen Benutzer (z. B. Cloud-Anbieter) ausführen lassen. Es ist immer noch ein sehr cooler Ort zum Erkunden, auch wenn Sie diese Frage stellen mussten, ist es wahrscheinlich nicht etwas, worauf Sie sich konzentrieren sollten, wenn Sie eine Frist einhalten.

Fazit

Verwenden Sie wie immer die richtige Abstraktion für den Job und überlegen Sie, welche Stärken Sie haben und wo Sie Ihre Ressourcen einsetzen.

0
tne