10年振りに新サーバを買ったので、自宅環境の設計を検討する。chefに代表される構成管理ツールの充実でゼロからの再構築が容易になった。その一方で物理サーバやKVM等の仮想サーバだと再構築の検証が重い。それ以外にも個人用途の貧弱なサーバの場合、KVMによるリソースの分断は管理的に面倒だったり、ノード数の制限が付きまとってしまう。

そこで今回はKVMに代わる仮想化を検討していきたい。まずはdockerから触ってみたが、結果から言うと今はまだ使えないと判断した。全ての面で否定する訳ではないが、シンプル且つ統一的に構造化されたインフラ基盤として使っていくにはまだ成熟度が足りないという判断だ。良い面も幾つもあるが、気になる点は以下のものだった。

• プロセス1つのみフォアグラウンドで動かすという原則

もちろんプロセス2つ以上で動かす方法はいくらでもあるが、dockerの考え方を尊重した使い方をする場合、smbとnmbのようなプロセスをどう扱うのか結論が出せない。

• IPアドレスを固定する方法がない

これも未成熟なツールを使うか、host networkingを使うか、lxcコンテナを利用するかで何とかならないでもないが、どれもそうまでしてdockerにこだわらなければいけないのか、という考えに至る。特にlxcコンテナ使ったりすると、もうlxcでいいだろという気分になる。

• ログ収集(もしくは標準出力へのメッセージ送信)が面倒

ログ系を標準出力に出すのに、ミドルウェアによってはあえてdebugモードにしなければいけなかったり、出力が出ないときのdebugが面倒だったり、普通に使うのって楽なんだなっていう気分に。。。

• Dockerfileの表現力が低い

mysqlのようにmasterとslaveで少しだけ設定を変えるような処理をやりづらい。共通設定とそれ以外の部分を別ファイル化してincludeするファイルを切り替えたりすればできるのだが、これもdockerを使うために設定ファイルの管理を無理矢理合わせてる格好になってしまう。

という訳で、現時点ではシンプルにlxcそのものとchefで構成管理していくのが、特に我が家のようなプアな環境においては効率的だと考えた。自宅環境はともかくvpsなどの場合、用途ごとにコンポーネントを分けようとすると、kvm中に更にkvmを作るという不合理な構造になってしまうのだが、lxcであればそういう意味においてもkvmとはるかに相性がいいと言える。

kvm + chefで開発していた頃は構成管理で寧ろ運用効率落ちたのではないか(検証が重くて)と思うこともあったが、軽快なlxcとの出会いは再びchefの開発熱を呼び覚ますほどだった。