web-dev-qa-db-ja.com

名前付きボリュームのdocker-compose.yml構文

名前付きボリュームのホストパスを指定するためのdocker-compose.yml構文は何ですか？

docker-compose.yml：

volumes:
  myvolume:  # how do I specify path here?
  othervolume:

services: # etc...

docs を確認しましたが、見つかりません。正直なところ、私は誰がどのようにこれを使っているのかわかりません。

dockerdocker-composedocker-volume
6
Petrus Theron

コンポーズボリュームの一般的なシナリオは、ローカルボリュームドライバーにマップし、/ var/lib/docker/volumesにボリュームを配置するデフォルトの名前付きボリュームを使用することです。あなたが探しているものではありませんが、これは多くの人にとって簡単なオプションです：

version: '3'
volumes:
  myvolume:
  othervolume:    
services:
  myservice:
    volumes:
      - myvolume:/volume/path

ホストボリュームをマップする一般的な方法は、パスを直接指定することです。ボリュームに名前は必要ありません。繰り返しますが、あなたが求めているものではありませんが、実装は非常に簡単です。これはカバーの下のバインドマウントです。

version: '3'
services:
  myservice:
    volumes:
      - ./path:/volume/path

名前付きボリュームとホストボリュームを一緒にしたい場合、探しているのはバインドマウントを使用するように構成された名前付きボリュームです。これには、ディレクトリが存在しない場合に失敗するという欠点がありますが、Dockerが空のディレクトリをイメージのコンテンツに初期化できるという利点があります。

version: '3'
volumes:
  myvolume:
    driver: local
    driver_opts:
      type: none
      o: bind
      device: /Host/path/to/volume
services:
  myservice:
    volumes:
      - myvolume:/container/volume/path

バインドマウントの欠点は、コンテナ上のuid/gidを使用してコンテナによって管理されるファイルを、ホスト上の他のユーザーが使用する可能性のあるパス内に配置することです。その結果、ホスト上またはコンテナ内のいずれかで権限の問題が発生します。これを回避するには、2つの間でuid/gidを揃える必要があります。

2
BMitch

同じリファレンスドキュメントで、サンプルdocker-compose.ymlの完全な拡張バージョンを確認できます

https://docs.docker.com/compose/compose-file/#compose-file-structure-and-examples

名前付きボリュームのマウントについては、dbセクションを参照してください。

  db:
    image: postgres:9.4
    volumes:
      - db-data:/var/lib/postgresql/data
    networks:
      - backend
    deploy:
      placement:
        constraints: [node.role == manager]
0
fly2matrix