Fabric : Administration distante d'un parc dynamique de serveurs/machines

1. Cas d'école

Mettons nous en situation: je suis un administrateur système, je possède un parc de 200 machines que je loue à des clients qui, pour leur écrasante majorité, développent des applications PHP qui possèdent evidemment chacune leur spécificité et besoins propres, Drupal, Wordpress, Magento, Joomla, developpement custom, impossible de prédire avec précision quel sera le module sorti de derrière les fagots que notre client souhaitera installer (et configurer) sur son serveur. Il veut son mod_machin qui embarque 2000 dépendances, et comme il va stocker moult contenu à haute teneur multimedia, il veut également un point de montage sur votre SAN prévu à cet effet, il veut également pouvoir se connecter uniquement par le biais d'un VPN pour lequel son serveur sera client et pas serveur, et j'en passe et des meilleures. Pour corser la chose, ces machines sont en production (cri d'horreur), ainsi, point de place à l'amateurisme, aux redémarrages ou autres bidouilles experimentales. Non, nous avons besoin d'une sorte de chef d'orchestre tout puissant, souple mais pas trop, qui nous permette en un coup d'automatiser des actions proprement.

Lorsqu'on démarre une activité, et en particulier une activité d'hébergement, les clients ne se bousculent pas, et on a tout le temps nécessaire pour choyer chaque serveur, mais tout le mal qu'on peut se souhaiter, c'est que cette activité se développe, et possiblement de façon exponentielle, et là, c'est le drame, et l'ont s'endort en se répétant “pourquoi je n'ai pas industrialisé, POURQUOI ??”. Car en effet, pour citer mon ami stephbul, “il faut perdre du temps pour gagner du temps”, autre tournure de la phrase bien connue “les admins c'est qu'un tas de feignasses”. Effectivement, et c'est très bien comme ça.

Ceux d'entre vous ayant lu les excellents articles sur puppet parus dans ces mêmes colonnes pensent peut-être détenir le saint Graal de l'administration, et je le pensais également. Car si puppet est un excellent outil pour maintenir un parc statique, ou disons peu mouvant, c'est une toute autre histoire pour une infrastructure d'hébergement: le client est roi, et en tant que tel, ses volontés changent chaque matin ensoleillé. Ainsi, voici les points que nous avons identifiés comme étant prérequis à l'administration de masse, dans un parc hétérogène :

- pusher des informations

- segmenter notre infrastructure en “rôles”

- ne pas utiliser de protocole particulier

- rien de particulier à installer sur les serveurs à administrer

- permettre de scripter des ajouts et modifications

- récupération des codes de retour pour post-traitement

- possibilité d'étendre l'outil de base, possiblement à l'aide d'un langage connu

- gestion fine des droits utilisateur, en particulier la possibilité de sudo afin de ne pas avoir de privilèges lorsque cela n'est pas nécessaire

Munis de ces besoins, nous avons sillonné l'intarwebz à la recherche de la perle rare, et si plusieurs candidats ont retenu notre attention, l'un d'entre eux, de par son excellente documentation et sa facilité de mise en œuvre nous a séduit quasiment instantanemment : fabric.

2. Kenessé fabric ?

À l'heure où j'ecris ces lignes (Bonne Année à tous !), la version “stable” de fabric est la 0.9.3, et la version 1.0 est en cours de développement. De nombreux blogs et autres témoignages font état de la stabilité de la solution, et votre serviteur apporte sa pierre à l'édifice.

on peut lire ceci sur la page de garde du projet[1] : (traduction libre)

Je n'aurais pas mieux dit.

Que ceux d'entre vous que l'apprentissage de Python rebute se rassurent, aucune notion de programmation n'est réellement nécessaire à la mise en place d'un système de déploiement fabric, car s'il serait évidemment plus élégant de réaliser certaines opérations par le biais du langage, rien ne nous empêche d'invoquer une commande shell pour ce faire. Mais nous verrons plus loin un exemple d'un tel cas de figure.

Démarrons notre apprentissage à l'aide d'un exemple simple; comme nous le suggère la page d'accueil du projet fabric, écrivons un module Python simplissime, aussi appelé fabfile :

Ici, nous importons de l'API fabric la seule méthode run, qui comme son nom l'indique, sert à executer une commande. Notez que l'execution de cette commande sera réalisée à l'aide de l'utilisateur qui appelle fabric si rien d'autre n'est spécifié. Nous reviendrons sur ce point plus tard. Nous déclarons ensuite une fonction à l'aide du mot clé def, cette dernière ne prend pas d'arguments. Enfin, nous appelons run avec pour seul argument la commande à executer, ici uptime. Il convient d'appeler ce module de cette façon :

La commande qui actionne tout le mécanisme fabric est fab. À cette commande, nous passons en argument :

- le fabfile à interpréter, c'est à dire le module Python qui contient les fonctions à prendre en compte

- les rôles ou bien le(s) nom(s) d'hôte(s) sur le(s)quel(s) nous allons executer notre fonction

- la fonction à executer

Important: nombre de fois, vous oublierez que c'est sur une machine distante que vous executez vos fonctions, n'oubliez pas que les commandes shell que vous invoquerez devront être présentes sur la cible ! Voici le résultat de notre invocation :

Et soudain, tout un monde de paresse s'ouvre à vous…

3. In portability we trust

Un parc est rarement homogène, que ce soit par simple envie de diversifier ses plateformes, par pur prosélytisme ou par la demande expresse d'un client, il est pas rare d'héberger d'autres Unices que GNU/Linux. En l'occurrence, notre parc est également constitué de Dead^WOpensolaris et, je vous le donne en mille, NetBSD. Voici le résultat de l'execution de notre dernier module sur une cible NetBSD :

Déception et énervement, NON Bash n'est pas présent par défaut sur tous les Unices du monde, et OUI on peut vouloir scripter de gentils outils à l'aide d'autres shells. Fort heureusement, les auteurs de fabric, s'ils ont renseigné des valeurs par défaut pour l'ensemble des paramètres impliqués dans l’exécution à distance, ont prévu d'étendre ces valeurs de plusieurs manières. La première et la plus simple consiste à renseigner un fichier de configuration, ~/.fabricrc :

Surcharge à l'issue de laquelle nous pouvons constater le bon fonctionnement de notre commande :

Cependant, si cette méthode élégante est tout à fait viable dans le cadre d'une machine centrale d'administration, il peut être tout à fait fastidieux de de notifier tous ses petits camarades de changer leur ~/.fabricrc tous les quatre matins. Afin de rendre cette opération plus industrielle, il convient de surcharger les valeurs de configuration initiales dans le fichier fabfile contenant nos differentes fonctions. En réalité, lorsque la commande fab est invoquée, elle surcharge les valeurs du module env de fabric avec celles présentes dans le fichier ~/.fabricrc. Ainsi, lorsqu'on ajoute :

C'est en réalité la valeur de env.user qui vaut désormais “pinpin”. Afin de réaliser cette opération dans le code, il suffit simplement d'ajouter l'import du module env et de spécifier la valeur du paramêtre dans notre fabfile :

Et de constater :

L'ensemble de ces variables d'environnement est bien évidemment documenté sur le site de fabric.

4. MOAR SERVARS !1!

On est mignons avec nos trois serveurs, mais nous parlions précédemment de centaines de machines. Voici à mon sens un must-have de tout système de déploiement digne de ce nom : les rôles. Fabric n'est evidemment pas le seul à embarquer ce type de notion, notons simplement sa grande souplesse et sa facilité d'utilisation. Les rôles se déclarent au niveau des variables d'environnement, tout comme nous l'avons vu précedemment pour user et shell, mais il s'agit ici non plus d'une variable simple mais d'un dictionnaire. Exemple :

Grâce à cette notion de rôles, nous pouvons regrouper sous un label l'ensemble des machines correspondant à une propriété particulière. L'exploitation des rôles en ligne de commande est extrêmement simple :

Bien évidemment, il est parfaitement possible de regrouper des machines identiques sous differents rôles, nous pourrions par exemple avoir :

De manière à découper les rôles fonction des actions à mener. Pour notre part, nous avons découpé nos rôles fonction de leur emplacement physique (datacenter), système d'exploitation, service (web, base de données, serveur SMTP…), client ainsi qu'une cible 'all' qui agit sur l'intégralité des machines du parc.

5. Une brève histoire de contexte

Autre particularité de fabric, les “Context Managers” permettent d'appliquer des propriétés particulières à un contexte d’exécution. Ces contextes se définissent à l'aide de la directive with et sont au nombre de 4 :

- cd permet de se déplacer dans un répertoire précis avant de poursuivre les opérations. Exemple :

- hide cachera les sorties souhaitées, par exemple, si l'on le désire plus voir les messages de fabric concernant les opérations en cours d'execution, on spécifiera :

- À l'inverse, show permettra de spécifier que l'on souhaite explicitement voir un type de message. Par exemple, pour afficher les messages de debug, désactivés par défaut, on inscrira :

- setting permet quand à lui de spécifier des paramètres particuliers au sein d'un contexte, et ainsi bypasser les variables d'environnement. Par exemple :

6. Fabric, un goût de paradis

Pour aller un peu plus loin dans la découverte de ce fabuleux moteur à flemme, je vous propose un petit tour d'horizon de quelques modules fort pratiques inclus dans les bibliothèques api, constituant les fonctions de base de fabric, et contrib, utilitaires tiers mais rapidement indispensables. Pour utiliser ces fonctionnalités, il vous faudra les importer, le plus simple consistant à importer tout le contenu des classes api et contrib de cette façon :

- sudo: puisque nous parlons d'administration, il va sans dire que nombre des opérations que vous serez amenés à réaliser devront l'être avec un UID autre que le votre, et très souvent l'UID 0. Fabric fournit pour cela la fonction sudo. L'utilisation est la même que pour la fonction run, par exemple

ou encore

Il va de soi que votre utilisateur a des droits correctement configurés dans le fichier sudoers de la cible.

- put et get: autre opération classique, l'envoi ou la récupération de fichier sur ou depuis un serveur. Les fonctions put et get permettent de très simplement réaliser ces actions :

et

- append: quel administrateur n'a jamais eu besoin d'ajouter une option à un fichier de configuration sur un nombre important de machines ? je ne vous crois pas. Quoi qu'il en soit, la fonction append nous fait gagner un temps considérable, jugez plutot :

- comment et uncomment: et si, et si, commenter ou décommender une ligne dans un fichier, fastidieuse tâche s'il en est :

Ici, le second argument, comme vous l'aurez probablement constaté, est une expression régulière qui servira à déterminer quelle ligne vous souhaitez commenter ou décommenter.

- contains: permet de tester si un fichier contient une chaîne de caractères, on peut optionnellement indiquer si la correspondance doit être exacte grâce à l'argument Exact=True (positionné par défaut à False) et si l'on a besoin des droits root à l'aide de l'argument use_sudo=True

- sed, comme son nom l'indique, est l'implémentation de la commande UNIX sed munie des arguments -r (expressions régulières étendues) et -i (génération d'un backup). On pourra ainsi substituer une chaîne de caractères de cette façon :

Comme pour les exemples précédents, l'argument use_sudo est optionnel. Notez que le backup généré aura l'extension .bak si l'argument backup n'est pas spécifié.

Nous n'avons vu ici que quelques-unes des fonctions fournies par l'environnement fabric, l'ensemble d'entre elles est clairement listé et explicité sur le site principal du projet dans la section “Documentation, API documentation”.

7. Mais euh, tu vas pas nous laisser comme ça hein ?

Voici pour finir un petit exemple très simple de module permettant de mettre à jour vos machines. On s’enquiert en premier lieu du système d'exploitation sur lequel nous fonctionnons, puis fonction de celui ci, commandons une mise à jour de la base de données de paquets. Si l'option do_upgrade est placée à yes via la ligne de commande, nous éxecutons une mise à jour :

Ce qui nous donne le rendu suivant :

Pour commander une mise à jour, nous aurions exécuté la commande suivante :

Car, oui, il est également possible de passer des arguments aux fonctions fabric par le biais de la ligne de commande.

Comme nous le précisions dans la première partie de cet article, un néophyte de Python pourra sans peine manipuler fabric et mettre au point ses déploiements simplement à l'aide des fonctions mises à disposition par l'API. Cependant, avec un investissement minimal dans ce langage d'une grande simplicité, on sera très rapidement en mesure d'effectuer manipulations et calculs bien plus rapidement. Pensez-y, s'il est tout à fait aisé et réalisable de se fendre d'un grep|sort|uniq|sed, ne serait-il pas plus élégant de tirer parti des fonctions de manipulation de chaîne du langage lorsque celles-ci sont réellement abordables [2] ?

8. Les oiseaux se cachent pour mourir

Au sein de l'entreprise dans laquelle je travaille[3], la découverte de cet outil a considérablement modifié nos méthodes de déploiement et d'administration, car si les divers systèmes de bootstrapping de nos différents Unices (preseed Debian, kickstart RedHat, jumpstart Solaris…) simplifient l'installation initiale, ils n'adressent pas la capillarité d'un parc hébergeant pratiquement autant de machines que de clients. La possibilité de manipuler 200 machines en une commande, et par le biais d'un système maintenu, fiable et ouvert, donne une toute autre envergure au métier d'administrateur. À l'époque du Cloud Computing, donc des machines virtuelles jetables, où un client est en mesure de vous demander une augmentation de plateforme de 200% du jour au lendemain, cette approche est non seulement salvatrice, mais aussi gratifiante. L'administration système prend un nouveau tournant, on manipule son parc comme un programme informatique, des unités de calcul virtuelles, et cet art prend des tournures macroscopique.

Liens

[1] http://docs.fabfile.org/0.9.3/

[2] http://docs.python.org/library/string.html

[3] http://www.nbs-system.com