これは何？
docker for windowsでdocker-composeのボリュームマウントはどうなるのか試してみたメモです。
2つのdocker-compose.ymlでvolumesの書き方を試しています。
これはmongoDBの場合どうもうまくいかないことがあるためです。
長くなったのでtl;dr
-
docker for windowsでdocker-composeのvolumes使う場合、マウントする側のディレクトリ表記はwindows(というよりNTFS？)に合わせよう！ - WSLでの
C:\は/mnt/c -
docker for windows+docker-compose+mongoDBは避けた方が無難なのかもしれない - ⇒Docker for Windowsで
docker-composeのvolumesで気にすることを個人的にまとめた
環境とか
-
dockerホスト
- Win10 64bit Pro
- docker for windows
-
docker-compose題材1：wordpress
- mysql:5.7
- wordpress:latest
-
docker-compose題材2：wekan
- mongo:latest
- mquandalle/wekan:latest
試した
題材1：wordpress(mysql)
volumesをwindowsに合わせて書く
肝心なところ以外割愛したdocker-compose.yml
version: '3'
services:
db:
image: mysql:5.7
container_name: wordpress_db
volumes:
- C:\docker\wordpress\data:/var/lib/mysql
# - /mnt/c/docker/wordpress/data:/var/lib/mysql
これでdocker-compose up -dして、結果をpowerShellとWSL(ubuntu)で見てみる。
まずはpowerShell。
PS C:\docker\wordpress\data> ls
ディレクトリ: C:\docker\wordpress\data
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 2018/12/03 17:18 mysql
d----- 2018/12/03 17:18 performance_schema
d----- 2018/12/03 17:19 sys
d----- 2018/12/03 17:19 wordpress
-a---- 2018/12/03 17:18 56 auto.cnf
-a---- 2018/12/03 17:19 1675 ca-key.pem
-a---- 2018/12/03 17:19 1107 ca.pem
-a---- 2018/12/03 17:19 1107 client-cert.pem
-a---- 2018/12/03 17:19 1679 client-key.pem
-a---- 2018/12/03 17:19 79691776 ibdata1
-a---- 2018/12/03 17:19 12582912 ibtmp1
-a---- 2018/12/03 17:19 1342 ib_buffer_pool
-a---- 2018/12/03 17:19 50331648 ib_logfile0
-a---- 2018/12/03 17:18 50331648 ib_logfile1
-a---- 2018/12/03 17:19 1679 private_key.pem
-a---- 2018/12/03 17:19 451 public_key.pem
-a---- 2018/12/03 17:19 1107 server-cert.pem
-a---- 2018/12/03 17:19 1675 server-key.pem
続いてWSL。
root@xxxx:/mnt/c/docker/wordpress/data# ls -ltr
total 188448
-rwxrwxrwx 1 machida machida 50331648 Dec 3 17:18 ib_logfile1
-rwxrwxrwx 1 machida machida 56 Dec 3 17:18 auto.cnf
drwxrwxrwx 1 machida machida 4096 Dec 3 17:18 performance_schema
drwxrwxrwx 1 machida machida 4096 Dec 3 17:18 mysql
drwxrwxrwx 1 machida machida 4096 Dec 3 17:19 sys
-rwxrwxrwx 1 machida machida 1675 Dec 3 17:19 ca-key.pem
-rwxrwxrwx 1 machida machida 1107 Dec 3 17:19 ca.pem
-rwxrwxrwx 1 machida machida 1675 Dec 3 17:19 server-key.pem
-rwxrwxrwx 1 machida machida 1107 Dec 3 17:19 server-cert.pem
-rwxrwxrwx 1 machida machida 1679 Dec 3 17:19 client-key.pem
-rwxrwxrwx 1 machida machida 1107 Dec 3 17:19 client-cert.pem
-rwxrwxrwx 1 machida machida 1679 Dec 3 17:19 private_key.pem
-rwxrwxrwx 1 machida machida 451 Dec 3 17:19 public_key.pem
drwxrwxrwx 1 machida machida 4096 Dec 3 17:19 wordpress
-rwxrwxrwx 1 machida machida 1342 Dec 3 17:19 ib_buffer_pool
-rwxrwxrwx 1 machida machida 12582912 Dec 3 17:19 ibtmp1
-rwxrwxrwx 1 machida machida 79691776 Dec 3 17:19 ibdata1
-rwxrwxrwx 1 machida machida 50331648 Dec 3 17:19 ib_logfile0
docker-compose.ymlのvolumesで指定した通り、mysqlはちゃんとC:\docker\wordpress\dataを使ってくれている。
そして、WSLから見ると/mnt/cがそのままC:\になるということのようです。
volumesをlinuxに合わせて書く
↑が確認できたので十分なのですが、本当に興味レベルで「WSLから見えるディレクトリでマウントするように書いてWSLでdocker-compose出来るんじゃないか？」と思って試しました。
結果、うまくいかない。
肝心なところ以外割愛したdocker-compose.yml
version: '3'
services:
db:
image: mysql:5.7
container_name: wordpress_db
volumes:
# - C:\docker\wordpress\data:/var/lib/mysql
- /mnt/c/docker/wordpress/data:/var/lib/mysql
今度はこれでdocker-compose up -dしてみる。
PS C:\docker\wordpress\data> ls
root@xxxx:/mnt/c/docker/wordpress/data# ls -ltr
total 0
何も無い。なぜだろう。
しかし、docker volume lsしてやると、当たり前ですがマウントポイントはデフォルトでちゃんと切られているようです。
パターン2：wekan(mongo)
volumesをlinuxに合わせて書く(順序が逆になってすみません)
肝心なところ以外割愛したdocker-compose.yml
version: '3'
services:
wekandb:
image: mongo:latest
container_name: wekandb
expose:
- 27017
volumes:
- /mnt/c/docker/wekan/data:/data/db
# - "C:\\docker\\wekan\\data:/data/db"
これでまたdocker-compose up -dして、結果をpowerShellとWSL(ubuntu)で見てみる。
まずはpowerShell。
PS C:\docker\wekan\data> ls
root@xxxx:/mnt/c/docker/wekan/data# ls -ltr
total 0
やっぱり無い。まあ、ここは上で確認したものと同じ結果なので想定通り。
volumesをwindowsに合わせて書く
肝心なところ以外割愛したdocker-compose.yml
version: '3'
services:
wekandb:
image: mongo:latest
container_name: wekandb
expose:
- 27017
volumes:
# - /mnt/c/docker/wekan/data:/data/db
- "C:\\docker\\wekan\\data:/data/db"
いろいろ試した結果、エスケープして書いてます。
そしてdocker-compose up -d。
PS C:\docker\wekan\data> ls
ディレクトリ: C:\docker\wekan\data
Mode LastWriteTime Length Name
---- ------------- ------ ----
d----- 2018/12/03 18:01 journal
-a---- 2018/12/03 18:01 0 mongod.lock
-a---- 2018/12/03 18:01 45 WiredTiger
-a---- 2018/12/03 18:01 21 WiredTiger.lock
-a---- 2018/12/03 18:01 0 WiredTiger.wt
-a---- 2018/12/03 18:01 0 WiredTiger.wt.1
-a---- 2018/12/03 18:01 0 WiredTiger.wt.2
root@xxxx:/mnt/c/docker/wekan/data# ls -ltr
total 0
-rwxrwxrwx 1 machida machida 0 Dec 3 18:01 mongod.lock
drwxrwxrwx 1 machida machida 4096 Dec 3 18:01 journal
-rwxrwxrwx 1 machida machida 0 Dec 3 18:01 WiredTiger.wt.1
-rwxrwxrwx 1 machida machida 21 Dec 3 18:01 WiredTiger.lock
-rwxrwxrwx 1 machida machida 0 Dec 3 18:01 WiredTiger.wt.2
-rwxrwxrwx 1 machida machida 45 Dec 3 18:01 WiredTiger
-rwxrwxrwx 1 machida machida 0 Dec 3 18:01 WiredTiger.wt
やはり、windowsに準拠して書いてやればマウントできるようです。
しかし、どうみても中身が怪しい…。
そして、動かないのであった
直前の、windowsに合わせてディレクトリを書いて、mongoにマウントしてあげようとした場合です。
他は動くことを確認しました。
エラー
2018-12-03T09:01:38.612+0000 I CONTROL [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
2018-12-03T09:01:38.635+0000 I CONTROL [initandlisten] MongoDB starting : pid=1 port=27017 dbpath=/data/db 64-bit host=c8c6bd0622c9
2018-12-03T09:01:38.635+0000 I CONTROL [initandlisten] db version v4.0.4
2018-12-03T09:01:38.635+0000 I CONTROL [initandlisten] git version: f288a3bdf201007f3693c58e140056adf8b04839
2018-12-03T09:01:38.635+0000 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.2g 1 Mar 2016
2018-12-03T09:01:38.635+0000 I CONTROL [initandlisten] allocator: tcmalloc
2018-12-03T09:01:38.635+0000 I CONTROL [initandlisten] modules: none
2018-12-03T09:01:38.635+0000 I CONTROL [initandlisten] build environment:
2018-12-03T09:01:38.635+0000 I CONTROL [initandlisten] distmod: ubuntu1604
2018-12-03T09:01:38.635+0000 I CONTROL [initandlisten] distarch: x86_64
2018-12-03T09:01:38.635+0000 I CONTROL [initandlisten] target_arch: x86_64
2018-12-03T09:01:38.635+0000 I CONTROL [initandlisten] options: { net: { bindIpAll: true } }
2018-12-03T09:01:38.668+0000 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=478M,session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),statistics_log=(wait=0),verbose=(recovery_progress),
2018-12-03T09:01:39.525+0000 E STORAGE [initandlisten] WiredTiger error (1) [1543827699:525626][1:0x7fb910fd8a40], connection: __posix_open_file, 715: /data/db/WiredTiger.wt: handle-open: open: Operation not permitted Raw: [1543827699:525626][1:0x7fb910fd8a40], connection: __posix_open_file, 715: /data/db/WiredTiger.wt: handle-open: open: Operation not permitted
2018-12-03T09:01:39.546+0000 E STORAGE [initandlisten] WiredTiger error (17) [1543827699:546502][1:0x7fb910fd8a40], connection: __posix_open_file, 715: /data/db/WiredTiger.wt:
handle-open: open: File exists Raw: [1543827699:546502][1:0x7fb910fd8a40], connection: __posix_open_file, 715: /data/db/WiredTiger.wt: handle-open: open: File exists
2018-12-03T09:01:39.551+0000 I STORAGE [initandlisten] WiredTiger message unexpected file WiredTiger.wt found, renamed to WiredTiger.wt.1
2018-12-03T09:01:39.553+0000 E STORAGE [initandlisten] WiredTiger error (1) [1543827699:553829][1:0x7fb910fd8a40], connection: __posix_open_file, 715: /data/db/WiredTiger.wt: handle-open: open: Operation not permitted Raw: [1543827699:553829][1:0x7fb910fd8a40], connection: __posix_open_file, 715: /data/db/WiredTiger.wt: handle-open: open: Operation not permitted
2018-12-03T09:01:39.571+0000 E STORAGE [initandlisten] WiredTiger error (17) [1543827699:571427][1:0x7fb910fd8a40], connection: __posix_open_file, 715: /data/db/WiredTiger.wt:
handle-open: open: File exists Raw: [1543827699:571427][1:0x7fb910fd8a40], connection: __posix_open_file, 715: /data/db/WiredTiger.wt: handle-open: open: File exists
2018-12-03T09:01:39.576+0000 I STORAGE [initandlisten] WiredTiger message unexpected file WiredTiger.wt found, renamed to WiredTiger.wt.2
2018-12-03T09:01:39.578+0000 E STORAGE [initandlisten] WiredTiger error (1) [1543827699:578575][1:0x7fb910fd8a40], connection: __posix_open_file, 715: /data/db/WiredTiger.wt: handle-open: open: Operation not permitted Raw: [1543827699:578575][1:0x7fb910fd8a40], connection: __posix_open_file, 715: /data/db/WiredTiger.wt: handle-open: open: Operation not permitted
2018-12-03T09:01:39.580+0000 W STORAGE [initandlisten] Failed to start up WiredTiger under any compatibility version.
2018-12-03T09:01:39.580+0000 F STORAGE [initandlisten] Reason: 1: Operation not permitted
2018-12-03T09:01:39.580+0000 F - [initandlisten] Fatal Assertion 28595 at src/mongo/db/storage/wiredtiger/wiredtiger_kv_engine.cpp 646
2018-12-03T09:01:39.580+0000 F - [initandlisten]
***aborting after fassert() failure
いろいろ見る
- Operation not permitted on NTFS volumes #243
- Volume mounts will not work on Windows #14
- Docker on Windows: Operation not permitted #107
- Windows 10, Docker and Mongo: Operation not permitted, terminating #190
- MongoDB on Windows Docker
- Docker + Windows + MongoDB -> std. Laradock fails. #1663
解決した人もいれば、しない人もいるようです。
同じような問題に直面してる人は多そうで、dockerとwindowsとmongoの組み合わせで起きてそうです。
特に↓のような文言もあったので、厳密にはHyper-V、NTFS、mongoDBあたりが相性悪いのかもしれない。
This issue seems to be related to NTFS filesystems.
結論として(tl;drの再掲)
-
docker for windowsでdocker-composeのvolumes使う場合、ディレクトリ表記はwindows(というよりNTFS？)に合わせよう！ - WSLでの
C:\は/mnt/c -
docker for windows+docker-compose+mongoは避けた方が無難なのかもしれない
疲れたのでここまで。