2017年06月02日

実際に触ってためしてみるDataVolumeContainer

dockerを運用に回そうと頑張っています。
今はresilio syncのファイルをどっか永続的な場所に保存しようとしているんだけれども
dockerではファイルの永続化はDataVolumeContainterというコンテナで一括管理がかっこいいという話をきいたので
ほーん、どういうもんだろ、という気持ちで手を動かしながら確認してみた。



DataVolumeContainer is 何

そもそも何でDataVolumeContainerに永続データを一括管理するのがかっこいいのか。
Dockerの各コンテナのファイルは、そもそもvolumeという機能でホスト側のファイルシステムをマウントして利用することができる。
すなわち

  • redmine : /var/share/docker/redmine配下を利用
  • postgresql : /var/share/docker/postgres配下を利用
  • resilio sync : /var/share/docker/sync配下を利用

みたいにコンテナひとつひとつにちゃんとマウントポイントを指定できるんなら、何も問題ない。
でもこういうフォルダ構成っていろんな設定ファイルに散らばると面倒くさいよね?
という問題を解決するため、redmineもpostgresqlもresilioも単に --volumes-from data_container だけ書いておいて
data_containerさんが一括でマウントポイントの面倒をみてやろう、というのが
DataVolumeContainerの役割なのだ

使ってみる

なるほどわかりました。で、実際どんな動きをするの?っていうのを↓のサイト様を参考にやってみた。


DataVolumeContainerに利用するイメージはなんでもいい。ていうか起動してる必要すらないんで軽ければ軽いほどいい
そういう場合に役立つイメージがbusybox。シェルやらコマンドやらを単一のファイルにまとめた特殊な環境を持つイメージで本来は組み込みLinux向け。
これを何もしないコンテナのイメージに利用するというのがDataVolumeContainerの定石ぽい

で、DataVolumeContainer側にbusybox、利用する側にcentos使って利用してみると、おー、/data/test.txtに書き込めた、読み込めた。
※詳細は上のリンク先参照…手抜きですまぬ。

このファイル、実体は俺の環境では/var/lib/docker/volumes/89e6797de5df417b9642f8f117a26835d0b5490666bd273ec3b40838e5fabf27というとんでもない場所に格納されているらしい。何事
名前から見て分かる通り、ホスト側から直接利用することは全く想定しておらず、
例えばバックアップしたければ他のコンテナ経由でファイルを取りに行くらしい。

これがベストプラクティスなのか。

実際どう?

さて、実際に使ってみてどうか。運用に回せるのか

んー。

-vで直接ホストのファイルシステムをマウントしたほうがマシくね?(ひどい結論)

冒頭でも語ったとおり、DataVolumeContainerの利点はマウントポイントがいろんな設定情報に散らかってしまうのを防ぐこと
欠点は/var/lib/docker/volumes配下のわけわからん名前のフォルダに永続化されてしまうので直接見に行けないこと

まあ、ホストの環境との依存関係がうすくなるのはいかにもかっこよくていいんだけど
それより格納先のファイルがわかりやすい方が好みだわー。

あと、どうせdocker-compose.ymlで複数のコンテナを一括管理するんだよね?
設定情報はそこに一元管理されるんだから問題なくね
まだ俺の理解度がたりなくてDataVolumeContainerの有用性に気づいてないのかな?

まあDockerのいいところは何度でも作り直せる部分にあるんで、ひとまずはファイルシステムを直接マウントしまくる方式でやるか。

タグ:Docker
posted by LoyalTouch at 06:25| Comment(0) | TrackBack(0) | インフラ | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

この記事へのトラックバックURL
http://blog.seesaa.jp/tb/450444070

この記事へのトラックバック