ruby on rails - rails - ¿Por qué aún no hay una mod_ruby viable para Apache?
nginx ruby on rails (5)
A pesar de lo popular que son Ruby and Rails, parece que este problema ya estaría resuelto. JRuby y mod_rails son buenos y elegantes, pero ¿por qué no hay un mod de Apache para Ruby?
Existe Phusion Passenger , un robusto módulo Apache que puede ejecutar aplicaciones Rack con una configuración mínima. Se está volviendo atractivo para los hosts compartidos, y convertir cualquier programa en una aplicación Rack es ridículamente fácil:
Una aplicación Rack es un objeto Ruby (no una clase) que responde a la
call. Toma exactamente un argumento , el entorno y devuelve una matriz de exactamente tres valores : el estado, los encabezados y el cuerpo.
Hay uno: mod_ruby , pero no se ha mantenido en aproximadamente 2 años.
Quizás valga la pena aclarar dos veces el punto de mislav de que mod_rails en realidad no está limitado al código de Rails. El nuevo nombre, mod_rack, es mucho mejor. Las aplicaciones trivialmente pequeñas pueden ser en rack, siendo su ejemplo:
class HelloWorld
def call(env)
[200, {"Content-Type" => "text/plain"}, ["Hello world!"]]
end
end
El problema básico es este: durante mucho tiempo, la resonancia magnética fue la única implementación factible de Ruby. La resonancia magnética tiene una serie de problemas que dificultan su inclusión en otra aplicación (que es básicamente lo que hace mod_ruby : incorpora MRI en Apache), especialmente uno de múltiples subprocesos (que es Apache). No es particularmente seguro para subprocesos y tiene bastante estado global.
Este estado global significa, por ejemplo, que si una aplicación Rails modifica alguna clase, todas las demás aplicaciones Rails que se ejecutan en el mismo servidor Apache también verán esta clase modificada.
Otro problema es que el código fuente de MRI no es fácilmente pirateable. La resonancia magnética ahora tiene más de 15 años y está comenzando a mostrarse.
Como resultado de estos problemas, mod_ruby nunca funcionó correctamente, y en algún momento los mantenedores simplemente se dieron por vencidos.
El intérprete PHP basado en C, por otro lado, fue diseñado desde el primer día para ser ejecutado como mod_php dentro de Apache. De hecho, para las primeras dos versiones, ni siquiera había una versión de línea de comando del intérprete, mod_php era la única forma de ejecutar PHP.
Phusion Passenger (también conocido como mod_rack aka mod_rails) resuelve este problema básicamente renunciando y eludiendo el problema: simplemente ejecutan una copia separada de MRI en un proceso separado para cada aplicación. Funciona de maravilla, y no solo para Ruby. Es compatible con WSGI (interfaz estándar para Python Web Frameworks), Rack (interfaz estándar para Ruby Web Frameworks) y soporte directo para Ruby on Rails.
Mis esperanzas están en mod_rubinius , que desafortunadamente aún no existe. Rubinius fue diseñado desde el principio para ser seguro para subprocesos, incrustable, sin estado global, no utiliza la pila C, etc. Fue diseñado para poder ejecutar múltiples máquinas virtuales Rubinius dentro de un proceso Rubinius. Esto hace que mod_rubinius sea infinitamente más fácil de implementar y mantener que mod_ruby. Lamentablemente, por supuesto, Rubinius aún no se ha lanzado, y el verdadero trabajo en mod_rubinius no puede comenzar hasta que se libere Rubinius. La buena noticia es que mod_rubinius ya tiene más personal detrás que mod_ruby, porque le ha pagado a los desarrolladores que trabajan en él por una empresa de hosting de Rails que quiere utilizarlo desesperadamente .