Puppet, Administration système centralisée

Puppet, Administration système centralisée

Date de publication : 29 janvier 2008

Puppet : Administration centralisée à Solutions Linux

Introduction : les conférences de Linux Solutions

Cette année, j’ai participé à ma façon au salon Solutions Linux & OpenSource pour Octopuce :

J’ai participé au jeu de conférences du 29 janvier au matin, dont le sujet était l’administration système et réseau.

Les conférences furent très intéressantes :

Un ingénieur de chez HP nous a parlé de LinuxCEO, système similiaire à FAI (Fully Automatic Install) qui permet de déployer des stations ou serveurs facilement à partir de configurations centralisées sur un serveur. Le déploiement part du principe qu’une machine est jetable et déploie automatiquement celle-ci à travers le réseau à partir de son boot.

Une autre conférence d’un senior de Bull était plus théorique, analysait la provenance, l’utilité et l’avenir des méthodes d’administrations comme ITIL ou CMM.

Ensuite, vint une conférence d’un jeune de Linagora sur l’étude comparée de systèmes SAN sous Linux pour l’accès à des niveaux d’I/O disques.

Enfin, une conférence d’un des développeurs de OCS Inventory / GLPI faisait le point sur ce produit de centralisation de l’inventaire de parc et du suivi du support informatique local.

Ma conférence, quant à elle, portait sur Puppet, logiciel client-serveur de gestion centalisée de l’administration système.

Puppet, l’administration système centralisée

Puppet est un produit tout à fait impressionnant et utile : il permet de décrire l’état de configuration d’un ensemble hétérogène de stations de travail ou serveurs et de s’assurer que l’état réel des machines correspond bien à l’état demandé.

Historiquement, l’IT se formalise par l’écriture de « bonnes pratiques », de « cahiers de procédures », l’utilisation de méthodes de type ITIL, etc.

Des problèmes arrivent dans ce monde idéal : il faut définir ces bonnes pratiques de manière cohérente et en restant proche des logiciels utilisés (ne pas trop partir dans les hautes sphères inopérantes) et il faut contrôler l’application de ces bonnes pratiques par l’ensemble des admins-sys, et le maintient de cet état de fait (contrôle régulier, comme pour les backups/restore)

Par ailleurs, les outils de l’administrateur système sont divers. Historiquement on retrouve :
- des outils hétérogènes (supervision, backups, services logiciels, graphiques d’état, etc.),
- des protocoles hétérogènes (snmp, nagios-nrpe, munin/cacti, HPOpenView, Dell OpenManage, chacun utilise son protocole de supervision),
- des plateformes hétérogènes et hiérarchies du système de fichiers diverses (/usr/local/apache sur bsd, /etc/apache sur debian, /etc/httpd sur redhat, etc.),
- mais aussi des points communs (au moins dans le monde unix) : les fichiers de configuration, le boot system V avec /etc/rc.d, les droits Posix avec chmod, etc.

Les nouveaux outils de l’administrateur système

De nouveaux outils d’admin Unix en dehors de sed grep et awk d’un côté et make/m4 de l’autre, sont apparus :

- les scripts maison : ils sont parfaits pour des usages multiples, mais ont un énorme inconvénient car ils ne sont bien souvent compréhensibles que par celui qui les a écrit ;) (voire pire, write only) ;
- les divers panneaux de contrôle web (plesk, cpanel, AlternC, etc.) : ils permettent de gérer des serveurs complets, mais imposent une bonne partie de la configuration utilisée ; ils ne répondent qu’à un besoin très précis (ici le hosting mutualisé de sites web et parfois de mail) ;
- cfengine : il permet de scripter le patchage et de contrôler l’état des services utilisés ; il est très utile pour appliquer des règles de réécriture sur les fichiers de configuration via un langage approprié ;
- FAI, PF-Tools & OpenQrm : ces scripts permettent le déploiement automatique de parcs, et considèrent (pour pftools et openqrm) chaque machine comme un élément jetable, « réinstallé à chaque boot ». Certains (OpenQrm) utilisent et conseillent puppet pour l’administration de plus bas niveau (configuration des services, et plus de l’OS/Network)

Puppet, présentation

Puppet est donc un outil de centralisation de l’administration de systèmes hétérogènes ou homogènes.

Par sa structure de langage, il fait le lien entre les bonnes pratiques, le cahier de procédures, et l’état effectif des machines.

  • Un serveur (PuppetMaster) contient la configuration commune et les points de différence entre machines / clusters & co.
  • Chaque machine, appelée noeud (node), fait tourner Puppetd, qui :
    • applique la configuration initiale pour le noeud concerné,
    • applique les nouveautés de configuration au fil du temps,
    • s’assure de manière régulière que la machine correspond bien à la config voulue.
  • La communication est assurée via des canaux chiffrés, en utilisant le protocole HTTPS de communication de ruby, et donc SSL (une mini-pki est fournie)
  • Puppetmaster sait servir
    • des recettes de configuration (recipes),
    • des fichiers,
    • des modèles (qui sont des fichiers avec des variables de remplacement),
    • des objets ruby (c’est là l’extensibilité de l’application).

- Et bien évidemment : Puppet est un logiciel libre écrit en Ruby, multiplateforme : bsd (free, macos…), linux (redhat, debian, suse…), sun (opensolaris…).

Facter : les faits sont têtus…

Facter est un outil associé à Puppet, chargé d’énumérer les paramètres locaux d’un système

- Adresse ip
- Hostname
- Distribution et version
- Toutes autres variables locales définies par l’utilisateur.

Il est disponible sur les noeuds utilisant Puppetd, il fournit des variables utilisables dans les templates Puppet.

Puppet par l’exemple

Puppet fournit un langage déclaratif simple :

- classes (permet de définir les confs de chaque service)
- héritage (permet de regrouper les confs communes)
- types d’objets particuliers (définis par Puppet, ou par des modules Ruby utilisateur)
- fonctions utilisateur
- Abonnement d’instances à d’autres instances (ex, un service est abonné à son fichier de conf, la modif de l’un entraînera le redémarrage de l’autre)

Exemples de types d’objets internes :

- File, permet de demander qu’un fichier existe, dispose de certains droits, et corresponde éventuellement à un certain contenu, fournit statiquement, ou à travers un modèle (template) avec substitution de variables
- Service, permet de déclarer un service, de s’assurer qu’il fonctionne, de le redémarrer dans certaines conditions (par exemple quand la conf est modifiée)
- Package, permet de demander l’installation, la mise à jour ou la désinstallation d’un package, en utilisant le système de packaging natif de l’OS utilisé (ports, deb, packages MacosX etc.)
- User, permet de gérer les utilisateurs unix (dans /etc/passwd) indépendemment de l’OS utilisé.

Exemple de service simple : la configuration des resolveurs DNS des machines est située dans /etc/resolv.conf

On définit une classe unique qui se charge de configurer les resolveurs :

On peut surcharger pour certains cluster situés dans un autre réseau par exemple :

Autre exemple : la configuration de l’horloge des serveurs, qui utilise ntp pour se synchroniser sur un maître :

Dernier exemple montrant la gestion des effets de bord : postfix (extrait)

Enfin, on définit des noeuds ou groupes de noeuds, qui affectent à chaque machine des classes, valeurs etc.

Conclusion

Ce que permet donc Puppet :

- Puppet permet de définir les configuration des logiciels utilisés pour tout un ensemble de machines, et permet donc **d’imposer les bonnes pratiques** (en terme de configuration et d’état des services) dans toute l’entreprise.
- Puppetd vérifie périodiquement (par défaut toutes les demi-heures) que la configuration du serveur correspond bien à ce que le Puppetmaster attend. Plus besoin donc de procédure de contrôles réguliers.

C’est donc l’outil rêvé d’une collaboration efficace entre les responsables de l’IT et les administrateurs système.

Ce que ne fait pas Puppet :

- Le déploiement automatique d’instances machines (voir PF-Tools, FAI ou OpenQrm)
- La supervision distante (type Nagios), mais il permet de configurer un Nagios pour les hôtes concernés (typiquement via un module à Puppet)

Notes

On pose généralement les recettes, templates et fichiers du puppetmaster dans un dépôt versionné (typiquement SVN) :

- Lorsque l’on commite, un script commit-hook effectue un svn update dans le dossier /etc/puppet/ et reloade puppetmaster.
- On sait qui a modifié quelle configuration, quand, et pourquoi (via le message commitlog)
- On peut revenir en arrière sur une configuration données
- On peut créer une branche de qualification que l’on teste sur un réseau de qualification indépendant, mais ressemblant de très près au réseau de production (puisque disposant de rigoureusement les mêmes règles de configuration) qui est ensuite propagé tel quel sur la production
- Le fait d’avoir principalement des configurations communes impose de discuter entre administrateurs et de s’assurer de la non nocivité d’une modification avant la propagée sur tout un backbone.

Dans le cas des packaging debian, Puppet dispose depuis peu d’un système de pre-seeding qui permet de pré-répondre aux questions posées par le package lors de son installation, et de pouvoir installer tout package automatiquement.

Le projet est dynamique et une liste de discussion entre utilisateur fourni de nombreuses réponses et permet de ne pas rester bloqué.

De nombreuses recettes sont fournies sur le site de Puppet (sur reductivelabs.com) et une documentation complète rappelle les objets principaux, les règles du langage, les bonnes pratiques en termes de recette, etc.

Adresses externes :

- Recettes Puppet chez ReductiveLabs (les auteurs de puppet)
- Recettes Puppet Chez David Schmitt
- Le site officiel de Puppet