Meilleures pratiques pour les nouveaux déploiements Rails sous Linux?

Question

J'ai utilisé des bâtons droits, des groupes de bâtards derrière Apache, j'ai examiné Thin et je suis devenu très intrigué par Passenger. J'ai aussi regardé Nginx. J'ai examiné l'IRM, Ruby Enterprise Edition, Rubinius et JRuby. Il existe de nombreuses options, chacune prétendant être le nouveau Saint-Graal.

Quelle est la meilleure option sur le marché pour un nouveau déploiement entièrement à jour? Les seules hypothèses sont les suivantes:

• L'application est basée sur Rails 2.2. (Je sais que la version 2.2 n’a pas encore été entièrement publiée, mais ce déploiement ne l’est pas non plus.)
• Le serveur est basé sur Linux. Probablement Ubuntu Hardy, mais vraiment, tout ce qui fonctionne le mieux dans ce cas.
• Les mails devront être entièrement fonctionnels et probablement communiquer avec une base de données MySQL.
• Tout le reste est négociable.

Compte tenu de ces contraintes particulièrement larges, quelle combinaison de logiciels donnera le meilleur résultat, en termes de simultanéité et de temps système réduit?

Je me penche vers Apache avec le "travailleur". mpm et Passenger + Ruby Enterprise Edition, tout simplement parce qu’il offre une stabilité et une simplicité de configuration et de maintenance immédiates.

Suis-je susceptible d'être particulièrement mieux loti avec une autre option?

Answer 1

Je suis passé de Mongrel Cluster à Passenger il y a deux semaines (serveur Debian Linux). Je n'ai pas regardé en arrière une seconde. Passenger est probablement le moyen le plus simple de mettre votre nouveau serveur en service. Les performances et la fiabilité sont également raisonnables.

Personnellement, j'aime passer mon temps à travailler sur de nouveaux projets Rails excitants plutôt que de traiter de problèmes de déploiement - Passenger me permet de faire exactement cela. Cependant, Mongrel ou autre chose peut toujours être préférable si vous avez des exigences particulières (ne s'applique pas à la plupart des produits).

Answer 2

Ce matin, DHP a abordé ce sujet sur son propre blog:

  

Mais d’une certaine manière, le message de Passenger a été un peu lent à s’enfoncer. Il existe déjà une tonne de sites gigantesques. Incluant Shopify, MTV, Geni, Yammer, nous allons bientôt passer à la première liste de Ta-da, puis nous espérons que le reste de la suite de 37signals le sera rapidement par la suite.

     

Ainsi, s'il reste toujours des raisons d'exécuter votre propre configuration personnalisée à plusieurs niveaux d'éléments configurés manuellement, tout comme certaines personnes s'éloignent de mod_php pour leurs détails, je pense que nous avons finalement opté pour une réponse par défaut. Ce qui ne vous oblige pas à vraiment penser au premier déploiement de votre application Rails. Quelque chose qui fonctionne hors de la boîte. Même si cette boîte est un hôte partagé!

http: //www.loudthinking .com / posts / 30-myth-1-rails-est-difficile-à-déployer

Tobias Lütke à propos du transfert de Shopify (en millions de demandes / jour) sur Passenger:

  

Tout cela signifie que la quantité totale de mémoire utilisée par Shopify au cours de son fonctionnement normal est passée de 9 Go en moyenne à 5 Go en moyenne. Nous avons également réparti les économies réalisées entre davantage de processus Shopify et plus d’espaces mémoire, ce qui a permis à notre temps de réponse moyen de passer de 210 ms à 130 ms alors que le trafic a augmenté de 30% au cours des derniers mois.

     

En conclusion: je ne vois aucune raison de choisir une stratégie de déploiement différente à ce stade. C'est simple, complet, rapide et bien documenté.

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

Answer 3

Nous utilisons l’ancien standard nginx - > pile bâtarde pour les 18 derniers mois, et bien que ce ne soit pas simple à installer la première fois, il s’est avéré flexible et nous a permis de gérer des sites à très fort trafic. Nginx en particulier a été absolument solide et rapide, et si vous pouvez obtenir la mise en cache des pages de votre application, vous pouvez traiter de nombreuses demandes.

Les bâtards coincés ont été un problème, nous utilisons donc monit pour les tuer quand ils se conduisent mal. Encore une fois, la configuration n’était pas totalement triviale, mais nous avons utilisé le même processus sur de nombreux sites à ce stade.

Nous n’avons pas encore joué avec le passager, alors c’est peut-être plus facile et plus stable, je laisserai la parole aux autres intervenants, tout ce que je peux dire, c’est qu’il n’ya aucune raison de ne pas construire un solide empiler avec nginx et métis.

Answer 4

Nous sommes passés de NginX + Mongrel à Passenger.

Je suis tout à fait convaincu que les passagers seront la nouvelle norme pour les rails, malgré les grappes NginX et Mongrel approuvées par des personnes très intelligentes. Les progrès récents en matière de passagers l'ont vraiment propulsé vers l'avant.

Notre configuration actuelle ressemble à ceci:

Serveurs Web

• Ubuntu 8.04 LTS
• Phusion Passenger sur Apache2
• MRI Ruby 1.8.6 et ses amis (form apt)
• Ruby Gems 1.3.0 (installé à partir du code source)

Serveurs de base de données

• Centos 5
• MySQL Cluster (nous venons de passer à cela, mais c'est prometteur)

Après avoir normalisé la distribution Linux exacte, nous avons pu écrire des recettes Capitrano pour faciliter le déploiement (de légères variations de configuration ont été à l’origine de nombreuses pannes de service) et nous simplifions autrement la vie.

Answer 5

Consultez Litespeed . Vous pouvez obtenir une version gratuite fonctionnant sur 1 cpu ou payer pour obtenir plusieurs cpu. C’est un peu cher, mais il est solide et gère les rails de manière brillante (c’est-à-dire qu’il utilise moins de mémoire et représente moins de surcharge à surveiller et à configurer). Je lance une quantité impressionnante d’applications sans perdre une minute.

Answer 6

Nous sommes également passés de Mongrel à mod_passenger et nous avons constaté que la stabilité était grandement améliorée grâce aux efforts nécessaires à l’installation et à la maintenance. Bon choix.

Answer 7

Un autre peu d'or:

La joyau Slicehost de Josh Peek regorge de recettes Capistrano beaucoup plus simples et bien organisées que Deprec. . Rien ici n’est particulièrement spécifique à Slicehost.

Answer 8

J'héberge mes nouvelles applications avec Apache2 et Passenger sur Ubuntu Hardy. Cela semble être la solution la plus simple et la meilleure pour la plupart des scénarios. Je viens de rejoindre Slicehost.com à cet effet. Ils semblent avoir de bonnes critiques et ont les prix les plus compétitifs des hôtes de première classe.

Je ne peux pas encore vraiment les approuver car je suis un nouveau client, mais l'ensemble des guides et la gamme d'options d'assistance sont impressionnants.

Ce que vous ne mentionnez pas, c'est la taille et la popularité de votre application. Ce critère pourrait affecter le processus de décision.

Answer 9

Capistrano + Deprec pour la configuration de ma pile sous Ubuntu et la gestion physique du déploiement.

Nginx servant de proxy aux clusers Mongrel pour l’architecture de serveur. Ce n'est pas la technique la plus récente, mais elle fonctionne bien, elle est bien documentée et ses performances sont très très élevées, même lorsque vous travaillez sur de petits VPS. En supposant que vous n’ayez pas bougé l’application, vous pouvez Slashdot un VPS Slicehost de 128 Mo et il ne cesse de revenir pour plus.

Cela dit: il y a eu beaucoup de trucs la première fois, jusqu'à ce que je découvre comment Nginx fonctionne réellement. Après cela, c'est incroyable - comme un petit apachelet avec un léger accent russe.