dockerでDBを使っているとデータを永続化させるためにローカルの特定のディレクトリなどをマウントさせる事が多い。運用しているdocker-composeを次のような感じで書いていた。
image: mongo:3.6
restart: unless-stopped
volumes:
- mongo_configdb:/data/configdb
- mongo_db:/data/db
restart: always
volumes:
mongo_db:
まぁこれで全然問題なかったのだけど、volumesで特にパスを指定していなかった。
そのため /var/lib/docker/volumes以下に動かしているコンテナ名でディレクトリが作成されていて、そのディレクトリがmountされている感じで動いていた。
/var/lib/docker以下に保存していると、なにかdocker pruneとかしてしまうとファイルが消えてしまう可能性があるらしい。それは避けたいのでローカルディレクトリ上に保存しようとした。
ファイルの移動
どうも調べていると一度volumeとimageを消さないと移動はできないらしい。
mvで移動しても良かったが、最初にbackupがてらcpでディレクトリごとコピーした。
今思い返せばcpじゃなくてrsync使ってたほうが良かったのかもしれない。
$cp -r /var/lib/docker/volumes /home/anatofuz/backup
この時点で/var/lib/docker/volumesを ls -lしたら全てroot:rootになっていたので油断していた。
ホームディレクトリに移したのでanatofuz:dockerくらいにchownしていた。
docker-composeへの追記
docker-composeにカレントディレクトリ以下にデータを保存させたかったので次の様な感じで追記をした。
volumes:
growi_data:
driver_opts:
type: none
device: /home/anatofuz/growi/data/growi_growi_data
o: bind
mongo_configdb:
driver_opts:
type: none
device: /home/anatofuz/growi/data/growi_mongo_configdb
o: bind
mongo_db:
driver_opts:
type: none
device: /home/anatofuz/growi/data/growi_mongo_db
o: bind
es_data:
driver_opts:
type: none
device: /home/anatofuz/growi/data/growi_es_data
o: bind
docer-compose stopしてdocker-compose rmしたあとにdocer-compose buildしようとしたら所、 volumeを消せと言われたのでポチポチvolumeを消していった。
ビルド時のpermission
ビルドするとこんな感じになる
Successfully built e3a815260e49
Successfully tagged growi_elasticsearch:latest
Building app
Traceback (most recent call last):
File "bin/docker-compose", line 6, in <module>
File "compose/cli/main.py", line 72, in main
File "compose/cli/main.py", line 128, in perform_command
File "compose/cli/main.py", line 304, in build
File "compose/project.py", line 397, in build
File "compose/project.py", line 380, in build_service
File "compose/service.py", line 1104, in build
File "site-packages/docker/api/build.py", line 160, in build
File "site-packages/docker/utils/build.py", line 30, in tar
File "site-packages/docker/utils/build.py", line 49, in exclude_paths
File "site-packages/docker/utils/build.py", line 214, in rec_walk
File "site-packages/docker/utils/build.py", line 214, in rec_walk
File "site-packages/docker/utils/build.py", line 214, in rec_walk
File "site-packages/docker/utils/build.py", line 184, in rec_walk
PermissionError: [Errno 13] Permission denied: '/home/anatofuz/growi/data/growi_mariadb_data/mysql'
[395570] Failed to execute script docker-compose
そもそもappは次の様にdocker-compose.ymlを書いている。
app:
build:
context: .
dockerfile: ./Dockerfile
ports:
- 3000:3000
links:
- mongo:mongo
- elasticsearch:elasticsearch
depends_on:
- mongo
- elasticsearch
environment:
- MONGO_URI=mongodb://mongo:27017/growi
- ELASTICSEARCH_URI=http://elasticsearch:9200/growi
- FILE_UPLOAD=local
- MATHJAX=1
command: "dockerize
-wait tcp://mongo:27017
-wait tcp://elasticsearch:9200
-timeout 60s
npm run server:prod"
restart: unless-stopped
volumes:
- growi_data:/data
restart: always
mariadbのdataにアクセスする必要は無いと思うのだけれど、なぜかこのパーミッションで怒られている。dataディレクトリの中でコンテナごとにディレクトリを切っていたけれど、この運用が駄目だったのかもしれない。
root:rootなのが怪しいのかと思いchownで変更した。
sudo chown -R anatofuz:docker data/
こうするとbuildは通った。
起動するとDBの中身を読んでくれない問題
build通ったので喜びながらdocker-compose upしたがアプリケーションの初期設定画面が表示されてしまっていた。DBがデータを読んでなさそうな気配はあったが、docker-composeのlogを見る限りPermission関連で怒られている気配はない。
色々見た結果、もともと/var/lib/docker/volumesの中にあったgrowi_growi_dataの様なコンテナ名のディレクトリをプロジェクトのdataディレクトリにコピっていた。このコピー先の/home/anatofuz/growi/data/growi_growi_dataをdocker-composeでvolumeとして指定していたのだけど、これが駄目だった。
実際には/home/anatofuz/growi/data/growi_growi_dataの中に_dataディレクトリがあり、このディレクトリの中に実際のデータが存在している。つまりこの_dataまで指定しなければならない。
今回はdocker-composeを操作せずに、各コンテナ名ディレクトリの_dataをmv ..して解決した。正直この解決方法が正しいかは微妙である。
とはいえ
もう一度docer-compose buildすると、相変わらず
PermissionError: [Errno 13] Permission denied: '/home/anatofuz/growi/data/growi_mariadb_data/mysql'
[395570] Failed to execute script docker-compose
と怒られてしまう。
$ ls -l data/
total 56
drwxr-xr-x 3 anatofuz docker 4096 Jun 4 23:18 growi_es_data
drwxr-xr-x 3 anatofuz docker 4096 Jun 4 23:18 growi_growi_data
drwxr-xr-x 4 anatofuz docker 4096 Jun 4 23:18 growi_https-portal_data
drwxr-xr-x 5 999 docker 4096 Jun 4 23:23 growi_mariadb_data
drwxr-xr-x 2 999 docker 4096 Apr 30 02:20 growi_mongo_configdb
drwxr-xr-x 4 999 docker 4096 Jun 5 08:53 growi_mongo_db
-rw------- 1 anatofuz docker 65536 Jun 4 23:18 metadata.db
どうもdocker-compose runした瞬間にmariadbなどのDB系のユーザーが999で実行されてしまい、anatofuzで起動しているgrowi(app)からは参照できないらしい。
実際にps auxするとmariadbが999ユーザーで実行されていた。/var/lib/docker/volumesで実行していたときは999ではなくrootで動いていた気がするので、なぜこうなったかはよく解っていない。
所感
/var/lib/docker/volumesに結局データが保存されるのであれば、別にわざわざ違うディレクトリをマウントしようと頑張る必要はなかったのかもしれない。少なくともdocker-compose buildがスムーズに行かなくなってしまった。
dockerのvolumeを適当なディレクトリに保存して永続化させるよりは、mongodbやmysqlなどのコンテナにattachするなりしてバックアップを取っていくほうが無難であるかなという気がした。今の環境を元に戻すかは怪しいところ。戻せたら良いんだけど…
全体的にdockerよく解っていないことが露呈しているので、なぜこうなったか検討がつく方がいれば教えていただけると嬉しいです
追記 (2020/06/08)
'/home/anatofuz/growi/data/以下においていた999ユーザーで実行されてしまうDB系のファイル群を
'/home/anatofuz/db/dataの様なトップディレクトリが異なるディレクトリ内に移動させてvolumeを作り直したところ、docker-compose build時のパーミッション問題は出なくなった。
おそらくappのビルド時にカレントディレクトリをマウントしていて、カレントディレクトリ以下のファイルのパーミッションは全て確認する挙動のような気がする。
id:papixさんや、 的確な指摘で文章のリファクタリングをしていただいた技術評論社の稲尾さん、 英語や技術的内容のレビューをしていただいた監修の牧さんを始めとする校正などに関わってくださった皆さんに御礼申し上げます。
の様にあまり画質が良くない(サイズが小さい)
とそこそこ高画質化される