サーバー構築自動化の実装方法

dRubyを使うと言っていて、逆にdRuby以外に何が必要なのかと言うと、1つは冗長化されたネームサービス、もう1つはプラグインローダ。


ネームサービスならRingがあるわけですが、そのままだと冗長性がないので、何かしら対処が必要になります。
ではどうするか?とうところは、まだ考えていないです。TupleSpaceやRinda::templateのような便利なものは揃っているので、まぁ何とかなるんじゃないかな、と考えています。カスケード・フェイルオーバーするようにするとか、上記分散ファイルシステムVRRPとかとか。いざというときにはブロードキャストを多用すればなんとでもなりそうな。


で、プラグインローダ。先日のエントリに書いたようなプラグインを、順々に起動していくプログラム。
方法は2つあって、一つはfork+execする方法、もう1つはloadする方法。


fork+execの場合は、言語がRubyでなくても使える。でもネームサービスなどのAPIにアクセスするときにIPCなるので、ここのところを何とかしないといけない。それから、オブジェクトを永続化しないといけないので、プラグインは起動したらずっと動かしておかないといけない。プロセスが多くなって、リソースを喰う。
loadだとRubyでないと使えないものの、IPCは要らないし、プロセスをずっと動かしておく必要もない。



一長一短。しかしAPIRuby用に作る以上、Ruby Spirit的には後者なのではないかと。
loadだと副作用的ではあるけど、いろいろできる。

たとえば、先頭にrequreが要らない。こちらでrequireしておけばいい。
それから、provideされたオブジェクトを勝手に拡張できる。すべてのオブジェクトに同じメソッドを勝手に追加するとか。(適当なクラスを継承しておいてもらえば良いのだけど、継承するように書く作業を省ける)
@NetworkManagerというメンバ変数を持っていれば、勝手にinitializeメソッドを拡張して、DSiAS.local.NetworkManagerを入れておくとか。ついでにコレで実行順制御と依存関係解決を行う(今までは別にメタデータが必要だった)。Rubyはリフレクションがおそろしく普通にできる。コード内でDependency Injection、的な。…あ、先頭に大文字は使えないな。先頭に1字付けるなどで、なんとでもなる。
普通はプラグイン名=クラス名にするし、そう限定した方が逆に分かりやすいので(Railsっぽい)、最後のDSiAS.provideも要らない。こちらでやってしまえばいい。
他のもいろいろできそうで、これは楽しい。