Почему еще нет жизнеспособного mod_ruby для Apache?

Ответ 1

Основная проблема заключается в следующем: в течение долгого времени МРТ была единственной возможной реализацией Ruby. У МРТ есть ряд проблем, из-за которых трудно внедрить его в другое приложение (что в основном означает mod_ruby: он включает MRI в Apache), особенно многопоточный (который Apache). Он не является особенно потокобезопасным и имеет довольно много глобального состояния.

Это глобальное состояние означает, например, что если одно приложение Rails модифицирует некоторый класс, тогда все другие приложения Rails, которые запускаются на одном сервере Apache, также будут видеть этот модифицированный класс.

Другая проблема заключается в том, что исходный код MRI нелегко взломать. Сейчас МРТ более 15 лет, и она начинает показывать.

В результате этих проблем mod_ruby никогда не работал должным образом, и в какой-то момент сторонники просто отказались.

С другой стороны, интерпретатор PHP на основе C был разработан с первого дня, который запускается как mod_php внутри Apache. Действительно, для первой пары версий не было даже версии интерпретатора с командной строкой, mod_php был единственным способом запуска PHP.

Phusion Passenger (aka mod_rack aka mod_rails) решает эту проблему, в основном отказываясь от проблемы: она просто запускает отдельную копию МРТ в отдельном процессе для каждого приложения. Он отлично работает, и не только для Ruby. Он поддерживает WSGI (стандартный интерфейс для веб-фреймов Python), Rack (стандартный интерфейс для Ruby Web Framework) и прямая поддержка Ruby on Rails.

Мои надежды находятся на mod_rubinius, чего, к сожалению, пока нет. Rubinius был разработан с самого начала, чтобы быть потокобезопасным, встраиваемым, свободным от глобального состояния, а не использовать C-стек и так далее. Он был разработан, чтобы иметь возможность запускать несколько виртуальных машин Rubinius внутри одного процесса Rubinius. Это делает mod_rubinius бесконечно проще реализовать и поддерживать, чем mod_ruby. К сожалению, конечно, Rubinius еще не выпущен, и настоящая работа над mod_rubinius не может даже начаться до тех пор, пока не будет выпущен Рубиний. Хорошая новость заключается в том, что у mod_rubinius уже больше трудозатрат, чем у mod_ruby, поскольку он заплатил разработчикам, работающим над ним, хостинговой компанией Rails, которая отчаянно хочет использовать ее самостоятельно.

Ответ 2

Существует Phusion Passenger, надежный модуль Apache, который может запускать Rack с минимальной конфигурацией. Это становится привлекательным для общих хостов, и превращение любой программы в приложение Rack довольно смешно:

Приложение Rack представляет собой объект Ruby (а не класс), который отвечает на call. Он принимает ровно один аргумент, среды и возвращает массив ровно три значения: статус, заголовки и тело.

Ответ 3

Возможно, стоит двузначный пункт mislav, что mod_rails фактически не ограничивается кодом Rails. Новое имя, mod_rack, намного лучше. Тривиально небольшие приложения могут быть стойкими - их пример:

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

Ответ 4

Есть один: mod_ruby, но он не поддерживался примерно через 2 года.

Ответ 5

Существует mod_rails, и он может запускать Rack, что еще вам нужно?