É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.