Dockerは、ローカルマシン上のコンテナーデータをバックアップおよび同期する2つの方法を提供します(つまり、volumeおよびmount)。私が気付いたいくつかのことを除いて、どちらも同じように動作します:
では、方法論にはいくつかの長所と短所がありますが、最適化に関してはまだ分類や違いがあります。
説明された回答を提供してください。
ボリュームには実際には3つのタイプがあります。
ボリュームにはソースとターゲットがあります。ソースはボリュームのタイプを識別するため、ファイル/ディレクトリへのパス(先頭のスラッシュを含む)はホストボリュームになります。ソースを提供しない場合は、匿名ボリュームを取得します。 Dockerfile内でボリュームを定義する場合、そこでソースを指定することはできません。そのため、デフォルトでdockerは、実行時に別の方法で指示しない限り、匿名ボリュームを作成します。
タイプごとに、長所と短所を次に示します。
可能な場合は、名前付きボリュームを使用します。データの初期化とuid/gidの問題のより適切な処理は、ホストボリュームの利便性よりも優先されます。 Dockerの外部でデータに直接アクセスする必要がある場合は、デフォルトのローカルドライバー設定の代わりに、バインドマウントを指す名前付きボリュームを使用してみます。この簡単な例は次のとおりです。
$ docker volume create --driver local \
--opt type=none \
--opt device=/home/user/test \
--opt o=bind \
test_vol
私のボリュームを定義するために、Dockerfileでこれを実行したくないので、私はdocker-compose.ymlを使用してそこでボリュームを定義します。 swarmモードでデプロイされている場合は、名前付きボリュームを持つNFSサーバーをポイントして、コンテナーが別のホストに移行するときにデータにアクセスできるようにします。それ以外の場合は、docker-composeで簡単に使用できるローカルの名前付きボリュームです。
Dockerfileのボリュームでは、常にボリュームとして作成する必要のあるパスをイメージで指定できます。これは本質的に、Dockerが使用するユニオンファイルシステムをバイパスします。
このようなイメージのユーザーは、実行時に常にその場所にボリュームを取得します
docker run <imagename>
つまり、-v /my/mount/point:/mount/here
を追加する理由はないので、ユーザーはそれを気にする必要はありません。
バインドマウント(上記の-v
の例のように)が必要な場合は、常に存在する必要があります。画像間での移植性はありません。
最適化の効果的な違いは次のとおりです。
これは意味がありますか?