web-dev-qa-db-ja.com

DockerボリュームコンテナーとDockerボリュームをどのように決めるのですか？

ドキュメントを読んだ後、生産性の高いアプリケーション/サービスデータを管理する最善の方法について、やや混乱していることに気付きました。

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

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

さて、慣行はオプション＃2のようですが、＃3の目的はなんでしょうか。

特に、docker volumeを使用してこれらのシナリオを正しく処理するにはどうすればよいですか。データボリュームコンテナーを使用するか、状況ごとにこれを使用する方が良いですか。

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

＃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を介した名前付きボリューム）を実行できる可能性があります。これの例は Flocker および Convoy です。具体的には、データの移動またはバックアップについて具体的に説明すると、Convoyにはデータをバックアップするための特定のサブコマンドがあり、ホストの外部にあるNFSまたはEBSでのストレージが可能です。

このため、より新しい方法（Docker 1.9以降）では、データのみのコンテナーではなく、名前付きボリュームを使用することを考えています。

18
Andy Shinn

Docker 1.9以降では、 Volumes API （docker volume create --name mydata）は、Data Volume Containerよりも優先されます。 2016年2月の時点で、Docker volumes documentation は非常に古くなっています。 Dockerの人々は、データボリュームコンテナー「 は推奨パターンと見なされなくなった 」、「 名前付きボリュームはほとんど（すべてではないにしても）のケースでデータのみのボリュームを置き換えることができる 」および「 データのみのコンテナを使用する理由がわからない 。」

22
Quinn Comendant