Ébauche de l'offre d'hébergement
Publié par Admin Mon, 25 Feb 2008 16:10:00 GMT
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
- accès SSH à un shell root (donc contrôle total)
- 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.
Vous noterez que la “tranche de serveur” n’est pas totalement définie, notamment les ressources CPU ne sont pas bien définies. Nous allons creuser le sujet au fil des billets.
Pour l’accès “full root via SSH”, nous penchons plus pour un accès sur un compte non privilégié. Le but est multiple: d’une part éviter de vous tirer dans le pied, d’autre part nous permettre d’assurer une mission de support qui ne vire pas au sauvetage désespéré systématique.
Nous souhaitons donner toute la latitute nécessaire pour le développeur web, donc si le compte non privilégié semble poser trop de limites, nous regarderons comment les repousser. Pour le moment nous avons de quoi vous laisser gérer l’ensemble de vos processus et configurations (de lighty jusqu’aux mongrel) sans même requérir à sudo. C’est très sécurisant et très simple à la fois.
Petite note sur la taille mémoire de 480MB: nous “provisionnons” 512MB par machine, et déduisons ce qui est globalement nécessaire (mémoire noyau, mémoire superviseur Xen si présent, structures Vserver, etc). Il s’agit d’une estimation par rapport à des configurations avec 8GB de RAM physique que nous allons utiliser.
Pour le nombre de bases, il s’agit d’une limite que nous devons instaurer puisque les serveurs MySQL et Postgres seront partagés par les utilisateurs. Cela semble classique d’avoir une base de prod et de préprod côte à côte, d’où le chiffre “2” (plutôt que 1!).
L’association des noms de domaine via le frontal géré par Bearstech vient aussi d’une contrainte simple: nous ne pouvons pas offrir une adresse IP par client, donc nous assurons le multiplexage nous-même sur une IP que nous gérons. CQFD.