Dockerのファイルシステムやマウント方法について記載しています。 またデータボリュームのマウントについて記載し、データの永続化についても記載しています。

1. Homma's Slide 2015
Dockerのディスクについて
～ファイルシステム・マウント方法など～
ほんま
2015.09.17
2015.09.20
※各ページの参考資料を各ページ下にURLを記載しております。
詳細はそのリンクをご確認ください。もっと詳しい内容が記載されています。
主に、RedHat 中井さんのページを参考にさせていただいております。

2. Homma's Slide 2015
目的
• Dockerのディスクについて調査＆報告します。
– どのようなファイルシステムがあるのか
• ファイルシステムについて
• 特徴など
2

3. Homma's Slide 2015
Dockerのファイルシステム
• Dockerのファイルシステムといえば、aufsです。
• というのはかなり古いです。
• 実際は、以下の種類が使用可能です。
– aufs
– btrfs
– devicemapper
– overlayfs
– zfs
※aufsは、Fedora、CentOSともにサポートしていません。
3

4. Homma's Slide 2015
デフォルトファイルシステムは？
• デフォルトのファイルシステムとは？
aufsはすでにほとんど使われていません。
理由としては、Linuxカーネルに標準に含まれていないためです。
Linuxカーネルで利用可能にしたのは、devicemapperです。
4
Docker = AUFSという図式はもう忘れたほうがいいかもしれない、あるいはDockerとストレージドライバ
の話 http://qiita.com/DQNEO/items/ee0caf80b056487cb762
Linux Distribution Storage Driver
CentOS 7 devicemapper
Ubuntu 14.04 devicemapper
CoreOS overlayfs
OSX (boot2docker) aufs

5. Homma's Slide 2015
DeviceMapperとは？
• Device Mapperは、metadataとdataの2つのディスクで構成さ
れます。
• Thin-Provisioning機能があります。
5
metadata
data
実際のデータが
保存される
データがどこに
保存されているか
2つのディスクで1つのファイルシステムを
構成する
使用した分だけブロックに
分けられ追加されるので、
メタ情報からどこに保存
されているのかを追跡します。
#1
#3
#2
#1 #2 #3
論理デバイス
※使用しない領域は紐づけがない状態で
ディスク容量を節約しています。

6. Homma's Slide 2015
DeviceMapperとLVMとは
• DeviceMapperはLVMを利用します。
– Direct LVM
– Loopback LVM
と、2つに分けることができます。
• マウントの方法が違います。
6
Loopback LVM direct LVM
OS上のディスク
data
meta
data
mount = /
ディスク上のファ
イルをループバッ
クデバイスとして
LVMでマウントしま
す。
OSディスク
device mapper用
ディスク（VG） 別のディスクや
残りのディスク
スペースを使って
ボリュームグルー
プ（VG）を作成しま
す。
meta
data data
※VGをdata、metadataの2つのLVを作成します。
OpenStackで
CinderをLVMで利用した
場合と同じです。
Dockerのデフォルト
はこちらです。

7. Homma's Slide 2015
Loopback LVMのメリット・デメリット
• ループバックデバイスとしてファイルを利用していますが、こ
のファイルはrawイメージ（パース）となります。
7
# qemu-img info /var/lib/docker/devicemapper/devicemapper/data
image: /var/lib/docker/devicemapper/devicemapper/data
file format: raw
virtual size: 100G (107374182400 bytes)
disk size: 292M
# qemu-img info
/var/lib/docker/devicemapper/devicemapper/metadata
image: /var/lib/docker/devicemapper/devicemapper/metadata
file format: raw
virtual size: 2.0G (2147483648 bytes)
disk size: 744K
仮想ディスクサイズと、物理ディスクのサイズが違います。
必要な時に必要なサイズを用意します。ディスクが節約できますが、
利用時には、ディスクの割り当て作業が発生します。
つまり、時間がかかります。

8. Homma's Slide 2015
DeviceMapperの仕組み
8
① Dockerサービス初回起動時
10Gディスク
LVMのdata上に10Gのディスクを作成します。
サイズを変更するには、Dockerサービスを起動する
前に、「--storage-opt dm.basesize=50G」を指定する
必要があります。
② Dockerイメージをダウンロードする
Dockerイメージ管理の内部構造
http://www.slideshare.net/enakai/docker-43975886/13
10Gディスク
docker
イメージ
最初に作成したディスクからスナップショット
を作成し、ダウンロードしたdockerイメージを
解凍＆展開します。
※初回起動時にはこのようなコマンドが実行されています。
mkfs.ext4 -E nodiscard,lazy_itable_init=0,lazy_journal_init=0
10Gディスク
スナップショット
※スナップショットの仕組みを使用して
いるので、高速に用意できます。
※実際にコピーしているわけではありません。

9. Homma's Slide 2015
DeviceMapperのスナップショットとは
• 高速にスナップショット（複製）ができます。
9
data領域
#1 #2
#1 #2
論理デバイス
Dockerイメージ管理の内部構造
http://www.slideshare.net/enakai/docker-43975886/18
スナップショット
（複製）
#1 #2
論理デバイス
※データをコピーするのではなく、参照先リストを作成するというイメージです。
※同じデータは複製されないので、ディスクの節約にもつながります。
→ これはDockerイメージがレイヤー構成をとっていることで
このような仕組みになっています。
書き込みすると
#1 #2
論理デバイス
#3
#3
追加分が書き込みされる。

10. Homma's Slide 2015
OverlayFSとは？
• OverlayFSとは
– lowerdir：基盤となるディレクトリ
– upperdir：基盤状に重ねるディレクトリ
で構成され、以下のようなイメージです。
10
lowdir:
updir:
/etc /usr /bin /dev
/dev
hostname
hostname
readme
upperfile
実際に見える
ディスク:
/etc /usr /bin /dev hostname readmeupperfile
上から見えるファイルが
実際のディスクになります。

11. Homma's Slide 2015
overlayfsを使ったコンテナ
11
lowerdir=/var/lib/docker/overlay/7322fbe74aa5632b33a400959867c8ac4290e9c5112877a7754be70cfe5d66e9/root
upperdir=/var/lib/docker/overlay/89803bc3844b59b8a5c1c437a2e1ff90f07b35baee14aa46f328ae1441eebe71/upper
workdir=/var/lib/docker/overlay/89803bc3844b59b8a5c1c437a2e1ff90f07b35baee14aa46f328ae1441eebe71/work
dockerのマウント情報を見ると、このようにマウントしています。
/var/lib/docker/overlay/以下にイメージがあります。
ディレクトリ イメージ内容
lowerdir コンテナ起動時に利用したイメージです
322fbe74aa5632b33a40095…のIDは、CentOSのイメージIDです
upperdir コンテナように割り当てられた上書き用のディスクです
89803bc3844b59b8a5c1c43…は起動したコンテナIDです
起動時にはコンテナ固有の設定が保存されています。
/etc/hosts
/etc/resolv.conf
※SELinuxが対応していないので、SELinuxは無効かしておく必要があります。

12. Homma's Slide 2015
overlayfsの速度向上の仕組み①
• overlayfsは、Linuxのファイルキャッシュを利用し、ファイルの
読み込み速度の高速化を図っています。
12
# docker history 0f73ae75014f
IMAGE CREATED CREATED BY SIZE
0f73ae75014f 11 days ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0 B
f37e6a610a37 11 days ago /bin/sh -c #(nop) LABEL License=GPLv2 0 B
f9a8cbc8dd13 11 days ago /bin/sh -c #(nop) LABEL Vendor=CentOS 0 B
f6f39725d938 11 days ago /bin/sh -c #(nop) ADD file:2c002b8a427ce98fc1 172.3 MB
47d44cb6f252 11 days ago /bin/sh -c #(nop) MAINTAINER The CentOS Proje 0 B
例えば、CentOSのイメージを更新履歴を見たものです。
それぞれのイメージの/bin/bashを見ています。
# ls -ali overlay/f6f39725d938../root/bin/bash
134607633 -rwxr-xr-x. 4 root root 960384 3月 6 2015 overlay/f6f39725d938../root/bin/bash
# ls -ali overlay/f37e6a610a37../root/bin/bash
134607633 -rwxr-xr-x. 4 root root 960384 3月 6 2015 overlay/f37e6a610a37../root/bin/bash
# ls -ali overlay/0f73ae75014f../root/bin/bash
134607633 -rwxr-xr-x. 4 root root 960384 3月 6 2015 overlay/0f73ae75014f../root/bin/bash
先頭の番号（i-node番号)が同じです。ファイルをハードリンクしています。
実体は同じなので、 1度読めば次はファイルキャッシュから再利用可能です。

13. Homma's Slide 2015
overlayfsの速度向上の仕組み②
• もちろん、コンテナ内部もi-node番号が同じになります。
13
[root@00b9ae2f38ba /]# ls -ali /bin/bash
134607633 -rwxr-xr-x. 4 root root 960384 Mar 5 2015 /bin/bash
# ls -ali overlay/f6f39725d938../root/bin/bash
134607633 -rwxr-xr-x. 4 root root 960384 3月 6 2015 overlay/f6f39725d938../root/bin/bash
# ls -ali overlay/f37e6a610a37../root/bin/bash
134607633 -rwxr-xr-x. 4 root root 960384 3月 6 2015 overlay/f37e6a610a37../root/bin/bash
# ls -ali overlay/0f73ae75014f../root/bin/bash
134607633 -rwxr-xr-x. 4 root root 960384 3月 6 2015 overlay/0f73ae75014f../root/bin/bash
コンテナ内でlsした結果です。
ホスト上のイメージごとのlsした結果です
すべてi-nodeが同じですよね。
コンテナを同時・大量に起動する場合、1度読み込むことでファイルキャッシュが
行われ、次から起動するときにはこのキャッシュを利用することができるので
高速起動が可能になります。

14. Homma's Slide 2015
overlayfsでのディスク使用制限
• overlayfsで/（ルート）がマウントされています。サイズはホスト上
のディスクサイズと同じです。
• DeviceMapperを利用する場合は/（ルート）は、デフォルトでは
10G（初回のみ設定変更可能）で、ホストとは共有していません。
• overlayfsの場合は制限がないので、運用上注意が必要です。
（/var/lib/docker/overlay/を別ディスクにするなど）
14
# df -h
Filesystem Size Used Avail Use% Mounted on
overlay 50G 1.9G 49G 4% /
tmpfs 2.0G 0 2.0G 0% /dev
shm 64M 0 64M 0% /dev/shm
tmpfs 2.0G 0 2.0G 0% /run/secrets
/dev/mapper/centos-root 50G 1.9G 49G 4% /etc/hosts
tmpfs 2.0G 0 2.0G 0% /proc/kcore
tmpfs 2.0G 0 2.0G 0% /proc/timer_stats

15. Homma's Slide 2015
ファイルシステムの性能
• ファイルシステムの性能は以下のようになっています。
15
Comprehensive Overview of Storage Scalability in Docker
http://developerblog.redhat.com/2014/09/30/overview-storage-scalability-docker/
overlayfsが一番性能がよく、
directLVMが次の性能がよい。
コンテナを1000個作成し、
終了するまでに要する時間

16. Homma's Slide 2015
コンテナの生存
16
docker run
時間
コマンド プロセス
コンテナ環境
（ネットワークなど）
コンテナ
イメージ
docker run で /bin/bashを実行した場合は、 ※「-rm」フラグを付けていない場合
コンテナ内で
exitします
※プロセスは終了すると
プロセスおよびコンテナは終了します
←終了してもイメージは
削除されません。
docker start ←コンテナを再スタートすると
イメージは変更されずに
コンテナ環境を設定し、プロセス
が起動します。
docker stop
※docker stopコマンドでも同じに
なります。
docker rm
※rmすることでイメージが削除されます。
削除しないとデータは残ったままです。
docker cpコマンドでホスト上に
コピーすることが可能です。

17. Homma's Slide 2015
データを永続化させる方法
起動したコンテナ内部には、永続させたいデータがある場合が
あります。
たとえば、
– データベースのデータ
– 処理したログ
では、どうすれば、データの永続化ができるのでしょうか。
• データの永続化でしようするのは、「-v」or「--volume」のオプ
ションです。
17

18. Homma's Slide 2015
「-v」オプションには2種類ある
• 「-v」オプションには2種類あります。
① -v （コンテナパス）:（読み書きモード）
② -v （ホストパス）:（コンテナパス）
• 意味合いとしては、以下のようになります。
① データボリュームの作成 → 新たに作成する
② データボリュームのマウント → 既存をマウントする
18

19. Homma's Slide 2015
「-v」の違い：①データボリュームの作成
19
①データボリュームの作成 ：「-v （コンテナパス）:（読み書きモード）」
/mountvol2
/mountvol1
コンテナのディスク ホストのディスク
/var/lib/docker/volume/03503bf0a60a9../_data/
/var/lib/docker/volume/1cffcc92c78762../_data/
マウント
指定したディレクトリと紐づくのは、/var/lib/docker/volume/以下のディレクトリ
になります。
volume以下のIDは、volume用に作られたIDで、コンテナIDとは一致しません。
# docker inspect test01
(略)
"Volumes": {
"/mountvol1": "/var/lib/docker/volumes/03503bf0a60a97f01…/_data",
"/mountvol2": "/var/lib/docker/volumes/1cffcc92c787626a5…/_data"
},
(略)
マウント情報を
管理しています
# docker run -it --name test01 -v /mountvol1 -v /mountvol2 centos /bin/bash

20. Homma's Slide 2015
「-v」の違い：②データボリュームのマウント
20
②データボリュームのマウント ：「-v （ホストパス）:（コンテナパス）」
/log
/work
コンテナのディスク ホストのディスク
/docker/mnt/test02/work/
/docker/mnt/test02/log
マウント
docker run で指定した引数でマウントされます。
既存のディレクトリをデータとして、コンテナに渡すこともできますし、出力結果
を指定したディレクトリに保存することができます。
# docker inspect test02
(略)
"Volumes": {
"/log": "/docker/mnt/test02/log",
"/work": "/docker/mnt/test02/work“
},
(略)
マウント情報を
管理しています
# docker run -it --name test02 -v /docker/mnt/test02/work/:/work
-v /docker/mnt/test02/log:/log centos /bin/bash

21. Homma's Slide 2015
データを永続化する方法のまとめ
21
①データボリュームの作成 ：「-v （コンテナパス）:（読み書きモード）」
docker rm しても作成したデータボリュームは削除されないので、
/var/lib/docker/volumes/以下を探せば、データを見つけることができます。
docker rm するときに、「-v」のオプションを付けるとデータボリュームも一緒に
削除されます。
②データボリュームのマウント ：「-v （ホストパス）:（コンテナパス）」
docker run で指定したディレクトリは残ります。
指定するディレクトリは識別できる名前（例えばコンテナ名など）にしておくと
複数のコンテナを起動してもわからなくなることはありませんね。
③コンテナを削除する前にバックアップする/コミットする
docker cpでコンテナからデータを取り出すことができます。
docker commitで現在のイメージをリポジトリに保存することができます。
commitの方法は、おすすめしません。

22. Homma's Slide 2015
データの永続化のもう一つの方法
• データの永続化にはもう一つの方法があります。
データコンテナを利用する方法です。
①のデータボリュームを作成を利用する方法に近いです。
22
PostgreSQL
コンテナ
データ
コンテナ
PostgreSQL/pg/data
マウント
/var/lib/docker/volume/03503bf0a60a9../_data/
ホスト上では
マウント
※この方法では、
あまりホスト上のマウント先を
意識することがなく利用できます。
ユーザはデータコンテナに
データが格納されていると
考えればよいです。

23. Homma's Slide 2015
データ
コンテナ
データコンテナのメリット
• 例として、PostgreSQLがバージョンを更新する場合を考えま
しょう。
• 右の方が運用上非常に良いのです。なぜでしょう？
23
PostgreSQL
9.4.0
PostgreSQL
9.4.2
データをミドルウェアと同じコンテナ
に格納している場合
データ
データ
データをミドルウェアと別のコンテナ
に格納している場合
PostgreSQL
9.4.0
データ
データ
コンテナPostgreSQL
9.4.2
データ

24. Homma's Slide 2015
なぜ？
• 大量のPostgreSQLコンテナが動作している場合を考えましょう。
24
PostgreSQL
9.4.0
PostgreSQL
9.4.2
データ
データ
こちらの運用の場合は、すべてのPostgreSQLがインストール
されたコンテナをyum updateをする必要があります。
①それぞれのコンテナでディスク容量が必要になります。
②それぞれでバージョン管理が必要です。
データ
コンテナPostgreSQL
9.4.0
データ
データ
コンテナPostgreSQL
9.4.2
データ
更新するのは、PostgreSQLのイメージだけです。
①イメージを使った起動なのでディスク容量は、不要です。
（イメージとハードリンクしたりして節約される）
②PostgreSQLのバージョンが統一される
（latestでコンテナを起動しなせば、すべて同じバージョン）
→コンテナの起動は非常に速いので、コンテナらしい
運用方法です。

25. Homma's Slide 2015
データコンテナのマウント方法
25
# docker run -v –d /dbdata --name dbdata busybox /bin/sh
https://docs.docker.com/userguide/dockervolumes/
①データコンテナの起動
※データコンテナと処理コンテナが同じディストリビューション・バージョンで
ある必要はないので、軽量なコンテナ（busybox）を利用します。
②処理コンテナの起動
# docker run -d --volumes-from dbdata --name db1 training/postgres
「--volumes-from」でコンテナを指定することで、指定したコンテナの
データボリュームをマウントすることができます。
PostgreSQL
コンテナ
データ
コンテナ
PostgreSQL/pg/data
マウント

26. Homma's Slide 2015
データコンテナの注意点
• データコンテナにマウントされたデータボリュームはコンテナ
の管理外になります。
• つまり、docker commitコマンドでコンテナを保存した場合、
データボリュームは保存されません。
• したがって、データコンテナのデータをバックアップする場合
は、docker execコマンドやdocker runで新しいバックアップが
実行されるコンテナの起動などを行います。
26
#docker run --volumes-from dbdata2 -v $(pwd):/backup ubuntu cd /dbdata && tar xvf /backup/backup.tar
バックアップ用のコンテナ実行例：

27. Homma's Slide 2015
まとめ
• ファイルシステム
– いろんなファイルシステムが利用できますが、Dockerコンテナでは大
量のコンテナの起動を想定してファイルシステムの向上が行われて
います。
– →起動速度が向上するファイルフォーマットに変わりつつあります。
– →また、大量にコンテナを起動した場合でもディスク容量を節約でき
るようにもなっています。
• データの永続性
– 「-v」オプションをうまく利用してデータの永続化を図ります。
– 「-ｖ」の利用法は、想定するシステムやコンテナによって使い分けま
しょう。
27