menéame -
Rails ha seguido muchos métodos de implantación los últimos cinco años. Lancé Basecamp con mod_ruby de nuevo cuando simplemente tenía una aplicación y entonces no me preocupaba que no pudiera ejecutar más sin solaparlas.
En los primeros momentos, puedes ejecutar Rails incluso como CGI, si no tienes una gran cantidad de carga. Solíamos hacer esto en el modo de desarrollo para que la pila completa se pudiera recargar entre cada petición.
Entonces migramos hasta FCGI. Esta es actualmente una plataforma viable. Ejecutamos durante años con FCGI. Pero esta plataforma no ha tenido un desarrollo activo durante mucho tiempo, y mientras las cosas han funcionado y había demasiadas urgencias que solucionar tenías que preocuparte de ellas para que corrieran bien.
Entonces vino Mongrel
Entonces llegó Mongrel y la confirmación de que no necesitábamos otro protocolo de comunicación para que los servidores de aplicaciones y los servidores web hablaran entre ellos. ¡Simplemente podíamos usar HTTP!. Así que se pusieron en marcha muchos paquetes de Mongrel detrás de proxies y balanceadores de carga.
Hoy, Mongrel (que es de un tipo similar a servidores basados en Ruby como Thin y Ebb) todavía predomina en el entorno de implantación y por muchas buenas razones: es estable, es versátil y es rápido.
La paradoja de muchas opciones lo suficientemente buenas
Pero hay también una jungla de opciones. ¿Qué servidor de web ejecuto?. ¿Ejecuto con Apache, nginx, o incluso lighthhtp?. ¿Hago relevo sobre los proxies del servidor de web o utilizo algo como HAProxy o Pound?. ¿Cuántos mongrels ejecuto?. ¿Los ejecuto bajo supervisión de procesos con monit o no?
Hay muchas respuestas sólidas y perfectamente válidas a estas preguntas. En 37signals hemos estado usando Apache 2.2 con HAProxy con procesos Mongrel vigilados por monit durante unos pocos años. Cuando ya has revisado en que partes utilizarlo, ves que no es una buena decisión.
Pero la disponibilidad de todas estas piezas que parecen tener todas sus argumentos válidos para llevarte a una elección. Cuando al fin has terminado de crear tu aplicación con Rails, puedo entender que no quieras convertirte también en un experto en los pros y contras de los servidores web, proxies, balanceadores de carga y monitores de procesos.
Y pienso que aquí el mito tiene sus raíces. La abundancia de muchas opciones lo suficientemente buenas. La falta de una única respuesta a cómo implantar Rails. Sin sies, sin noes, sin “eso depende”.
La solución de una sola pieza de Phusion Passenger
Ese es el motivo por el cual estoy realmente feliz de ver que el grupo Phusion sacó de la nada a principios de este año Passenger (también conocido como mod_rails). Un módulo único, gratuito, open source para Apache que trajo la facilidad de instalación como la de un módulo mod_php.
Una vez que lo has instalado tienes un Apache que sirve como todo: servidor web, balanceador de carga, servidor de aplicación y monitorizador de procesos. Simplemente descargas la aplicación y haces un touch de tmp/restart.txt cuando quieras inciar y listo, ya estás funcionando.
Pero Passenger ha sido un poco lento en su llegada. Hay muchos sitios que están ejecutándose sin él. Incluyendo Shopify, MTV, Geni, Yammer, y nosotros tendremos migrado Ta-da list primero, y después esperamos que el resto de la suite de 37signals rápidamente después de él.
Así que mientras todavía hay razones para ejecutar tu propia instalación personalizada y configurada manualmente, igual que hay gente fuera de mod_php para usos particulares, creo que hemos encontrado finalmente una respuesta por defecto. Algo que no requiere realmente que pienses en la primera implantación de Rails. Algo que simplemente trabaja, aunque sea en un hospedaje compartido.
En conclusión, Rails nunca más será complicado de implantar. Phusion Passenger lo ha hecho ridículamente fácil.
Puedes ver más artículos de esta serie:
Nota: Este artículo es una traducción del publicado por David Heinemeier en su blog.
Comentarios Recientes