docker engine swarmモードで複数のホスト間でボリュームを共有する方法は？
Docker Engine Swarmモードで複数のホスト間で共通/単一の名前付きボリュームを共有できますか？それを行う最も簡単な方法は何ですか？
NFSサーバーがセットアップされている場合は、次のようにdocker composeからのボリュームとしていくつかのnfsフォルダーを使用できます。
volumes:
grafana:
driver: local
driver_opts:
type: nfs
o: addr=192.168.xxx.xx,rw
device: ":/PathOnServer"
ゼロから、Docker自体はこれをサポートしていません。ボリュームの新しいレイヤータイプを提供するドッカープラグイン、またはFSで直接データを同期する同期ツールを使用して、追加のコンポーネントを使用する必要があります。
私の観点からは、最も簡単な解決策はrsyncまたはより正確にはlsyncdn rsyncのデーモンバージョンです。しかし、私はドッカーボリュームにそれを試したことがないので、それがうまく処理できるかどうかはわかりません。他のソリューションは Infinit.sh を使用して提供されます。基本的にはlsyncdと同じです。これは一方向の同期です。そのため、DockerコンテナーがそのボリュームでRWである場合、期待と一致しません。私はこのソリューションを試してみましたが、ROの操作には問題なく動作します。運用環境にはありません。まだアルファ版です。Infinitは、Dockerドライバを提供する途中です。まだリリースされていません。だから私もそれを試していませんでした。
私が見つけたがインストールできなかった（そして試すことができない）他の解決策は、flockerとglusterFSです。どちらも、複数のマシンから複数のHDDに基づいてFSボリュームを作成するように設計されています。しかし、この数週間、リポジトリはどれも機能していませんでした。
弱い解決策しか出せなくて申し訳ありませんが、私は同じ問題に直面しており、まだ完璧な解決策を見つけていません。
乾杯、オリヴィエ
物事の壮大な計画で
他の答えは間違いなく正しいです。まだ何かが足りない、またはこの領域では物事が実際には改善されない可能性があるという結論に達していると感じた場合は、典型的なPOSIXのような階層型ファイルシステムの抽象化の使用を再検討することをお勧めします。すべてのアプリケーションが実際にそれを必要とするわけではありません（必要なアプリケーションがほとんどない場合もあります）。多分あなたもそうではありません。
ファイルシステムの防御
それは多くのサークルでまだ非常に一般的ですが、通常これらの人々はリモート/分散ファイルシステムをよく知っており、それらを適切に設定して活用する方法を知っています（また、既存のDockerボリュームドライバーではない場合もあるが、非常に優れたシステムである場合もあります） ）。時々、それは単に強制されているためでもあります（他のストレージバックエンドをサポートするために書き換えることができない、または書き換えるべきでないコードベース）。任意のDockerボリュームドライバーを使用、構成、または作成することは、二次的な問題にすぎません。
代替案
ただし、オプションがある場合は、アプリケーションの他の永続化ソリューションを評価してください。多くの実装はPOSIXファイルシステムインターフェイスを使用しませんが、代わりにネットワークインターフェイスを使用します。これにより、Docker Swarmなどのクラスターに特定のインフラストラクチャレベルの問題が発生しなくなります。
サードパーティ（クラウドプロバイダーなど）が管理するソリューション
永続データと共有データのファイルシステムへのすべての依存関係の削除に成功した場合（transientローカル状態でも問題ありません）、完全に「ステートレス」なアプリケーションがあると主張するかもしれません。もちろん、いつでもどこかに永続化された状態が常にあることがよくありますが、アイデアは自分で処理しないことです。多くのクラウドプロバイダー（ホストしている場合）は、永続的な状態を処理するための完全に管理されたソリューションを提供するため、まったく気にする必要がありません。この方法を使用する場合は、テストにローカルで使用できる実装と互換性のあるAPIを使用するマネージドサービスを検討してください（たとえば、サードパーティまたはその提供によって提供されるその実装のイメージに基づいてDockerコンテナーを実行することによって）あなた自身を維持することができます）。
DIYソリューション
Docker Swarmクラスター内で永続的な状態を自分で管理したい場合は、ファイルシステムの抽象化が避けられないことがよくあります（とにかく、ブロックデバイスを直接ターゲットにすることはさらに困難になるでしょう）。データを永続化するために使用するものの要件が確実に満たされるように、ノードとサービスの制約を試してみる必要があります。中央のDBMSサーバーのような特定の場合には、それは簡単です（「常に特定のノードでのみタスクを実行する」）。
そのようなセットアップのセットアップ、スケーリング、およびモニタリングのタスクは、決して簡単なものではありません。そのため、多くのアプリケーション開発者が他の誰か（クラウドプロバイダーなど）に任せて喜んでいます。それでも、探索するのに非常に便利なスペースですが、その質問をしなければならなかったとしても、締め切りが迫っている場合は、それを重視する必要はないでしょう。
結論
いつものように、仕事に適切な抽象化を使用し、一時停止して、自分の長所とは何か、リソースをどこに費やすかについて考えます。