「まっさらなサーバを30分で本番投入できるようにする」に、たくさんのブックマークを頂きました。その中のコメントで「OSインストール、ある程度の設定がされたdisk imageをあらかじめ作っておいて、そのdisk imageをddした方が早いと思う」というものがありました。確かに速度を最速化することを考えると、確かにDisk imageをddする、というのは、かなり有力な手段です。なぜはてなではそうしていないか、を書いてみました。
- ネットワーク経由でできない。できるようにするには、前準備が必要。
- ddを利用する場合、単純に使うと、dd if=/dev/hda1 of=/dev/hdb1のようになり、HDDの差し替えをしないといけません。もちろん、ちょっと頑張れば、ネットワーク経由でddできるようになりますが、その場合、コピー先にOSをインストールしておかないといけないと思います。
- 用途ごとに微調整が必要
- プロキシーとバックエンドの構成は違うし、DBの構成もまた違います。さらにアプリケーションごとに多少の差異があり、それぞれにディスクイメージを用意するのは、大変です。
- ディスクサイズがけっこう違う
- そもそもディスクサイズが時々違ったりするので、ddでは、一番小さいのに合せないといけない気がします。
- OSも実は混在している
- 実は、Cent4系とCent5系の両方が存在するので、それぞれのためにまたディスクイメージを作るのは大変です。
- 環境の再現が困難
- ディスクイメージで持っていると、環境のコピーをするのは簡単ですが、同じ環境を再現するのは大変です。なにか問題が発生した時の解析手段が一つ減ってしまいます。
- アップデートが大変
- ディスクイメージを、用途や種類ごとにたくさん作ってしまうと、一つのパッケージをアップデートするのは大変です。そして、CPANモジュールは、けっこうな頻度でアップデートされます。
というような理由で、キックスタート & rpm化 & puppetのほうが、柔軟性と速度が高い次元でバランスが取れており、これ以上高速化を求めることは、あまり意味がないのかな、と思っています。
もっとも、ディスクイメージのコピー自体は、色々と便利な手段で、例えば、用途ごとに分岐する前のOSキックスタートあたりにうまく適用できると、様々な可能性がある思います。ただ、ハードへの物理的なアクセスはしたくないので、ddのコピー先にネットワークブート+ディスクレスで起動して、ddによるコピーを受ける環境を整えるのが大変そうです。
