Docker Composev1.6.0 +では、docker-compose.yml
ファイルの新しい/バージョン2ファイル構文が追加されました。変更には、volumes
という名前の個別の最上位キーが含まれます。これにより、ボリューム定義を1か所に「集中化」できます。
私がしようとしているのは、そこにボリュームをnameして、ローカルホストディスク上の複数のパスを参照する単一のボリュームを持つことです。以下は、Traceback
で終わる例外をスローする例です。
AttributeError: 'list' object has no attribute 'items'
例docker-compose.yml
:
version: '2'
services:
db:
image: postgres
volumes:
- database:/var/lib/postgres/data
php:
image: php-fpm:5.6
volumes:
- phpconf:/etc/php/conf.d
namedvolume:
container_name: namedvolume
build: ./Docker/Testvolume
volumes:
- ./Docker/Testvolume/shareme
volumes:
database:
- ./Docker/Postgres/db:ro
- ./Docker/Postgres/ini
phpconf:
- ./Docker/PHP-FPM/conf
singledir: ./Docker/foo
completemap: ./Docker/bar:/etc/service/conf.d
- namedvolume:/etc/service/conf.d # < this was a separate attempt w/o the other keys
… ?
これまでのところ、すべての Docker Compose docs master
- branch ボリューム構成のリファレンスを読み、 Docker Compose docs Volume/Volume-Driverのリファレンスを読み、調べました- GitHubの例 予想される正しい構文を検索します。誰もすでにそれを使用していないようで(GitHub)、ドキュメントは完全ではありません(docker.com)。また、別のボリュームをservice
として構築してvolumes
で参照しようとしましたが、それも機能しません。この構文の見方はどのようになっていると思いますか?
volumes
キーの目的名前付きボリュームを作成するためにあります。
使用する場合使用しないと、ボリュームのハッシュ値の束が表示されます。例:
$ docker volume ls
DRIVER VOLUME NAME
local f004b95d8a3ae11e9b871074e9415e24d536742abfe86b32ffc867f7b7063e55
local 9a148e167e1c722cbdb67c8edc36f02f39caeb2d276e9316e64de36e7bc2c35d
名前付きボリュームでは、次のようなものが得られます。
$ docker volume ls
local projectname_someconf
local projectname_otherconf
docker-compose.yml
構文は次のとおりです。
version: '2'
services:
app:
container_name: app
volumes_from:
- appconf
appconf:
container_name: appconf
volumes:
- ./Docker/AppConf:/var/www/conf
volumes:
appconf:
networks:
front:
driver: bridge
これは、上記の名前付きボリュームのようなものです。
ハッシュがたくさんある場合、クリーンアップするのはかなり難しい場合があります。ここにワンライナーがあります:
docker volume rm $(docker volume ls |awk '{print $2}')
編集: @ArthurTaccaがコメントで指摘したように、覚えやすい方法があります。
docker volume rm $(docker volume ls -q)
ハッシュを検索する必要がなくなったので、続けてハッシュを呼び出すことができます。…name:
docker volume inspect <volume_name>
# Example:
$ docker volume inspect projectname_appconf
[
{
"Name": "projectname_appconf",
"Driver": "local",
"Mountpoint": "/mnt/sda1/var/lib/docker/volumes/projectname_appconf/_data"
}
]
サイドノート:docker-compose down
ボリュームを作成する前に、サービスを新たに開始してください。
Boot2Docker/Docker Machineを使用している場合は、 docker-machine ssh
およびSudo -i
を行う前にls -la /mnt/…
そのボリュームの–ホストマシンはVMDocker Machineによってプロビジョニングされた)です。
私の理解では、グローバルvolumes:
セクションを使用して
external: true
を指定しない限り、グローバルセクションのボリュームは自動作成されます。それでも、volumes:
セクションで、各サービスにそのボリュームをマウントする場所を通知する必要があります。
これは非常に簡単な例です:
version: '2'
volumes:
project:
services:
one:
volumes:
- project:/bar
two:
volumes:
- project:/foo
project
のグローバルvolumes:
エントリにより、名前付きボリュームproject
が作成されます。次に、サービス1では/bar
として、サービス2では/foo
としてマウントされます。両方のサービスがボリュームのデータを共有し、それを読み書きできます。
私はあなたがしようとしていることが可能であるとは思いません(複数のパスを単一のボリュームに変えて、異なるr/wフラグで)。 If可能です。おそらく、他の方法でこれらのプロパティを持つ名前付きボリュームを作成し、それを外部ボリュームとして追加する方法を見つけることによります。
volumes:
mymagicvolume:
external: true
あなたがやろうとしていることは、見たものとほぼ同じだと思います here 。つまり、現在、ホスト上のマウントポイントを参照する名前付きボリュームを作成することはできません。名前付きボリュームを作成してコンテナー間でデータを共有できますが、データはボリューム自体にのみ存在し、ボリュームを削除すると消えます。
名前付きボリュームのマウントが提案されています ですが、残念ながら近い将来、コアに追加されません。ただし、 local-persist という名前のDockerプラグインを使用することで可能です。