Malgré le silence relatif sur le blog RoR, nous ne nous sommes pas croisés les pouces chez Bearstech ces 6 derniers mois. Nous avons travaillé sur l'infrastructure de notre plate-forme et pouvons maintenant annoncer quelques nouveautés, étalées sur quelques posts sur ce blog, en commençant par les versions de Ruby et de Debian.

Notre dernière tentative avec un template basé sur Lenny nous avait laissé avec une version de Ruby pas vraiment adaptée aux applications Rails : Ruby 1.8.7. Il nous fallait donc soit abandonner Lenny, soit packager un Ruby différent (la version 1.8.6 par exemple, maintenue par Engine Yard).

Estimant qu'il serait dommage de se priver de Lenny (Etch se fait vieille), nous avons décidé de packager la dernière release de Ruby 1.8.6 pour Lenny, ce qui s'est révélé plutôt facile, grâce au fabuleux travail de l'équipe Ruby de Debian.

Emportés par notre élan, nous avons même décidé de proposer Ruby 1.9.1, ce qui s'est également révélé facile à packager, toujours grâce à Debian.

Par contre, si la version 1.8.6 marche sans problème avec les applications Rails et les gems courantes, ce n'est clairement pas le cas de Ruby 1.9.1. Nous avons du patcher le gem mysql pour qu'il daigne s'installer, et c'est pas le seul gem qui va poser problème...

Le template basé sur la version 1.9.1 est donc réservé aux amateurs n'ayant pas peur de mettre les mains dans le cambouis, mais celui utilisant Ruby 1.8.6 est d'ores et déjà fonctionnel.

L'arrivée de Lenny comme version stable de Debian étant imminente (avec les quelques mois de retard habituels), nous avons décidé de jeter un oeil aux packages de Lenny pour nous préparer à la mise à jour de notre offre d'hébergement.

Le test n'a pas été sans problèmes, car Lenny vient avec Ruby 1.8.7, version qui backporte les fonctionnalités de la branche 1.9 dans la branche 1.8 et a la réputation de « casser » pas mal d'applications (dont Rails).

Or, il se trouve que la version 1.8.7 de Ruby n'est pas compatible avec la branche 1.x de Rails, ni avec la branche 2.0.x de Rails.

Il n'y donc pas d'autre solution que de passer à Rails 2.1, mais c'est là que le problème se corse d'avantage : la plupart des applications grand public ne sont pas encore compatibles avec Rails 2.1 (y-compris Typo, le moteur de ce blog). Autre application phare du monde Rails : Redmine n'est compatible avec Rails 2.1 qu'en version de développement.

C'est pourquoi nous avons décidé de conserver notre offre d'hébergement en Debian Etch, avec un Ruby 1.8.5. Le cœur de la plate-forme étant de toute façon installé par Rubygems, il n'y a pas de problème de « vieux » packages venant de Debian Etch.

Il n'y a pas eu de mise à jour majeure depuis quelques mois, mais quelques corrections, des nouveaux testeurs et une nouveauté.

Côté correctifs :

• le support rsync a été corrigé, scp installé et de manière générale tout opération "tunnelée" via SSH devrait se dérouler sans soucis ;
• Rake et IRB sont pré-installés dans l'image de référence ;
• Les liens dans le message de bienvenue n'étaient pas à jour; bien qu'ils soient corrigés, ils ne mènent pas encore à la page de maintenance de son serveur virtuel (ça arrive!)

Côté testeurs :

• Lors du Barcamp RubyOnRails à la Cantine, ce fut l'occasion d'un MashPit et Bearstech a fourni des environnements de développement RoR "prêt à jouer" ;
• Un grand merci à Bruno Michel qui a signalé les bugs et améliorations possibles.

Côté nouveauté: un script ror-farm-image est apparu. Il permet de créer une image disque d'un système Debian identique à celui qui est utilisé sur nos serveurs. Le résultat est plus lourd puisqu'il contient un système Debian Etch et tous les services requis (cron, syslog, mysqld, lighttpd, etc).

L'intérêt est de pouvoir récupérer l'image chez soi et de jouer avec un environnement de production. Il est même possible de bootstraper son travail à la maison, puis une fois que le besoin de production se fait sentir, souscrire à notre (future) offre, et déployer votre travail avec un simple ''rsync''.

Si le coeur vous en dit, une image beta de 220 Mo est disponible. Sur une distribution Debian ou Ubuntu, vous pouvez la tester ainsi :

    wget -nv http://ror.bearstech.com/ror.img.tar.gz
    tar xzf ror.img.tar.gz
    qemu-system-x86_64 -nographic -redir tcp:8089::8080 -hda ror.img

Techniquement, il s'agit d'une image "raw" d'un disque de 1GB (fichier sparse/à trou, il n'occupe pas 1GB sur votre disque), avec une Debian Etch AMD64 configurée pour le réseau "userspace" que QEMU met en place par défaut. Il suffit de faire suivre le port 8080 pour pouvoir joindre le Lighty de votre machine virtuelle.

Hélas je doute que nous produisions une image 32bits, Bearstech s'apprêtant à mettre à la retraite sa dernière machine 32bits dans 2 semaines. Notez qu'il est tout à fait possible de lancer QEMU 64 bits sur une plateforme 32 bits (comme le fait votre serviteur sur un "vieux" Pentium M): un peu lent, mais utilisable.

Pour le futur :

• nous envisageons de baser notre template sur une distribution Debian Lenny, afin de profiter des versions 1.8.6 de Ruby et 1.5.x de Lighty ;
• nous allons avancer sur le portail d'hébergement avec notamment une synthèses de la documentation et des outils élaborés, et un formulaire d'inscription.

Cette semaine j'ai utilisé quelques heures éparses pour travailler sur un de nos outils fondateur, ror-farm-add. Il s'agit d'un script shell qui crée une machine virtuelle (vserver) prête à l'emploi pour y déposer son appli RoR.

J'en ai profité pour mettre le tout en ligne sur notre forge.

ror-farm-add a été largement "refactoré", il n'est plus basé sur 'dupvserver' qui faisait une copie mécanique de tous les fichiers du vserver template. Comme LVM s'est imposé pour la gestion de l'espace disque, j'en ai profité pour mettre en place ce shéma par vserver :

• / est un bind-mount read-only de la racine du template (conceptuellement, c'est comme un hardlink appliqué à un répertoire) ;
• /home est un filesystem stocké dans le lv /dev/vg-vservers/client.

Conséquences :

• le gros du filesystem d'un vserver est read-only, et ce n'est pas plus mal niveau sécu. Ce qui doit être customisé pour chaque vserver est déporté dans le /home. C'est ainsi que /etc et /var sont des symlinks vers /home/etc et /home/var respectivement ;
• une modif dans le template est immédiatement visible dans tous les vservers. Cela va potentiellement simplifier les maj APT et surtout garantir une homogénéité sans faille des vservers. Par contre ça ne redémarrera pas les démons comme il faut; d'un autre côté les vservers se rebootent en 2 à 3 sec: je sens que les procédures de mises à jour vont être simples et 'stateless' !
• chaque vserver ne consomme que ce qui est alloué au niveau LVM pour l'utilisateur (la tranche qu'il a payée), en particulier le système n'est pas décompté (200 à 300MB pour une Debian GNU/Linux). Au passage on n'a pas de remords à installer tout le nécessaire sur lequel on serait tenté de faire des économies: man pages, locales, etc.
• tous les vservers utilisent effectivement la même image des binaires, donc moins de conso mémoire et une meilleure utilisation du buffer cache; c'est un argument clé quand on a des environnements à 80% similaires et répliqués massivement sur un serveur (x16 chez nous) ;
• il faut 3.5sec pour obtenir un vserver tout neuf et entièrement démarré !

J'ai également revu le principe de l'identification des vservers et l'adressage sur le LAN 10/8. Désormais les IDs vservers sont choisis statiquement (ex: 'ror-add-farm myserver 5'), et l'IP automatiquement déduite selon un plan en 10.0/16. Les concepts :

• si on garde un vserver-id constant (ad vitam aeternam), on peut potentiellement le choisir universellement unique. Pour les migrations c'est très souhaitable, puisqu'on est sûr de ne provoquer aucune collision d'un root-server à l'autre. On aura un problème pour le 49151ème client, mais on verra d'ici là ;
• de même on peut garder l'IP constante. Je ne sais pas encore si c'est utile, mais ça ne coûte rien. Un /16 suffit (on prend le 10.0/16), ainsi on se réserve la possibilité de rajouter des subnets ;
• dans la même veine, je distribue les IPs en laissant des trous dans les /24, au cas où... (10.0.y.2-251). Ca permet notamment de libérer le 10.0.0.1 qui est désormais l'IP du root-server (donc la passerelle, donc le serveur MySQL, etc) ;
• sinon c'est pas compliqué - au début: le vserver 2 a l'IP 10.0.0.2, etc ! De toute façon c'est au-to-ma-tique, c'est le principal.

Et pour finir, j'ai rajouté (enfin) le support SSH. C'est en fait assez simple, mais les détails étaient pénibles. Chaque client fait un simple 'ssh client@client.ror.bearstech.com' et il arrive sur le compte 'ror' de son vserver 'client'. Il passe donc par le SSH du root server, et chaque client se retrouve  avec un compte Unix et un shell spécial qui ne fait qu'une chose: 'vserver $client exec su - ror'. La "rentrée" dans le vserver est indolore et transparente :). L'utilisateur peut naturellement utiliser les facilités de SSH dans ~/.ssh (déposer ses clés pubs, modifier sa conf client, etc). Les pièges :

• chaque compte Unix client est root, et qui plus est sur le root-vserver ! Eh oui, uid=gid=0 pour que le 'vserver exec' fonctionne. Heureusement ceci ne sert qu'à exécuter la commande triviale ci-dessus. Je me permet donc de faire l'économie d'une solution plus sophisitquée à l'aide des 'capabilities' et/ou SELinux ;
• j'ai désactivé le PrintMotd et PrintLastLog du sshd sur le root-server, il fournissait les infos du... root-server ! Pour compenser, on a un simple 'cat /etc/motd' dans ~ror/.bash_profile et même un petit message personnalisé par client ;
• j'ai désactivé le StrictModes du sshd afin qu'il accepte d'utiliser le home ~ror (uid=gid=1000) alors que l'auth se fait en root (uid=gid=0). On a des bonnes pratiques sur nos serveurs et il n'y a que le root qui peut se logger (via PKI), pas d'inquiétudes. De même pour les clients, ils n'ont qu'un compte par vserver, pas d'attaque cross-account possible (ça se dit ?).

Dernière petite note sur ror-farm-del : très pratique pour les tests, nettoie à fond un vserver et toutes ses confs afférentes (y compris le compte shell, les comptes MySQL, etc). Marche très bien sur un vserver en cours d'exécution, n'a strictement aucune pitié. Je m'en sers intensivement pour les tests, je dois en être à 200 création/destruction du même vserver. Par contre je doute qu'il serve pour autre chose que des tests, en production je préfère compter sur un ror-farm-backup et ror-farm-restore (ce qui laisse présager le ror-farm-migrate peut être aussi).

Pour la suite: nous allons travailler sur un frontend pour gérer les clients et les serveurs virtuels qu'ils achètent. Nous faisons le pari d'utiliser un Redmine à cet effet: nous avons ainsi les outils qu'il faut pour publier des infos (monitoring, facturations, etc), échanger (incidents, requêtes) et documenter (FAQ, etc). A suivre...

Au niveau des hébergements actuellement proposés, on retrouve deux grandes familles.

Hébergements généralistes

La première est la famille proposant un hébergement généraliste, avec suffisamment de contrôle sur le serveur pour pouvoir installer ce qu'on veut (et donc installer du Rails).

Cette famille demande pas mal de connaissance au niveau adminsys, et même si elle intéressante pour mettre les mains dans le cambouis, elle ne permet pas vraiment de débuter dans l'hébergement si on ne maîtrise pas son sujet. À réserver à ceux sachant ce qu'ils font, ou aux aventureux.

Hébergements spécifiques

La seconde famille est plus difficile à trouver pour Rails, il s'agit des hébergements spécifiquement pensés autour d'une technologie. On retrouve un peu de tout dans cette famille, que ce soit des dédiés avec assistance (packages préinstallés, support), des serveurs privés
virtuels ou des mutualisés, avec mise en commun d'une partie de l'architecture (serveur frontal, serveur de BDD), etc.

C'est dans cette catégorie que l'on retrouve les offres les plus intéressantes pour les gens souhaitant héberger des applications Rails en dehors de chez eux sans avoir à administrer une machine complète.  Au niveau tarification, on paie le plus souvent en fonction des capacités du système (disque, mémoire, bande passante, etc.), avec des tarifs et des offres très variables.

Ce qu'on va faire

Nous allons mettre en place un hébergement Ruby on Rails mutualisé (à base de seveurs privés virtuels) et configuré aux petits soins.

Specs techniques

Pour un compte RoR sur la plate-forme, on a :

• une tranche de serveur rien que pour soi ;
• un compte utilisateur "ror" préconfiguré, avec installation de gems en local ;
• deux bases de données (MySQL ou PostreSQL) pour le dev et la prod ;
• 480 Mo de RAM ;
• 2 Go de disque (en RAID1).

Les détails de l'architecture seront expliqués dans le post suivant, c'est assez velu.

En gros, chaque compte possède son propre lighttpd, qu'il peut configurer comme il l'entend (Mongrel, FastCGI, Webrick, ...), et Bearstech maintient un premier frontal qui fera la répartition entre les
comptes. C'est donc Bearstech qui s'occupe de faire le lien entre les noms de domaines et les comptes, ça évite les fausses manipulations et les conflits côté client.

Avantages

Pour les utilisateurs, c'est un contrôle total de l'application depuis le compte "ror" (code source, méthode de déploiement de l'appli, config du serveur frontal, config du backend, ...), sans intervention
nécessaire de notre part, même pour un changement complet de config.

D'un autre côté, Bearstech reste maître de l'hébergement, et peut administrer le frontal en s'assurant ainsi que tout cohabite sereinement, notamment au niveau des noms de domaine et des ressources
utilisées.

Bien évidemment, on proposera aussi des configurations toutes faites, pour ceux qui n'ont pas envie de tout maitriser mais simplement d'héberger une appli Rails.

On s'est dit chez Bearstech: « tiens, si on se lançait dans l'hébergement Rails ? On vend des tranches de Mongrel au kilo et on est riches ! »

Bon en fait ça s'est pas tout a fait passé comme ça. Il y a pas mal d'éléments qui nous ont poussé à se lancer dans cette aventure. On ne sait même pas encore où ça va nous mener...

On a roulé notre bosse sur RoR

On s'est fait une expertise sur RoR, à la fois côté développement et côté hébergement - qui sont nos deux spécialités. Pour le volume et la "scalabilité", [Noumba](http://noumba.net/) nous a appris beaucoup de choses. On en a profité pour publier nos informations les plus utiles:

• Bench hébergement RoR : un petit comparatif embarquant Apache, Lighttpd, Mongrel, FastCGI et la smala. Nous avons utilisé à peut près tout ceci en production, même du WEBrick en des temps mémorables.
• Installation Rails locale : une petite recette simple mais très utile pour les adminsys qui permet de manipuler de multiples environnements RoR et de les isoler, cloner, forker...
• Et bien sûr on se pointe à Paris on Rails pour assurer le minimum de veille technologiques et changer un peu d'IRC pour voir les collègues.

On fait de l'hébergement sur mesure

Nous ne nous positionnons pas sur  l'hébergement LAMP massif ou même le serveur dédié à installer et maintenir soi-même. Tous nos hébergements sont taillés sur mesure, de la petite machine virtuelle jusqu'à l'architecture multi-serveurs avec redondance, réplication, filers and co. Et surtout nous maintenons et suivons toutes nos installations, du système jusqu'à l'application. Les buzzwords sont donc: webcare, vertical, kador, humilité.

Ca tombe bien: pour héberger du Rails, il ne suffit pas d'envoyer quelques fichiers par FTP et suivre le wizard en 13 étapes; et un développeur Rails a sûrement mieux à faire que de digérer le manuel Unix de 12kg qui plie son étagère. D'ailleurs de son point de vue le shell "c'est pas agile".

On est des inconditionnels du logiciel libre

Les logiciels sont là, il n'y a plus qu'à se servir. Vous voulez un framework populaire avec un langage fun, en quelques clics vous y êtes. Mais c'est l'échange qui est le plus gratifiant.

Quand on héberge, il en ressort souvent peu de choses. Notre but va être donc multiple :

• Publier le maximum d'information sur nos méthodes d'hébergement RoR
• Diffuser et maintenir des outils pour aider à l'administration d'hébergement RoR
• Et bien sûr fournir un service aux petits onions, car même publié et diffusé, le savoir-faire ça se vend !

A suivre...

Ce blog est hébergé sur l'ébauche d'infrastructure d'hébergement RoR générique que nous sommes en train de mettre au point. Nous allons détailler par le menu nos pérégrinations et les solutions que nous allons retenir. N'hésitez pas à nous faire part de votre sentiment !