Dockerと共有されるホストボリュームにNFSディレクトリをマウントします。

Dockerと共有されるホストボリュームにNFSディレクトリをマウントします。

次のDockerコンテナを検討してください。

docker run --rm -it -v /tmp:/mnt/tmp alpine sh

これにより、ホストディレクトリ/ tmpがアルパインコンテナ内の/ mnt / tmpにマウントされます。

これで、ホストシステムはNFSボリュームを/ tmpディレクトリにマウントします。

mkdir /tmp/nfs
mount -t nfs4 192.168.1.100:/data /tmp/nfs

インストールがホストシステムで実行され、次のものが表示されます。

# ls /tmp/nfs
file1 file2 file3
#

しかし、Dockerコンテナには空のディレクトリがあります。

# ls /mnt/tmp/nfs
#

Dockerコンテナに直接マウントすると、この問題を解決できることがわかります。しかし、マウントがホストコンテナでは動作しますが、Dockerコンテナでは動作しない理由を本当に知りたいです。

ベストアンサー1

これは、ボリュームがprivateマウント伝播を使用しているために発生します。つまり、マウントが発生すると、ソース側(Dockerの「ホスト」側など)で行われたすべての変更はマウントの下に表示されません。

この問題を処理する方法はいくつかあります。

  1. NFSを最初にマウントしてコンテナを起動します。マウントはコンテナに伝播されますが、以前と同様に、マウントに対する変更(マウント解除を含む)はコンテナには表示されません。

  2. 「サブ」電波を使用します。つまり、マウントが作成されると、ソース(Dockerホスト)に対するすべての変更がターゲット(コンテナ)に表示されます。ネストしたインストールを実行する場合rslaver再帰)を使用することをお勧めします。

「共有」通信もあります。このモードでは、マウントポイントの変更がコンテナ内からホストに、またはその逆に伝播されます。あなたのユーザーはそのような変更を行う権限がないので(CAP_SYS_ADMINを追加しない限り)これはおそらくあなたが望むものではありません。

次のようにインストールを作成するときに伝播モードを設定できます。

$ docker run -v /foo:/bar:private

別のオプションは、ホストマウントの代わりにボリュームを使用することです。次のことができます。

$ docker volume create \
    --name mynfs \
    --opt type=nfs \
    --opt device=:<nfs export path> \
    --opt o=addr=<nfs host> \
    mynfs
$ docker run -it -v mynfs:/foo alpine sh

これにより、特定の方法でホストを設定したりマウント伝播を処理したりすることなく、常にコンテナにマウントを実行できます。
ノート:デバイスパスの前半が必須ですが、nfsカーネルモジュールが少し奇妙です。
ノート:Dockerは現在<nfs host>DNS名を解決できないため(1.13にある予定です)、ここにIPアドレスを提供する必要があります。

「共有サブツリー」のインストールの詳細:https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt

おすすめ記事