Ergonomie, Rails et Architecture de l'information web (2.0)

Comment ça on ne migre jamais un vendredi ? C’est en tout cas ce que je répète régulièrement, non sans raison, mais là, j’avais envie.

Je viens de déménager le site vers mon nouveau serveur. La migration s’est à priori déroulée sans incident ni interruption de service, et les autres sites suivront durant le week-end : d’abord les sites en Ruby on Rails, puis les sites en PHP qui rejoindront la jail dans laquelle j’ai décidé de les confiner, les alertes de sécurité à répétition de Wordpress ayant tendance à sérieusement m’échauffer les oreilles.

Compte-rendu “live” de la session de ce premier Barcamp Paris Rails consacrée à Rails dans les environnements d’hébergement mutualisé que j’ai animé avec Nicolas Mérouze.

Problématiques soulevées :

• Partage des ressources (RAM et processeur) entre les différentes applications.
• Application web nécessitant un redémarrage à chaque changement en mode production, donc des privilèges élevés sur la machine.
• Complexité de mise en place pour un hébergement de masse, aux particuliers.

J’ai curieusement des sueurs froides chaque fois que je dois appeler le service commercial d’une entreprise fournissant des prestations grand public, que ce soient de l’accès à internet, de l’hébergement ou de l’électroménager. J’ai pourtant pris mon téléphone ce matin afin de m’enquérir de l’état de ma commande d’un nouveau serveur dédié qui devrait remplacer celui-ci sous quelques jours, et ô, surprise, ça ne s’est pas du tout déroulé comme prévu.

Quelques jours après Dedibox, OVH vient de révéler sa nouvelle grille tarifaire low cost, associée à de nouvelles offres matérielles plus qu’alléchantes. J’avais couvert avec intérêt le lancement de la Dedibox, il y a deux ans, et après des débuts hésitants, la Kimsufi d’OVH a visiblement atteint sa vitesse de croisière, et il est temps d’offrir un comparatif entre les deux offres.

S’il existe un grand nombre de manières de déployer et de faire tourner des applications développées avec Ruby on Rail, comme, au hasard, ce blog, l’hébergement de masse reste encore un vrai problème, principalement pour des raisons de complexité de configuration côté serveur. L’absence sous Apache d’un modrails comme il existe un modphp y était certainement pour beaucoup, jusqu’à la sortie hier de Passenger, aussi appelé modrails. Enfin terminés les atermoiements entre mongrel + modproxy, ou fastcgi, avec tous les inconvénients inhérents à ces deux solutions. Il existe certes d’autres solutions logicielles, parmi lesquelles ma préférée va à Nginx + Thin, cependant quand on héberge des sites faisant très massivement appel à mod_rewrite, ces dernières sont malheureusement exclues (à moins que quelqu’un ne me porte les quelques 500 rewrite rules qui restent encore ici et là).

Mais sans plus attendre, rentrons immédiatement dans le vif du sujet, l’installation de mod_rails pour Apache 2 sous Debian.

Webfaction fait partie de ces hébergeurs qui ont bien compris l’intérêt de proposer de bonnes alternatives à PHP – comme Ruby on Rails par exemple – et des alternatives aux panneaux de contrôle généralement peu intuitifs ou lents proposés en standard par la grande majorité des sociétés du même genre (webmin, plesk…).