Homma's Slide 2015

Dockerのディスクについて ～ファイルシステム・マウント方法など～

ほんま

2015.09.17 2015.09.20

※各ページの参考資料を各ページ下にURLを記載しております。 詳細はそのリンクをご確認ください。もっと詳しい内容が記載されています。 主に、RedHat 中井さんのページを参考にさせていただいております。

Homma's Slide 2015

目的 • Dockerのディスクについて調査＆報告します。

– どのようなファイルシステムがあるのか

• ファイルシステムについて

• 特徴など

2

Homma's Slide 2015

Dockerのファイルシステム • Dockerのファイルシステムといえば、aufsです。

• というのはかなり古いです。

• 実際は、以下の種類が使用可能です。 – aufs

– btrfs

– devicemapper

– overlayfs

– zfs

※aufsは、Fedora、CentOSともにサポートしていません。

3

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

Homma's Slide 2015

DeviceMapperとは？ • Device Mapperは、metadataとdataの2つのディスクで構成されます。

• Thin-Provisioning機能があります。

5

metadata

data

実際のデータが 保存される

データがどこに 保存されているか

2つのディスクで1つのファイルシステムを 構成する

使用した分だけブロックに 分けられ追加されるので、 メタ情報からどこに保存 されているのかを追跡します。

#1 #3

#2

#1 #2 #3

論理デバイス

※使用しない領域は紐づけがない状態で ディスク容量を節約しています。

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のデフォルト はこちらです。

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

仮想ディスクサイズと、物理ディスクのサイズが違います。 必要な時に必要なサイズを用意します。ディスクが節約できますが、 利用時には、ディスクの割り当て作業が発生します。 つまり、時間がかかります。

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ディスク

スナップショット

※スナップショットの仕組みを使用して いるので、高速に用意できます。 ※実際にコピーしているわけではありません。

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

追加分が書き込みされる。

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 readme upperfile

上から見えるファイルが 実際のディスクになります。

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は無効かしておく必要があります。

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度読めば次はファイルキャッシュから再利用可能です。

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度読み込むことでファイルキャッシュが 行われ、次から起動するときにはこのキャッシュを利用することができるので 高速起動が可能になります。

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

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個作成し、 終了するまでに要する時間

Homma's Slide 2015

コンテナの生存

16

docker run

時間

コマンド プロセス コンテナ環境

（ネットワークなど） コンテナ イメージ

docker run で /bin/bashを実行した場合は、 ※「-rm」フラグを付けていない場合

コンテナ内で exitします

※プロセスは終了すると プロセスおよびコンテナは終了します

←終了してもイメージは 削除されません。

docker start ←コンテナを再スタートすると イメージは変更されずに コンテナ環境を設定し、プロセス が起動します。

docker stop ※docker stopコマンドでも同じに なります。

docker rm

※rmすることでイメージが削除されます。 削除しないとデータは残ったままです。

docker cpコマンドでホスト上に コピーすることが可能です。

Homma's Slide 2015

データを永続化させる方法 起動したコンテナ内部には、永続させたいデータがある場合があります。

たとえば、 – データベースのデータ

– 処理したログ

では、どうすれば、データの永続化ができるのでしょうか。

• データの永続化でしようするのは、「-v」or「--volume」のオプションです。

17

Homma's Slide 2015

「-v」オプションには2種類ある • 「-v」オプションには2種類あります。 ① -v （コンテナパス）:（読み書きモード）

② -v （ホストパス）:（コンテナパス）

• 意味合いとしては、以下のようになります。 ① データボリュームの作成 → 新たに作成する

② データボリュームのマウント → 既存をマウントする

18

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

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

Homma's Slide 2015

データを永続化する方法のまとめ

21

①データボリュームの作成 ：「-v （コンテナパス）:（読み書きモード）」

docker rm しても作成したデータボリュームは削除されないので、 /var/lib/docker/volumes/以下を探せば、データを見つけることができます。

docker rm するときに、「-v」のオプションを付けるとデータボリュームも一緒に 削除されます。

②データボリュームのマウント ：「-v （ホストパス）:（コンテナパス）」

docker run で指定したディレクトリは残ります。

指定するディレクトリは識別できる名前（例えばコンテナ名など）にしておくと 複数のコンテナを起動してもわからなくなることはありませんね。

③コンテナを削除する前にバックアップする/コミットする

docker cpでコンテナからデータを取り出すことができます。 docker commitで現在のイメージをリポジトリに保存することができます。 commitの方法は、おすすめしません。

Homma's Slide 2015

データの永続化のもう一つの方法 • データの永続化にはもう一つの方法があります。

データコンテナを利用する方法です。

①のデータボリュームを作成を利用する方法に近いです。

22

PostgreSQL コンテナ

データ コンテナ

PostgreSQL /pg/data マウント

/var/lib/docker/volume/03503bf0a60a9../_data/

ホスト上では マウント

※この方法では、 あまりホスト上のマウント先を 意識することがなく利用できます。 ユーザはデータコンテナに データが格納されていると 考えればよいです。

Homma's Slide 2015

データ コンテナ

データコンテナのメリット • 例として、PostgreSQLがバージョンを更新する場合を考えましょう。

• 右の方が運用上非常に良いのです。なぜでしょう？

23

PostgreSQL 9.4.0

PostgreSQL 9.4.2

データをミドルウェアと同じコンテナ に格納している場合

データ

データ

データをミドルウェアと別のコンテナ に格納している場合

PostgreSQL 9.4.0

データ

データ コンテナ

PostgreSQL 9.4.2

データ

Homma's Slide 2015

なぜ？ • 大量のPostgreSQLコンテナが動作している場合を考えましょう。

24

PostgreSQL9.4.0

PostgreSQL9.4.2

データ

データ

こちらの運用の場合は、すべてのPostgreSQLがインストール されたコンテナをyum updateをする必要があります。 ①それぞれのコンテナでディスク容量が必要になります。 ②それぞれでバージョン管理が必要です。

データコンテナPostgreSQL

9.4.0データ

データコンテナPostgreSQL

9.4.2データ

更新するのは、PostgreSQLのイメージだけです。 ①イメージを使った起動なのでディスク容量は、不要です。 （イメージとハードリンクしたりして節約される） ②PostgreSQLのバージョンが統一される （latestでコンテナを起動しなせば、すべて同じバージョン） →コンテナの起動は非常に速いので、コンテナらしい 運用方法です。

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マウント

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

バックアップ用のコンテナ実行例：

Homma's Slide 2015

まとめ • ファイルシステム

– いろんなファイルシステムが利用できますが、Dockerコンテナでは大

量のコンテナの起動を想定してファイルシステムの向上が行われています。

– →起動速度が向上するファイルフォーマットに変わりつつあります。

– →また、大量にコンテナを起動した場合でもディスク容量を節約できるようにもなっています。

• データの永続性 – 「-v」オプションをうまく利用してデータの永続化を図ります。

– 「-ｖ」の利用法は、想定するシステムやコンテナによって使い分けましょう。

27