Le 15 févr. 07 à 14:02, Jérémy Dierx a écrit :
Bonjour,
Bonjour,
Parmis tout les railers ici présents, y en auraient-ils certains
qui aient déjà une expérience de l’hébergement RoR pro ? Je cherche
un retour d’expérience dans ce domaine avant de me lancer dans
l’aventure et proposer du RoR Ã mes clients :
Ca fait quasiment un an dans le cadre du service http://
feedback20.com en revanche on a pas opté pour la solution packagé
mais pour le full custom. Un infogérant pour le hosting, la
maintenance hardware, le monitoring et la couche système.
- failles de sécurité de la techno?
Mis à part l’épisode de la 1.1.6 à priori pas de raison de se méfier
de rails plus que n’importe quel autre techno, tout est entre les
mains du programmeur.
En revanche en terme de package c’est moins rose, en général quand on
cherche à héberger sérieusement on choisit une distribution stable et
des packages stables officiels. Seulement voilà pour héberger rails
il est quasi impossible de se cantoner à cela.
Exemple la version de ruby dans la Sarge 3.1 est la 1.8.2 alors que
RoR pousse à utiliser au moins la 1.8.4 voire la 1.8.5, pour
l’instant ca tourne sous 1.8.2 mais je doute qu’on ait une nouvelle
version stable pour debian avant que ce ne soit plus le cas.
Ce n’est pas le pire, en terme de serveur web il faut impérativement
prendre des risques que ce soit lighty, nginX ou mongrel il n’existe
pas de version stable sur les distributions dîtes “serieuse”.
Résultat un monitoring sérieux est impératif pour éviter les
mauvaises surprises.
Il est donc loin d’être idiot de passer par un hébergeur qui s’est
spécialisé en rails si on a pas envie de se pencher sur ce genre de
subtilité.
Pour ma part ca s’est excellement bien passé puisque qu’à part une
fois ou j’ai eu un process zombi pour cause de boucle infinie dans la
librairie yaml ca a été absoluement sans problème sur lighty+fcgi
- problématique des mise à jour de la techno ?
La mise à jour de rails n’est pas problématique sauf qu’il est
impératif de suivre les versions car le backport ne fait pas parti de
la doctrine officielle.
En revanche pour les mêmes raisons que précédemment (utilisation de
package testing sans mise à jour de sécu) il y a du travaille de
suivie au niveau du serveur web, et il n’est pas forcement facile de
choisir entre installabilité potentielle ou faille de sécu non
patché. Une bonne procédure de validation est requise.
Concrètement c’est ce coté là qui est le plus pénible surtout comparé
à une techno comme php qui est blindé à ce niveau.
- mutualisation (mongrel + apache2.2) / ressources nécessaires ?
Par expérience perso si la stabilité te préoccupe je te déconseille
fortement les environnements mutulisés (même avec php d’ailleurs) car
même si tout va bien chez toi rien ne dit que c’est le cas chez le
voisin. Si tu suis un peu ce qui se dit sur les forums anglais de
rails à ce propos la grosse tendance est au VPS.
- satisfaction global du prestataire (vous) ? des clients ?
Honnêtement excellente pour tout le monde, dans mon cas en tout cas.
- charge de travail en terme de maintenance par rapport à d’autres
techno (comme PHP) ?
Plus élévé pour l’hébergement c’est un fait mais ca reste
raisonnable, une bonne partie est relativement standard donc
facilement externalisable, pour s’assurer de la stabilité après modif
il n’y a qu’une possibilité tester…
- automatisation des processus de déploiement
Les meilleurs en l’état de l’art honnêtement, capistrano et les
migrations font des merveilles, c’est un plaisir d’appuyer sur la
touche en tremblant et de s’apercevoir que ca s’est déroulé sans
heurt. J’ai eu un problème une fois mais c’est backgroundrb qui a
refusé de démarré et a donc empèché le redemarrage du serveur alors
que la migration de la base avait eu lieu. Le jour juste avant Paris
on Rails en plus, arg… 7 minutes de downtime, les seuls en 1 an.
- stratégie globale choisie (redondance de DB, ip fail over,…
même si ce sujet sort un peu du cadre de cette techno) ?
On a commencé simple 2 serveurs en failover avec 2 DB en réplication.
D’ici peu de temps on passe à la version cluster avec DB en multi-
maitre, j’hésite encore à passer à nginX + mongrel ou à attendre une
stabilisation de lighttpd 1.5 pour avoir un proxy qui fonctionne
convenablement pour passer à mongrel avec en plus un support coté
server de l’upload avec barre progression directement en JSON.
Concrètement je n’ai aucune bonne raison de changer et de tenter le
diable surtout qu’un des adages en hébergement c’est de ne pas
changer une équipe qui gagne pour de mauvaises raisons.
Si on regarde 37signals ils tournent encore avec APACHE + FCGI sur
toutes leurs applis (c’est ce que disent les entêtes http en tk).
Ce sont surtout les hébergeurs type EngineYard avec Ezra qui sont en
train de pousser le couple NginX/mongrel car l’empreinte mémoire est
la meilleure et les dev pour apache2.2/mongrel car c’est le plus
simple et du terrain connu (please pas de flame :).
A vrai dire il n’y a pas LA solution tout dépend de tes ressources,
ton traffic, de ce que tu fais et du niveau de cache que tu y
associes, et du ratio cout/charge que tu es près à mettre.
Pour les petits budget sérieux un VPS nginX/mongrel est la solution
du moment mais ca change tous les 3 mois, la meilleure source d’info
actuelle est http://groups.google.com/group/rubyonrails-deployment.
Pour ceux qui recherche la plus grosses stabilité/scalabilité à un
cout raisonnable c’est le custom avec une petite prestation
d’infogérance pour mettre en place si on a pas les compétences en
interne.
Pour les plus gros bugdets des gens comme telecom Italia ou typhon
sont sans doute plus adaptés.
A noté que chez les américains un type nouveau d’hébergement est en
train d’emerger, type server grip/VPS qui promet le confort du tout
fait et une scalabilité sur commande. C’est l’optique marketé par
l’intermédiaire de shopify et c’est très prometteur, un big-ip/server
iron qui load balance et tape sur une ferme virtuelle de serveur
qu’on peut augmenter/diminuer à volonté. Reste à voir si pour un
utilisateur lambda ca marche aussi bien 
- pertinence de la mutualisation de petits et moyens sites pro chez
un hébérgeur comme dreamhost en comparaison à une mutualisation
perso sur dédié ?
Mon conseil c’est d’éviter les hébergeurs mutulisés, j’ai moi même
été hébergeur mutualisé php non commercial pendant 3 ans et je
connais plutôt bien le milieu, les business plans et les pratiques.
Techniquement c’est forcement pire avec une technos qui utilise des
serveurs d’application comme rails, en particulier dreamhost qui est
j’ose espérer est un des pires. J’avais un typo là bas et en gros une
action sur 5 ne démarrait pas car le process fastcgi était moisi, et
dans ce cas là tu n’as AUCUN moyen de régler le problème si ce n’est
déménager.
Un VPS peut-être, mais je ne m’y risquerai personnellement pas pour
un client mais j’ai un ami http://vinorati.com/ qui le fait sans
heurt hébergé aux us.
Un machin type dedibox ? pour une plateforme en prod c’est bof ca ne
permet pas de scaler et niveau perf c’est vraiment pas top (avec du
lighty/fcgi en tk, peut être avec un ngnix+mongrel c’est mieux), en
revanche c’est parfait pour la préprod.
Bref à toi d’abord de déterminer tes critères, ton budget et les
capacités technique à disposition. Le fait est qu’en France trouver
un prestataire avec une vraie Rails de production n’est pas chose
aisée. Si tu veux du conseil hors hébergement tout packagé j’avais
discuté un peu avec François SIMOND qui avait fait le sujet
hébergement à la Rails conf, qui m’avait plu et qui faisait de la
prestation externe. Tu peux trouver son email dans les archives de la
liste.
Renaud
j’ai du ajouter Globalize pour gérer
), mais