Niveau : expert

En quelques années, le métier de sysadmin a beaucoup changé.
D'abord, grâce aux progrès de la virtualisation (si le nombre de machines physiques n'a pas forcément évolué, le nombre de machines virtuelles, lui, a explosé).
Et ensuite, grâce à son évolution logique, le Cloud Computing.

En conséquence de quoi, les utilisateurs des moyens informatiques en entreprise s'attendent à avoir un serveur en quelques minutes, contre plusieurs jours / semaines il y a dix ans.
Pire encore, encore trop peu d'entreprises qui ont migré vers le Cloud utilisent la "flexi-sécurité" qu'offre cette technologie, alors que c'est son plus grand atout : pouvoir déployer et détruire automatiquement les instances, en fonction de la charge applicative et du coût sur la place de marché EC2 d'Amazon !
Contrairement à une idée reçue, dans le Cloud, on ne paie pas ce que l'on utilise, mais ce que l'on provisionne ...

L'automatisation est donc logiquement devenue un objectif stratégique dans les entreprises qui ont un département IT interne et chez les prestataires de services spécialisés, de la même façon qu'elle a été toujours été au cœur des préoccupations pour les fournisseurs de cloud.

Au-delà d'une certaine nostalgie d'une informatique à la Papa, je pense que les nouvelles attentes sont légitimes, et même si les équipes IT ont rétréci, les nouvelles méthodologies ont au moins l'avantage d'élever les compétences de l'administrateur, et ne doivent pas être vues comme ennemies mais comme génératrices de valeur ajoutée : l'auto-déploiement, les "Software-Defined Technologies" (SDx, Networking et Storage), la gestion de configuration centralisée, ne sont pas un simple buzz commercial, mais les briques élémentaires qui permettent de construire des architectures informatiques plus efficientes, tant du point de vue économique que fonctionnel.

Dans le cadre de la modernisation d'une infrastructure existante, le plus simple est de commencer par automatiser la configuration initiale des serveurs, le déploiement de logiciels et de nouvelles configurations, ce qui permet aux équipes de se focaliser sur la gestion des vrais incidents et de libérer du temps d'installation, qu'elles pourront alors consacrer à des tâches autrement plus intéressantes intellectuellement (et professionnellement).

Il existe plusieurs outils Open Source / gratuits à cette fin, les plus connus étant Puppet, Chef, CFEngine, Ansible et SaltStack.
Je présenterai aujourd'hui l'installation de Puppet, qui est certainement le plus aisé à prendre en main, et qui convient bien aux infrastructures de taille petite et moyenne (nous parlons d'une limitation à 10000 voire 100000 machines, tout de même !)

"Resistance is futile" - les Borgs, Star Trek

Si vous n'êtes toujours pas convaincus, vous trouverez une très bonne présentation de la philosophie autour de Puppet, par Bess Sadler de l'université de Stanford ;-)
Vampires vs Werewolves: Ending the War Between Developers & Sysadmins - PuppetConf 2013

Préambule

Constat sur les méthodes de travail

Quelle que soit l'entreprise, une équipe informatique se voit confrontée à un certain nombre de problèmes récurrents, inhérents à la gestion manuelle du parc informatique :
- des difficultés à déployer des nouveaux postes / serveurs, des nouveaux services, voire à suivre la croissance de l'entreprise
- des tâches répétitives, simples (installer MRTG, par exemple) ou complexes (intégrer un nouveau serveur dans un cluster applicatif, déployer une nouvelle version d'une application qui dépend de plusieurs services), mais dans tous les cas, chronophages
- des erreurs dues à l'inattention (même avec les meilleures équipes du monde, un projet qui comporte des "charrettes" entraînera forcément des fautes, dues à la fatigue et au stress)
- des différences entre les plateformes de développement, de pré-production et de production, rendant les tests et recettages caduques; entrainant des dysfonctionnements à chaque mise en production
- des bugs récurrents, dont le temps de résolution ne diminue pas avec la répétition (parce que la fréquence est trop petite, parce qu'ils ont été traités par des personnes différentes, parce qu'ils n'ont pas été documentés)
- une absence d'historique, due à l'absence de documentation, généralement, et des interventions et changements, en particulier. Plus l'entreprise aura de vécu, plus il y aura de turnover, et plus cette absence de continuité sera problématique
- une mauvaise communication : autant un SI peut-être cohérent s'il y a un seul administrateur expérimenté et rigoureux, autant un travail en équipe entrainera forcément un "manque de synchronisation" et des tensions (les informaticiens préfèrent les modes de communications informels, un petit mot à la machine à café, des mails laconiques). En cas d'urgence, il est important de savoir exactement ce qu'a fait une personne, dans les moindres détails !
- et par conséquent, une résistance au changement, une réticence à faire évoluer le SI, plus ou moins marquée

L'automatisation permet de répondre en majeure partie à ces problèmes, puisqu'elle permet :
- de faciliter le déploiement d'un grand nombre de machines, de services
- de réduire le temps nécessaire pour les mises en production applicatives, mais aussi de revenir à un état antérieur (rollback)
- de centraliser et de rendre visibles les procédures techniques de configuration d'un système, d'un service, et de pouvoir en retracer les évolutions successives
- d'apporter de la constance, de la consistance au SI (erreurs d'attention, fautes de frappe dans une commande, interprétations différentes)

Ce que Puppet n'est pas

- Puppet n'est pas un outil d'inventaire : certes, Puppet Dashboard comporte des fonctionnalités d'inventaire, mais ne replace pas un logiciel spécialisé. Un inventaire doit être complet, et Puppet ne liste que les systèmes qu'il gère
- ni un service de distribution de logiciels : il s'appuie sur les gestionnaires déjà présents sur l'OS, par exemple Yum et Apt. Il permet, par contre, d'ajouter de nouveaux dépôts, afin de faciliter la distribution
- ni un outil de déploiement : il ne remplace pas FAI / Kickstart / Jumpstart, mais peut travailler avec eux
- ni une console réseau du type ClusterSSH : il ne permet pas d'agir interactivement avec les serveurs, l'exécution des commandes est liée à la présence de "ressources" (procédures) et du déclenchement d'événements précis. Si une tâche demande une intervention manuelle, c'est qu'elle n'entre pas dans le cadre de l'automatisation
- Puppet ne gérera pas forcément toutes les machines de votre parc (c'est même peu probable, au départ)
- ce n'est pas un logiciel "plug & play", une interface graphique trop limitante, trop contraignante; mais un framework souple et exhaustif (et vide au départ), qui vous permettra de bâtir l'automatisation de votre SI avec les procédures en vigueur dans votre entreprise, tel que vous l'entendez
- il ne vous apportera pas la méthodologie, la rigueur, le savoir-faire, les best practices. Cela, seules vos équipes pourront vous l'apporter

A quel type de professionnels s'adresse l'outil ?

L'outil s'adresse principalement aux administrateurs système, mais les administrateurs réseaux et les développeurs peuvent aussi en avoir l'usage, selon le périmètre d'action de chacun (pour automatiser la configuration des switches, par exemple; pour mettre en place et faire évoluer des environnements de pré-production, qui seront ensuite mis en production, etc).
Il n'est pas nécessaire de connaitre le langage Ruby, dont est tiré le langage propre à Puppet, mais pour bien comprendre les subtilités de la syntaxe et de l'architecture du logiciel, il est important d'avoir de bonnes bases en développement, que ça soit sur des langages généralistes, ou sur des langages de scripting.
De même, puisque l'outil automatise la configuration de systèmes et de services, les techniciens qui utiliseront au départ Puppet auront de solides bases en administration et une vision claire de l'architecture du SI.
Enfin, il faut qu'ils comprennent ce que l'outil pourra apporter à l'entreprise, mais aussi à eux, en tant que professionnels.

Pour que l'outil soit adopté et qu'il génère de la valeur ajoutée, il est donc primordial de le confier aux bonnes personnes.
Si le management fait l'économie de cette démarche de réflexion, le projet ne décollera pas, prendra la poussière, et viendra compliquer une infrastructure déjà complexe, comme c'est souvent le cas en entreprise ;-)

Pour quel type d'entreprise ?

Je dirais que l'activité n'a que peu d'importance, un administrateur peut le mettre en place dés lors qu'il a à gérer 10-20 machines.

Outre les avantages de l'automatisation, qui sont proportionnels au nombre de machines managées et directement quantifiables, j'ai tendance à croire que Puppet a des bénéfices cachés pour le SI :
- il permet de réduire les erreurs d'attention
- de documenter, sans efforts particuliers à fournir, les procédures, le savoir-faire IT de l'entreprise
- il contribue à "sortir la tête du guidon", puisqu'il impose aux équipes de rationaliser l'architecture de l'infrastructure qu'elles automatisent
- il supprime, ou diminue grandement, les efforts nécessaires pour mettre en conformité les petites incohérences, celles qu'il y a sur la TODO list, mais qui ne sont jamais suffisamment prioritaires pour qu'on les corrige (un vieux serveur jamais mis à jour, une configuration obsolète ou qui ne correspond plus aux normes de sécurité voulues par le DSI, etc)

C'est pour toutes ces raisons que j'utilise Puppet, y compris sur mon réseau personnel (une quinzaine de VMs Linux, principalement)

L'écosystème Puppet

Fonctionnalités

- Gestion centralisée de configurations
- Automatisation
- Déploiement de masse (lorsqu'il est associé avec un outil de déploiement "bare-metal" ou cloud)
- Gestion de fichiers de configuration (statiques) et de templates (dynamiques)
- Versionning
- Fournit une couche d'abstraction
- Idempotence
- Non-discombobulation

Abstraction, idempotence et non-discombobulation : des avantages de taille sur les scripting !

Les termes peuvent paraitre prétentieux, mais s'expliquent assez simplement, et à eux seuls, justifient le passage d'une infrastructure gérée par scripts à une infrastructure automatisée par Puppet.

En effet, les scripts d'installation, de post-installation, de configuration posent un certain nombre de problèmes, qui ne peuvent être résolus qu'avec énormément de temps (et d'argent) :
- ils sont difficilement maintenables et versionnables
- ils ne s'exécutent généralement qu'une seule fois, après l'installation de la machine
- ils ne sont pas conçus pour de multiples exécutions, sans effets de bord
- il est pénible de maintenir des scripts élaborés pour de multiples environnements
- lorsqu'un script plante, il est très difficile d'identifier les points qui ont échoué
- tous les points à corriger doivent l'être manuellement

Et ce sont ces défauts-là que corrige une architecture spécialisée comme Puppet.

Puppet dispose de son propre langage, déclaratif, et non pas procédural. Je dis le résultat que je veux obtenir, et non pas comment je fais pour y arriver, comme dans un script.
Cela a un avantage, l'abstraction : je déclare l'installation du paquet "mrtg" sur trois serveurs, le système calcule les actions nécessaires.
Le premier serveur est sous Debian, Puppet détermine qu'il faut utiliser le gestionnaire de paquetages Apt.
Le second est sous Fedora, Puppet détermine qu'il faut utiliser Yum.
Le troisième est sous FreeBSD, Puppet détermine qu'il faut utiliser Ports.
Il est quelquefois nécessaire de "spécialiser" les manifestes, mais c'est généralement l'affaire de quelques lignes.
Par exemple, il faut préciser que sur Fedora, le serveur web d'Apache est dans le paquet "httpd", alors que sur Debian, il est dans le paquet "apache2".
Mais rien de bien compliqué !

L'idempotence est une propriété mathématique, qui peut être résumée de la façon suivante : quelque soit x, f(f(x)) = f(x).
Autrement dit, quelque soit le nombre d'itérations successives, l'idempotence garantit qu'une opération ne sera appliquée qu'une seule fois.
Ceci est très important dans le cadre d'une installation ou d'une configuration : un paquet ne sera installé qu'une seule fois, un même fichier ne sera copié qu'une seule fois, un fichier de configuration ne sera modifié qu'une seule fois.
C'est un très grand défaut des scripts qui est corrigé là, puisqu'à moins de passer un temps inhumain (et injustifiable) sur les algorithmes d'un script, celui-ci ne sera pas apte à s'exécuter à de multiples reprises.
Une copie de fichier, au pire, échouera, parce que le fichier existe déjà; au mieux, écrasera le fichier déjà existant et prendra du temps et des ressources machine qui n'ont pas lieu d'être, surtout en production.
L'idempotence du logiciel Puppet implémente, pour chaque type d'action, l'intelligence opérationnelle que ne possède pas le script : dans le cas d'une copie de fichier, vérifier s'il existe déjà, si la version locale de la machine correspond à la version de référence, et n'effectuer la copie que si les fichiers différent.

La discombobulation est un anglicisme - je ne vois pas d'équivalent en français - qui signifie qu'une personne (ou dans le cas qui nous intéresse, une machine) est dans un état de confusion, d'incertitude à la suite d'un événement précis.
Lorsqu'un script s'exécute, certaines instructions seront exécutées avec succès, d'autres échoueront.
Le script plantera alors, sans s'exécuter jusqu'à la fin, ou continuera de s'exécuter, alors que des pré-requis ne sont pas satisfaits.
De plus, il sera très difficile d'identifier quelles étapes ont échoué, pourquoi, et la reprise sur erreur devra se faire manuellement.
Prenons le cas d'une installation de service : nous demandons à installer le package mysql-server, à configurer /etc/mysql/my.cnf, à relancer le service mysql.
Il est bien évident qu'il ne sert à rien de configurer my.cnf et encore moins de relancer le service mysql, si l'installation du package mysql-server a échoué.
C'est toute cette logique qu'intègre Puppet, il ne laisse pas le système dans un état de discombobulation.
Le logiciel permet de construire facilement des dépendances (via la propriété "require"), de répertorier les succès, les échecs, leurs raisons, et d'évaluer s'il est nécessaire de continuer.
Lorsque les échecs seront solutionnés, à la prochaine itération, seules les étapes échouées précédemment et leurs dépendances seront relancées.

Terminologie

Puppet fonctionne selon le schéma client/serveur.
Les fichiers de configuration se nomment "ressources", ou encore "manifestes". Chaque manifeste peut contenir une ou plusieurs classes.
Le serveur Puppet, aussi appelé "master", tourne sous forme de service (daemon)
Le client Puppet, aussi appelé "agent", tourne généralement sous la forme de daemon, mais peut être, dans certains cas, lancé manuellement ou périodiquement via cron.
Un ordinateur géré par Puppet est aussi appelé un "nœud" (node).
Les agents ne sont pas connectés en permanence au master, mais demandent les ressources qui les concernent à intervalle régulier.
Cet intervalle est de 30 minutes par défaut, et peut être augmenté, s'il y a beaucoup de nœuds et une infrastructure chargée; ou diminué, afin de donner l'illusion de déploiements presque immédiats, en contrepartie d'une charge accrue sur le serveur et les nœuds.

Principe de fonctionnement

1. L'agent, au début de son exécution, compile un certain nombre de "faits" (facts en anglais), qui représentent l'inventaire de base (OS, architecture i386 ou amd64 par exemple, RAM, nom d'hôte, ips, disques durs, interfaces réseau, etc)
2. Il interroge le serveur afin de demander la liste des ressources qui s'appliquent à lui
3. Le serveur fait une recherche dans le catalogue de ressources et compile celles qui concernent l'agent qui en fait la demande
4. Il renvoie les ressources correspondantes à l'agent
5. Le moteur contenu dans l'agent interprète les ressources fournies, en fonction des faits dont il dispose
6. Essaie de les appliquer
7. Retourne un rapport d'activité au master, avec la liste précise des succès, des échecs et des messages d'erreur éventuels
8. Le master stocke ces rapports
9. Toutes les communications réseau se font en HTTPS, avec des certificats qui ont été fixés à l'installation du logiciel (pour éviter les usurpations d'identité)

Structuration des fichiers

Dans le répertoire /etc/puppet se trouvent les fichiers suivants :

• auth.conf (ACL générale)
• fileserver.conf (ACL pour le serveur de fichiers)
• puppet.conf (le fichier de configuration général, avec une section [master] et une section [agent])
• le répertoire manifests, avec :
  • site.pp (fichier de définitions globales)
  • nodes.pp (fichier de définition des noeuds et des classes qui leur sont appliquées, le point d'entrée de Puppet)
• le répertoire modules, dont chaque répertoire représente lui-même un module. Chaque module contient :
  • un répertoire files, avec les fichiers statiques du module
  • un répertoire templates, avec les fichiers de gabarit dynamiques
  • un répertoire manifests :
    • qui contient au moins le fichier init.pp, point d'entrée du module qui définit une ou plusieurs classes

Une architecture modulaire et extensible

Puppet, à sa conception, a été conçu pour être entièrement modulaire.
Au fil du temps, de nombreux services ou librairies, sont venues se greffer à la base : Facter (le plugin qui inventorie les faits), PuppetDB (un back-end PostgreSQL), Puppet Dashboard (une interface graphique de reporting), The Foreman (gestion de cycle de vie et déploiement).
De même, en plus des ressources que vous mettrez en place vous-mêmes, une librairie centralisée est disponible sur https://forge.puppetlabs.com.
Vous avez la possibilité de télécharger et d'installer les modules dont vous avez besoin directement depuis la ligne de commande, à la manière de PECL (PHP) ou de CPAN (Perl).

Pré-requis matériels

- Les agents sont relativement peu gourmands (entre 40 et 120MO de RAM), mais peuvent demander des ressources CPU et des E/S importantes lorsqu'ils se connectent au master, en fonction de la complexité du catalogue compilé et des actions entreprises sur le moment
- Le serveur est quant à lui gourmand, et demande, pour les services essentiels (le Puppet-Master, PuppetDB, Dashboard) dans les 3-4 GO de RAM et un quad-core récent pour servir confortablement une cinquantaine de nodes

Maintenant que nous avons fait le tour de la théorie, nous pourrons passer à la pratique bientôt !

Partager l'article