¿Mejores prácticas para nuevas implementaciones de Rails en Linux?

Question

He usado mestizo recto, he usado racimos mestizos detrás de Apache, he mirado a Thin, y Passenger me intriga mucho. También he mirado a Nginx. He visto MRI, Ruby Enterprise Edition, Rubinius y JRuby. Hay muchas opciones, cada una de las cuales dice ser el nuevo santo grial.

¿Cuál es la mejor opción para una implementación completamente nueva y totalmente actualizada? Los únicos supuestos son los siguientes:

• La aplicación está basada en Rails 2.2. (Sé que 2.2 aún no se ha lanzado completamente, pero tampoco esta implementación.)
• El servidor está basado en Linux. Probablemente Ubuntu Hardy, pero realmente, lo que funcione mejor en este caso.
• Rails necesitará ser completamente funcional y probablemente hablar con una base de datos MySQL.
• Todo lo demás es negociable.

Dadas estas limitaciones especialmente amplias, ¿qué combinación de software producirá el mejor resultado, en términos de concurrencia y baja sobrecarga?

Me estoy inclinando hacia Apache con el " trabajador " mpm y Passenger + Ruby Enterprise Edition, simplemente porque ofrece estabilidad inmediata y simplicidad de configuración y mantenimiento.

¿Es probable que esté particularmente mejor con otra opción?

Answer 1

Cambié de Mongrel Cluster a Passenger hace dos semanas (servidor Debian Linux). No miré hacia atrás ni por un segundo. Passenger es probablemente la forma más fácil de poner en funcionamiento su nuevo servidor. El rendimiento y la fiabilidad también son razonables.

Personalmente, me gusta pasar mi tiempo trabajando en nuevos y emocionantes proyectos de Rails en lugar de tratar con problemas de implementación: Passenger me permite hacer exactamente eso. Sin embargo, Mongrel o algo más puede ser preferible si tiene algún tipo de requisitos especiales (no se aplica a la mayoría de los productos).

Answer 2

Esta mañana, DHH habla sobre este mismo tema en su propio blog:

  

Pero de alguna manera el mensaje de Pasajero ha tardado un poco en asimilarse. Ya hay una tonelada de grandes sitios corriendo. Incluyendo Shopify, MTV, Geni, Yammer, y nos trasladaremos a la primera lista de Ta-da en breve, luego con suerte el resto de la suite de 37 señales rápidamente a partir de entonces.

     

Entonces, aunque todavía hay razones para ejecutar su propia configuración personalizada de varios niveles de piezas configuradas manualmente, al igual que hay personas que evitan mod_php por sus detalles, creo que finalmente nos hemos decidido por una respuesta predeterminada. Algo que no requiere que piense realmente en la primera implementación de su aplicación Rails. Algo que simplemente sale de la caja. ¡Incluso si ese cuadro es un host compartido!

http: //www.loudthinking .com / posts / 30-myth-1-rails-is-hard-to-deploy

Tobias L & # 252; tke sobre el tema de cambiar Shopify (millones de solicitudes / día) a Pasajero:

  

Todo esto significa que la cantidad total de memoria utilizada por Shopify durante las operaciones normales pasó de un promedio de 9 GB a un promedio de 5 GB. Distribuimos los ahorros de manera uniforme entre más procesos de Shopify y más espacio en memoria caché, lo que movió nuestro tiempo de respuesta promedio de 210 ms a 130 ms, mientras que el tráfico creció un 30% en los últimos meses.

     

En conclusión: no puedo ver ninguna razón para elegir una estrategia de implementación diferente en este momento. Es simple, completo, rápido y bien documentado.

http://blog.leetsoft.com/2008/11/15/passenger

Answer 3

Hemos estado usando el antiguo estándar nginx - > mongrel stack durante los últimos 18 meses, y aunque no fue trivial de configurar la primera vez, ha demostrado ser flexible, y se ha ocupado de algunos sitios de mucho tráfico para nosotros. Nginx en particular ha sido absolutamente sólido y rápido, y si puede obtener el almacenamiento en caché de la página de su aplicación, puede atender muchas solicitudes.

Los mestizos atascados han sido un problema, por lo que usamos monit para matarlos cuando se portan mal. Nuevamente, no fue totalmente trivial de configurar, pero hemos utilizado el mismo proceso en muchos sitios en este momento.

Todavía no hemos jugado con el pasajero, así que tal vez sea más fácil y más estable, diferiré con los otros respondedores sobre eso, todo lo que puedo decir es que no hay ninguna razón para que no puedas construir un sólido apilar con nginx y chucho.

Answer 4

Hemos cambiado fron NginX + Mongrel a Passenger.

Creo totalmente que Passenger será el nuevo estándar para los rieles, a pesar de que algunas personas muy inteligentes respaldan el clúster NginX y Mongrel. Los recientes avances en Passenger realmente lo han impulsado hacia adelante.

Nuestra configuración actual es algo así:

Servidores web

• Ubuntu 8.04 LTS
• Phusion Passenger en Apache2
• MRI Ruby 1.8.6 y amigos (formulario apto)
• Ruby Gems 1.3.0 (Instalado desde la fuente)

Servidores de bases de datos

• Centos 5
• MySQL Cluster (acabamos de cambiar a esto, pero es prometedor)

Habiendo estandarizado la distribución exacta de Linux, hemos podido escribir recetas Capitrano para ayudar a la implementación (pequeñas variaciones en la configuración han sido la fuente de MUCHAS interrupciones del servicio) y, de lo contrario, simplificar nuestras vidas.

Answer 5

Eche un vistazo a Litespeed . Puede obtener una versión gratuita que se ejecuta en 1 CPU o pagar para obtener varias CPU. Es un poco caro, pero es sólido como una roca y maneja los rieles de manera brillante (es decir, usa menos memoria y es menos costoso para monitorear y configurar). Ejecuto una gran cantidad de aplicaciones y no pierde el ritmo.

Answer 6

También cambiamos de Mongrel a mod_passenger y encontramos que la estabilidad mejoró enormemente con este esfuerzo requerido para la configuración y el mantenimiento. Buena elección.

Answer 7

Otro poco de oro:

La gema de Slicehost de Josh Peek está llena de recetas de Capistrano que son mucho más simples y mucho más organizadas que Deprec . Nada allí es especialmente específico de Slicehost, tampoco.

Answer 8

Estoy alojando mis nuevas aplicaciones con Apache2 y Passenger en Ubuntu Hardy. Parece la mejor y más fácil opción para la mayoría de los escenarios. Me acabo de unir a Slicehost.com para ese propósito. Parecen obtener buenas críticas y tienen los precios más competitivos de los anfitriones de primera clase.

Realmente no puedo respaldarlos todavía porque soy un cliente nuevo, pero el conjunto de guías y la gama de opciones de soporte son impresionantes.

Lo que no mencionas es cuán grande y popular es / será tu aplicación. Este criterio podría afectar el proceso de decisión.

Answer 9

Capistrano + Deprec para configurar mi stack en Ubuntu y administrar físicamente la implementación.

Nginx proxying a clusers mestizos para la arquitectura del servidor. No es la técnica más nueva y puntera, pero funciona bien, se está documentando bien y tiene un rendimiento muy, muy alto, incluso cuando se trabaja en VPS pequeños. Suponiendo que no ha bloqueado la aplicación, puede Slashdot un Slicehost VPS de 128 MB y sigue regresando por más.

Dicho esto: hubo un lote de problemas la primera vez, hasta que descubrí cómo funcionaba realmente Nginx. Después de eso es increíble, como un pequeño Apachelet con un ligero acento ruso.