Ruby/JRuby Process Models Explained (by Arun Gupta 8/20/07)JRuby Hackday にて、Nick Sieger は以下に Rails アプリケーションを配備した際のプロセスモデルを解説しました。 本ブログエントリで、私はイベント後の頭の中のダンプをとります。以下の画像は上で述べた各アプローチのプロセスモデルです。各画像のに含まれている箱はプロセスでなく、アプリケーションロジックを表します。画像の凡例は次のようなものです。 Cannot resolve external resource into attachment. 最初のアプローチでは、C ベース Ruby on Rails アプリケーションは、フロントに HTTP ライブラリ、Mongrel を置いています。典型的なアプリケーションは Mongrel サーバのクラスタ (Mongrel_cluster プラグインで提供される) に配備されます。 Cannot resolve external resource into attachment. Mongrel クラスタでは、複数の Ruby インタプリタは OS の単一プロセスとして起動されます。 二つ目のアプローチは、Rails アプリケーションを JRuby を使って配備するかを示します。これは、C Ruby + Mongrel 配備と JRuby + GlassFish 配備の間の過渡的なアプローチです。 Cannot resolve external resource into attachment. Mongrel JCluster では、OS プロセスとしては、JVM が一つ起動されるのみです。 最後のアプローチは JRuby アプリケーションをどう GlassFish に配備するかを示します。このアプローチでは、アプリケーションを配備する上で二つのモードがあります。 Cannot resolve external resource into attachment. 一つ目の場合、Goldspike プラグインが標準的な Rails アプリケーションにインストールされます。このプラグインは "war:*" rake ターゲットを Rails プロジェクトに追加します。rake ターゲット "war:standalone:create" を実行すると、依存性のある JRuby と Rails ライブラリを全て含む WAR ファイルを生成します。そうすると、この WAR ファイルを GlassFish に配備できます。この WAR ファイル内の "web.xml" には、Servlet リクエストから Rails ディスパッチャへデータを変換する Servlet (org.jruby.webapp.RailsServlet) が載っています。 Cannot resolve external resource into attachment. 二つ目の場合では、Grizzly コネクタがリクエストの形式を理解し、直接、事前に設定された JRuby インストール (Rails gem で更新されます) にディスパッチします。両方の場合で、GlassFish としては単一の JVM が OS プロセスとして動いています。二つ目のアプローチの主な利点は、web アプリケーション処理をバイパスし、リクエストを直接 Rails フレームワークに委任することです。 最初の GlassFish のケース (Goldspike/JRuby) に関する詳しいスクリーンキャストはこちらで、二つ目のケース (Grizzly/JRuby) はこちらにドキュメントされています。 日本語翻訳: ogino |
