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

Le lancement de la dernière offre “pro” de l’hébergeur à bas prix Dedibox qui a fait couler pas mal d’encre virtuelle et de récentes conversations autour des solutions d’hébergement professionnelles m’ont montré que, même au sein des travailleurs du web, les différentes offres d’hébergement n’étaient pas comprises de la même manière, entraînant souvent au mieux des incompréhensions jusqu’à la réception du devis, au pire, des commandes sur ou sous dimensionnées par rapport aux besoins réels.

Cet article vise donc à démystifier les offres d’hébergement web en clarifiant les 10 points qui semblent le plus souvent poser problème. Il est entrecoupé de considérations toutes personnelles sur telle ou telle offre d’hébergement et tel ou tel hébergeur que j’ai pu croiser ici et là.

Pas de repos pour les braves en ce 14 juillet – normal il est hollandais, il n’en a donc pas grand chose à faire – puisque Hongli Lai vient d’annoncer la sortie de Passenger mod_rails 2.0.2, qui corrige un certain nombre de bugs critiques. Passenger est un module Apache qui rend le déploiement d’une application Ruby on Rails, mais pas seulement, aussi simple qu’un site en PHP, retirant la principale épine du pied de mon framework web favori.

Cette nouvelle version de Passgenger corrige en particulier une importante fuite de mémoire qui survenait chaque fois qu’un client web quittait le ApplicationPoolServerExecutable. Celle-ci, après avoir mis le serveur à genoux et rendu le site indisponible pendant un week-end entier m’avait finalement forcé à downgrader en 1.0.5 nettement plus stable.

Et comme une bonne nouvelle n’arrive jamais seule, cette version arrive avec un paquet Ubuntu tout chaud.

Le site – ainsi que tous les sites hébergés ici – a été indisponible une bonne partie du week-end pour toutes un tas de mauvaises raisons rigolotes quand on y pense, à savoir :

1. Impossible de résoudre les noms de domaine (hier). Et pour cause, TinyDNS tombait chaque fois qu’on essayait d’y accéder car il ne pouvait pas ouvrir ses logs en écriture, c’est à dire souvent.

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.

Durant le RailsCamp Paris, nous discutions des perspectives que mod rails ouvrait dans le domaine de l’hébergement mutualisé Ruby on Rails, une fois son adoption réalisée par les hébergeurs grand public. Nous ignorions alors que Dreamhost, l’un des principaux hébergeurs mondiaux venait d’annoncer sur son blog la mise à disposition de Passenger / mod rails sur l’intégralité de son parc mutualisé.

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.

1&1 ne me proposant malheureusement pas d’IP françaises, me voilà contraint de rapatrier ce blog sur le sol hexagonal, et du même coup de changer de plate-forme. Tout ça pour une bête question de référencement dans les outils de recherche. Enfin, peut-être pas si bête que ça en fait.

D’un point de vue technique, cela nous donne :

Avant

• Athlon64 3500+.
• 1go de RAM.
• 80go de disque dur.
• 100mb.

Maintenant

• Pentium4 3ghz hyper threadé.
• 2go de RAM.
• 250go de disque dur.
• 100mb.

Le tout pour 20 euros de moins par mois. Je perds en revanche le raid 1 et le backup en ftp de 80go proposés par 1&1, mais vus les tarifs, il n’est pas exclu que je prenne un hébergement de backup ailleurs histoire d’assurer le coup. Comme ils disent dans les assurances, ça ne coûte cher qu’avant l’accident.

Et si vous lisez ce billet, c’est que la migration s’est faite sans problème.