ruby-on-rails - Apache 用の実行可能な mod_ruby がまだないのはなぜですか?

Question

Ruby や Rails が普及しているように、この問題はすでに解決されているようです。JRuby と mod_rails はどれも素晴らしいものですが、Ruby だけの Apache mod がないのはなぜでしょうか?

Answer 1

最小限の構成でRackアプリケーションを実行できる堅牢な Apache モジュールであるPhusion Passengerがあります。共有ホストにとって魅力的になりつつあり、プログラムを Rack アプリケーションに変えるのは驚くほど簡単です。

Rack アプリケーションは、に応答するRubyオブジェクトcall(クラスではない) です。1 つの引数、環境を取り、正確に3 つの値(ステータス、ヘッダー、本文) の配列を返します。

Answer 2

基本的な問題はこれです: 長い間、MRI は実行可能な唯一の Ruby 実装でした。MRI には、別のアプリケーション (基本的にはmod_rubyが行うことです。MRI を Apache に埋め込みます)、特にマルチスレッドのアプリケーション (これは Apache です) に埋め込むのを困難にする多くの問題があります。特にスレッドセーフではなく、かなりのグローバル状態があります。

このグローバルな状態は、たとえば、1 つの Rails アプリケーションが何らかのクラスを変更した場合、同じ Apache サーバー上で実行される他のすべてのRails アプリケーションも、この変更されたクラスを参照することを意味します。

もう 1 つの問題は、MRI のソース コードが簡単にハッキングできないことです。MRI は現在 15 年以上経過しており、その兆候が現れ始めています。

これらの問題の結果として、mod_ruby は本当に適切に機能することはなく、ある時点でメンテナーは単純にあきらめました。

一方、C ベースの PHP インタープリターは、最初から Apache 内で mod_php として実行されるように設計されています。実際、最初の 2 つのバージョンでは、インタプリタのコマンドライン バージョンさえなく、mod_php がPHP を実行する唯一の方法でした。

Phusion Passenger (別名 mod_rack 別名 mod_rails)は、基本的に問題をあきらめて回避することでこの問題を解決します。アプリケーションごとに個別のプロセスで MRI の個別のコピーを実行するだけです。Rubyだけでなく、うまく機能します。WSGI (Python Web フレームワークの標準インターフェース)、Rack (Ruby Web フレームワークの標準インターフェース) をサポートし、Ruby on Rails を直接サポートします。

残念ながらまだ存在しないmod_rubiniusに期待しています。Rubiniusは最初から、スレッドセーフで、組み込み可能で、グローバルな状態から解放され、C スタックなどを使用しないように設計されています。1 つの Rubinius プロセス内で複数の Rubinius VM を実行できるように設計されています。これにより、mod_rubinius は mod_ruby よりも実装と保守がはるかに簡単になります。もちろん、残念ながら Rubinius はまだリリースされておらず、mod_rubinius の実際の作業は Rubinius がリリースされるまで開始できません。幸いなことに、mod_rubinius はすでに、mod_ruby がかつて持っていたよりも多くの人員を背後に抱えているということです。これは、Rails ホスティング会社が開発者に支払いを行っており、Rails ホスティング会社が自分たちでそれを使用したいと切望しているからです。

Answer 3

mod_rails は実際には Rails コードに限定されていないという mislav の指摘を二重に明確にする価値があるかもしれません。新しい名前 mod_rack の方がはるかに優れています。ごく小さなアプリはラックに収納できます。その例は次のとおりです。

class HelloWorld
  def call(env)
    [200, {"Content-Type" => "text/plain"}, ["Hello world!"]]
  end
end

Answer 4

mod_rubyがありますが 、2年ほどメンテナンスされていません。

Answer 5

mod_railsがあり、 Rackアプリケーションを実行できます。他に何が必要ですか?