Docker Swarm はボリューム共有をどのように実装しますか? 質問する

Docker Swarm はボリューム共有をどのように実装しますか? 質問する

Docker Swarm は次の 2 種類のストレージを管理できます。

volumeそしてbind

bindこれはローカル ディレクトリ (各 swarm ノード上) とタスク間のバインディングを作成するため、Docker ドキュメントでは提案されていませんが、実装については言及volumeされていないため、タスク間でボリュームがどのように共有されるのかわかりません。

  • Docker Swarm はノード間でボリュームをどのように共有しますか?
  • ボリュームはどこに保存されますか (マネージャー上ですか? マネージャーが複数ある場合は?)
  • 異なるネットワーク上の異なるマシンで実行されている場合、ノード間で問題は発生しませんか?
  • VPN を作成しますか?

ベストアンサー1

Swarm モード自体はボリュームに対して特別な処理は行いません。コンテナが稼働しているノード上で、指定したボリューム マウント コマンドを実行します。ボリューム マウントがそのノードに対してローカルである場合、データはそのノード上にローカルに保存されます。ノード間でデータを自動的に移動する機能は組み込まれていません。

GlusterFS、Rook、Ceph、Longhorn などのソフトウェア ベースの分散ストレージ ソリューションがいくつかあります。これらの多くは Kubernetes との統合に重点を置いていますが、Swarm では役に立ちません。

典型的な結果として、アプリケーション内でストレージのレプリケーションを管理するか (etcd やその他の raft ベースのアルゴリズムなど)、外部ストレージ システム (できれば独自の高可用性を備えたもの) でマウントを実行する必要があります。外部ストレージ システムのマウントには、ブロック ベースとファイル ベースの 2 つのオプションがあります。ブロック ベースのストレージ (EBS など) は通常、パフォーマンスが高くなりますが、マウントできるのは 1 つのノードに限られます。このためには、通常、サードパーティのボリューム プラグイン ドライバーを使用して、Docker ノードにそのブロック ストレージへのアクセスを許可する必要があります。ファイル ベースのストレージ (EFS など) はパフォーマンスが低くなりますが、移植性が高く、複数のノードに同時にマウントできるため、複製されたサービスに役立ちます。

最も一般的なファイルベースのネットワーク ストレージは NFS です (これは EFS で使用されるのと同じプロトコルです)。また、サードパーティのプラグイン ドライバーなしでマウントできます。Docker に同梱されている「ローカル」ボリューム プラグイン ドライバーは、ドライバー オプションを使用してマウント コマンドに必要な値を渡すオプションを提供します。オプションがない場合、ボリュームはデフォルトで docker ディレクトリ /var/lib/docker/volumes に保存されます。オプションを使用すると、NFS パラメーターを渡すことができ、NFS ホスト名で DNS ルックアップも実行できます (NFS では通常実行されないことです)。ローカル ボリューム ドライバーを使用して NFS ファイルシステムをマウントするさまざまな方法の例を次に示します。

  # 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"
  ...

最後にある Compose ファイルの例を使用する場合、ボリュームへの変更 (サーバー パスまたはアドレスの更新など) は、既存の名前付きボリュームには反映されないことに注意してください。ボリュームの名前を変更するか、ボリュームを削除して、Swarm が新しい値でボリュームを再作成できるようにする必要があります。

NFS の使用でよく見られるもう 1 つの一般的な問題は、サーバー上で「ルート スカッシュ」が有効になっていることです。これにより、ルートとして実行されているコンテナーがボリュームにファイルを書き込もうとすると、権限の問題が発生します。また、コンテナーの UID/GID がボリュームへの書き込み権限を必要とする場合にも同様の UID/GID 権限の問題が発生するため、NFS サーバーでディレクトリの所有権と権限を調整する必要がある場合があります。

おすすめ記事