Avancées sur les outils d'automatisation
Publié par Vincent Fri, 14 Mar 2008 16:07:00 GMT
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…