DockerボリュームコンテナとDockerボリュームを決定する方法は？

ドキュメントを読んだ後、生産的なアプリケーション/サービスデータをどのように管理するのが最適かについて、多少混乱していることに気付きました。

3つのオプションがあるようです：

ボリュームをホストディレクトリにマップするだけです（つまりの-v引数docker run）
データ用のdockerコンテナーイメージを作成します（つまり、コンテナーとを分離します--volumes-from）
Dockerボリュームの作成（つまりdocker volume create）

今、受け入れられている慣行はオプション＃2であるようですが、＃3の目的は何ですか？

特に、これらのシナリオをどのように正しく処理しdocker volume、各状況にデータボリュームコンテナーまたはこれを使用する方がよいでしょうか？

サーバーの別のボリュームやストレージ層にアプリケーションデータが必要です
バックアップ
データの復元

storage docker

— デュークオブゲーミング
ソース

serverfault.com/q/576490/126632

— マイケルハンプトン

@MichaelHampton私は私の質問に言い換えるべきで実現

— dukeofgaming

＃1は本番環境では深刻なオプションではありません。代替手段が存在する場合は、基本的に実行しないでください。

— マイケルハンプトン

@MichaelHamptonなぜですか？データはドッキングされていないかもしれませんが、ホストOSはまだ監視およびバックアップを行うインフラストラクチャチームによって管理されています

— -dukeofgaming

@dukeofgaming言うまでもなく、実行btrfs scrubして破損したファイルを見つけて修正できます。Docker化されたものがどのように機能するかはわかりませんが、データの腐敗を防ぐことはできないため、個々のファイルを復元するのではなく、何か悪いことが起こった場合は常に完全な復元が必要です。別の考えでは、抽象化の別のレイヤーが追加されるため、ファイルの読み取りと書き込みがさらに遅くなります。私はどういうわけか2番目と3番目の利点を理解していませんが、dockerの使用経験がないため、これは変わる可能性があります。

— inf3rno

回答:

＃2と＃3はほぼ同じものだと思いますが、主な違いは、＃3で停止したコンテナがないことです（文字通り、名前付きボリュームです）。たとえば、名前付きボリュームを作成し、-v代わりに＃2を使用して同様の操作を実行できます。

名前付きボリュームを作成します。

$ docker volume create --name test

コンテナーからそのボリュームにデータをマウントして書き込みます。

$ docker run -v test:/opt/test alpine touch /opt/test/hello

その後、同じtestボリュームを別のコンテナにマウントして、データを読み取ることができます。

$ docker run -v test:/opt/test alpine ls -al /opt/test     
total 8
drwxr-xr-x    2 root     root          4096 Jan 23 22:28 .
drwxr-xr-x    3 root     root          4096 Jan 23 22:29 ..
-rw-r--r--    1 root     root             0 Jan 23 22:28 hello

ここでの利点は、データのみのコンテナーを削除しても、ボリュームが誤って消えないことです。これで、docker volumeサブコマンドで管理できます。

$ d volume ls
DRIVER              VOLUME NAME
local               test

また、ボリュームドライバーの可能性が将来的に開かれるため、ホスト間で共有ボリューム（つまり、NFSを介した名前付きボリューム）を実行できる場合があります。この例としては、フロッカーとコンボイがあります。データの移動またはバックアップについて具体的に説明すると、Convoyにはデータをバックアップするための特定のサブコマンドがあり、ホストの外部のNFSまたはEBSに保存できます。

このため、私はもっと新しい方法（Docker 1.9以降）は、データ専用コンテナーではなく名前付きボリュームを使用することだと思います。

— アンディシン
ソース

ありがとう、あなたは私の質問のほとんどに答えましたが、異なる物理ボリューム層でコンテナデータを管理するポイントはまだ答えられていません。それは重要なものです...別の物理ホストボリューム（つまり、別のパーティション、物理ディスクなど）にあるティア0ストレージのデータ（dockerfileで定義されたボリューム）

— -dukeofgaming

私は、ソートのボリュームドライバの言及していました。現時点では、物理ローカルストレージドライバーの外部にデータを保存するには、具体的には目的の操作を実行したドライバーを使用する必要があります。私の頭の上にはgithub.com/rancher/convoyとgithub.com/ClusterHQ/flockerがあります。Convoyは現在、NFSとGlusterFSをサポートしています。これを明確にするために答えを修正します。

— アンディシン

devicemapperドライバーを使用すると、私の質問に答えられるようです、ありがとう！docs.docker.com/engine/userguide/storagedriver/…– dukeofgaming 16

— 1

the volume won't accidentally disappear if you remove the data-only container。詳しく説明してもらえますか？ありがとう。

— ステファン

Docker 1.9の時点では、ボリュームAPI（docker volume create --name mydata）で名前付きボリュームを作成することは、データボリュームコンテナーよりも優先されます。2016年2月の時点で、Docker ボリュームのドキュメントは非常に古くなっています。ドッカーの人々自身がデータボリュームコンテナが「ことを示唆していない、もはや推奨パターンと見なされていない」、「例（すべてではない）という名前のボリュームは、ほとんどのデータ専用ボリュームを交換することができるはず、」と「私が使用に見ることができない理由データ専用コンテナ。」

— クイン・コメンダント
ソース