開発用途のサーバを立てる場合、環境ごとに実サーバを持とうとすると運用コスト面でネックになります。
コストを抑えるために類似環境を数台のサーバにまとめている場合、本番環境とOSやミドルウェアのバージョンが違っていると、アップ後にその問題に気づいてリリース直前に慌てたりすることも懸念されます。
同等環境をもつ検証用サーバがないと、本番環境のバージョンアップや構成変更が必要になった場合に影響範囲をあらかじめ把握しておくことができません。新しいバージョンやモジュールを試したい時でも、クリティカルな案件では評価が出そろうまで様子を見ようという消極的な判断にもなってしまいます。
この課題を解決すべく VirtualBox を使って、ローカルマシンに仮想環境を作って開発する方法を試してみました。
ローカルマシン [ Intel Core i7(2.8GHz)/4GB - Windows7(32bit) ] 上に、最少構成の CentOS5 で Varnish + Webサーバ のように複数仮想マシンを立ててみましたが、開発作業を行う上でのパフォーマンス面では全く支障ありませんでした。
開発用途で実サーバの代替になりうるか？という点ではいくつかの注意点があります。
VirtualBox の場合、デフォルトでは1つの仮想ネットワークアダプタに NAT で割り当てられます。この設定ではゲストOS上からの外部への接続しかできず、ホストOS含め外部からゲストOSへの接続ができません。このままではゲストOS上ですべての作業を行わなければならず不便です。
割り当てを「ブリッジネットワーク」に変更し、社内LANに参加させる方法が最もシンプルなのですが、以下の課題があります。
- 各仮想マシンのゲストOSごとにIPアドレスの割り当てが必要。開発スタッフが多いとIPアドレスの管理が煩雑。
- 社内LAN配下でないとゲストOSに接続できない。
互いの仮想環境にアクセスするには都合がよいのですが、個別に思いのままの仮想環境を立ち上げる場合には不便です。ローカルマシンで完結させる用途では以下のネットワーク構成が都合がよいです。
- アダプタ1(eth0)
- NAT - ゲストOSから外部ネットワークに接続（yum/メール送信/外部サービスへのソケット通信/等）
- アダプタ2(eth1)
- Host Only Network - ホストOS / ゲストOS 間を接続できるようにする目的
Host Only Network により、ホストOSがルータになってLANを作りますので、どういう構成で組むかはそれぞれで思いのままですし、ローカルマシン内に環境があるのでネットにつながっていなくても作業できます。
自分はサーバに ssh ログインして vim でコードをガリガリ書いていくタイプなので、キータイプごとにネットワーク通信が行われます。遠いリージョンの Amazon EC2 インスタンスに接続したり、mopera のようなデータ通信サービスから接続する際、わずかなデータ転送速度の違いでレスポンスの悪さを感じて作業になりません。これがローカルマシン内で済むことになりますので作業効率はもちろんのこと、ネットにつなげない状況であったり、許可ネットワーク外にいる場合でも作業ができることになり、開発用途ではこちらの方がはるかに快適です。
ローカルマシンでコードを書いて、逐一サーバにアップする人にとっても、VirtualBox の共有フォルダを使えばダイレクトに変更することができますし、サーバへファイルアップする手順であっても物理ネットワークを介さずに済みます。
導入のメリットをまとめると
- マシンスペックが許す限り、好きなだけ環境を持てる。
- 仮想マシン状態のスナップショットがとれるため、新しいモジュールを評価したいときにも躊躇せずインストールを行える。
- 同じサーバを立てたければディスクイメージの複製を作るだけなので、セットアップ作業を大幅に短縮できる。
- ローカルマシン上で仮想環境を作ることで、ネットにつなげない環境や許可ネットワーク外にいても作業できる。
デメリットとしては
- 複数人で各ローカルマシン上で開発を行う際、互いの更新のマージが必要。
- 各ローカルマシン内のゲストOSへ外部からのアクセスはできない。OpenID認証(RP Discovery)やメール受信などを扱う場合には、ローカルマシン内にダミープログラムを設置したり、ポートフォワードの設定が必要
- 操作ミス/ハードウェア障害でのバックアップが各個人にゆだねられる。うっかり仮想マシンごと消してしまった/HDが壊れて復旧できない/等
- テンプレートファイルや静的ページだけを担当するスタッフやサーバ構築に不慣れなスタッフにとっては負担になる。
ということが挙げられます。
今回はローカルマシンでの作業用途でのレビューでしたので、次回は複数人開発向けの共有開発サーバとして設置する場合でレポートしたいと思います。
