dockerの永続領域はホストかData Volume Containerか・・・

ちょっとdockerの使い方で、「Data Volume Container」ってのを見つけたので、考えてみた話。まだ構成は変えていない。

今このブログサーバーは、mysql等のデータフォルダはすべて、host側に用意されたコンテナ用フォルダをvolumeとしてマウントしています。つまり、DBやログ等のファイルについては、docker内ではなく、普通のファイルシステムに書きだされている状態。

dockerの外に出した理由は、イメージの肥大化を嫌ったためです。

他方、Data Volume Containerというものがあります。別のdockerコンテナにボリュームだけを提供するコンテナ。こうすることで、データ領域とコード領域のコンテナを分割出来るメリットがあります。管理上のメリットとして、「ホスト側にファイルを晒さないで済む」という点があります。つまり、dockerの世界に閉じる、と。

ただ、これ、docker内だとやっぱりイメージ肥大化して、運用性落ちる（性能も落ちる）気がしてならないんですが・・・。あと、コンテナ増えすぎないか？という懸念もあります。

そして、ここに、実は以前から気になっている設定がありました。Cent OSにdockerを入れると、/etc/sysconfig/docker-storageにこんな記述があります。

# By default, Docker uses a loopback-mounted sparse file in
# /var/lib/docker.  The loopback makes it slower, and there are some
# restrictive defaults, such as 100GB max storage.

# If your installation did not set a custom storage for Docker, you
# may do it below.

# Example: Use a custom pair of raw logical volumes (one for metadata,
# one for data).
# DOCKER_STORAGE_OPTIONS = --storage-opt dm.metadatadev=/dev/mylogvol/my-docker-metadata --storage-opt dm.datadev=/dev/mylogvol/my-docker-data

そのまま読むと、（そのままでも無いけど）デフォルトのsparse fileは遅いから、カスタムストレージ使うと良いらしい、と。なんだ、LVM使えるんじゃん、というのが率直な感想。

なるほど、dockerはこのStorage Driverが肝らしい。というわけで、調べてみた。

Cent OS 6のdocker infoを見ると、所謂sparse fileベースのドライバになっています。

Storage Driver: devicemapper
 Pool Name: docker-253:2-852770-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
...

じゃあCoreOSはどうなんだろう、と思ったら、overlayfs。これがやっぱり速いらしい。

Storage Driver: overlay
Backing Filesystem: extfs

つまり、dockerをdockerらしく使うには、Core OS等、overlayfsが使える環境で、Data Volume Container構造でデータを保持するのが、一番カッコイイらしいですな。

さすがにVPSのホストをCentOSからCoreOSに変えるのはちょっとコスト高いかなぁと思いつつ、dockerの性能の勘所がちょっと見えた気がしました。まだ何も変えてませんがね。