Puppet, outil de gestion de configurations – Partie 1

 

puppetlabs.com

PuppetLabs, maison d’édition de Puppet

Bonjour à tous,

Voici mon premier billet sur Puppet. Ca fait deux ans que je travail dessus au taf, je l’ai mis en place sur 200 machines et j’ai également fais mon mémoire de Master 2 dessus.

Ce premier billet va être extrêmement théorique : il n’y aura pas de pratique/installation/optimisation/jesaispasquoi.

 

Tout d’abord, Puppet est un outil de gestion de configurations. La gestion de conf est un des processus ITILv3  :

 » un système de gestion des configurations est un ensemble d’outils et de bases de données utilisé pour la gestion des données de configuration d’un fournisseur de services informatiques. Il inclut également des informations relatives à d’autres points (incidents, problèmes, erreurs connues, changements et versions) et peut contenir des données portant sur les employés, les fournisseurs, les sites, les succursales, les clients et les utilisateurs. Le système de gestion des configurations offre également des outils chargés de collecter, de stocker, de gérer, de mettre à jour et de présenter les données relatives à tous les éléments de configuration et à leurs relations. Il est géré par le processus de gestion des configurations et est utilisé par l’ensemble des processus de gestion des services informatiques. « 

Puppet est le logiciel qui répond à ce processus. On orchestre et organise tout le parc autour d’un seul outil.

On retrouve, comme pour toutes les gestions de configurations, un client et un serveur. Le serveur est une CMDB (principe ITILv3), c’est là que sont agrégées toutes les données de l’outil. On a donc un serveur qui connait toutes les « configurations » du parc et les clients (des « nodes ») qui s’y connectent pour charger ces configurations.

 

Les configurations décrivent ce qu’on doit faire sur une machine :

  • copie de fichiers depuis des sources différentes,
  • édition de fichier avec remplacement d’un motif par une variable,
  • création de variables récupérées par le logiciel client,
  • fonctions algorithmiques dans les configurations (boucles, cas, conditions),
  • installation de logiciels depuis un binaire renseigné ou depuis un dépôt,
  • création d’une arborescence,
  • synchronisation d’un dossier depuis le serveur,
  • montage automatique d’un dossier réseau,
  • copie d’une clé ssh publique pour une liste d’utilisateurs,
  • lancement d’un démon s’il n’est pas actif et vérification de sa programmation au démarrage,
  • relancement de ce démon si son fichier de configuration est modifié,
  • création d’un utilisateur système et ajout dans des groupes spécifiques,
  • définition d’un ordre spécifique entre les points ci-dessus,
  • etc.

En gros, tout ce qu’on peut faire via ligne de commande sur une machine est faisable via Puppet, donc automatisable. Puppet étant écrit en Ruby, c’est compatible avec la grande majorité des OS (Linux, MAC, Windows), même si certaines fonctions ne sont pas disponibles sur des OS un peu underground.

Puppet, comme CFEngine l’outil historique, a un langage propre qu’il est indispensable de maîtriser pour faire quoi que ce soit. C’est un langage déclaratif, on défini des ressources et on dit ensuite ce qu’on fait de celles-ci. Les ressources sont un fichier, un point de montage, un paquet, etc.

Pour aller dans des détails de fonctionnement, le client Puppet se connecte au serveur pour récupérer sa conf. Il lui envoie au passage toutes les infos sur la machine (les « facts ») : hostname, IPs, taille des disques, quantité de RAM, etc. On peut bien entendu créer ses propres facts en Ruby.  Une fois connecté au serveur avec toutes ces infos, ce dernier compile le catalogue du client. Le catalogue est l’ensemble des configurations qui doivent s’appliquer au client et qu’on a explicitement stipulé dans un fichier. Je reviendrai sur l’arborescence de Puppet dans un second billet. Le serveur renvoie ce catalogue au client qui l’exécute en local. Le client renvoie finalement le rapport d’exécution au serveur, dans lequel on sait pour chaque point si ça s’est bien ou mal passé.

 

Exemple concret d’un serveur Apache sous Linux :

Sur le serveur Puppet, je crée ma configuration dans laquelle je dis que je veux le paquet Apache, mon fichier de vhost, l’ouverture du port 80 dans IP(6)Tables, et l’arborescence de mon site qui est un montage NFS. Comme l’ordre est important, je veux que ces actions soient effectuées dans cet ordre précis. Je vais même demander à Puppet qu’il active le vhost que je viens de coller et qu’il reload Apache. Et bien voila, grâce à Puppet, tout ça est fait en moins de 40secondes, et mon site est en ligne. J’ai 300 autres serveurs à mettre en prod’ ? Rien à changer si ce n’est déclarer à Puppet que ces serveurs devront avoir la conf Apache.

Sous Puppet, une configuration qui définie un logiciel est un module. Typiquement ici, on a un module Apache qui va copier les fichiers et installer les paquets, mais on aura également un module IPTables, pour ouvrir le pare-feu.

 

« En fait Puppet, ça sert à déployer en gros ? »

C’est le deuxième gros point de Puppet et des outils de gestion de configurations en général : ce ne sont pas des outils de déploiement !!

Puppet est fait pour tourner toutes les 30minutes. Donc toutes les 30mns, il va vérifier que notre paquet apache est bien installé, que le fichier de vhost est bien présent et qu’il est le même que sur le serveur, que le port 80 est bien ouvert, etc. Il va essayer de réappliquer entièrement sa conf à chaque exécution.

A l’inverse, un outil de déploiement, comme Ansible ou Capistrano par exemple, va faire que du « one-shot ». J’ai une modif à faire, c’est Ansible qui va la faire pour moi. Je peux faire 50modifs complètement contradictoires sur mon parc, elles seront faites sans poser de question. Par contre, une fois que j’ai finis ma modif, le serveur n’est plus administré : tout peut être écrasé, modifié, ce n’est plus l’outil de déploiement qui gère. La gestion de configurations va justement toujours remettre le serveur dans l’état défini par l’admin. Le serveur est donc administré par l’outil. C’est aussi pour ça qu’on appelle la gestion de configurations de « l’admin centralisée » ou « administration système centralisée ». On ne fait pas juste des modifs ciblées sur notre parc, on le gère entièrement par l’outil, quitte à ne plus rien faire à la main.

L’avantage de gérer toute la configuration, c’est la cohérence : même si je rajoute 50modules à mon serveur, je ne peux pas dire à un endroit  que j’ajoute un paquet et à un autre que je le supprime. Vous gérez toute la conf de votre machine, tous les changements depuis l’installation de l’OS. On peut donc par erreur supprimer un fichier, un paquet, Puppet remettra la machine dans le droit chemin.

C’est donc super puissant, surtout si vous n’êtes pas seul à travailler sur cette machine ! Vous êtes certain que ce que vous faites ne pourrira pas la configuration de vos collègues.  Dans la pratique c’est vérifié, vu que Puppet ne compilera pas s’il y a une incohérence dans la conf, le client ne fera donc aucune manip. Ce que j’ai également observé c’est que le premier lancement du client peut être très long, jusqu’à 2mn pour les config les plus poussées, mais que s’il n’y a pas eût de modification sur le serveur, chaque exécution se fait en 4-8secondes. Puppet n’est donc pas un outil de déploiement, mais un gestionnaire de configurations.

 

« Je suis seul admin sur un parc de 20machines, c’est utile ? »

Oui s’il y a beaucoup de similitudes dans les machines : les mêmes scripts de sauvegarde, le .bashrc modifié, les 5-6 paquets indispensables que vous ajoutez après chaque installe, la configuration du mail en ligne de commande, etc. L’étape à laquelle les admins arrivent très vite, c’est un petit script maison qui fait ces modifs, qui les fait vite et bien. Le problème du script est que plus le parc grossit et devient hétérogène, moins c’est maintenable, surtout s’il y a plusieurs admins. Ensuite, les scripts ne sont qu’une post-installe, toutes les modifications que vous ferez à posteriori sont à faire à la main ! Après je ne vous le cache pas, écrire ses configurations, que ce soit avec Puppet ou un autre, ça prend du temps. J’ai estimé, pour un admin qui connait déjà la conf qu’il veut automatiser, à 1 journée minimum par module. Il y a toujours des modules communs mais en plus, chaque nouveau service sur une machine nécessite son propre module. Pour automatiser 100 serveurs CentOS en prod, ça m’a pris presque 6 mois de travail, en parallèle du reste. Et ça, juste pour écrire les confs de mes serveurs, l’infra Puppet était déjà opérationnelle…

NB : à l’origine, Puppet est fait pour tourner sur une seule machine, donc on peut l’installer même pour un seul serveur.

 

« On est plusieurs admins dans mon équipe, c’est possible ? »

En fait les outils de gestion de configurations sont fait pour un travail collaboratif. Comme je l’ai dis, on ne peut pas avoir de configurations contradictoires, on a qu’une seule configuration cohérente. De ce fait, c’est beaucoup plus facile de travailler en équipe, on ne peut pas pourrir les conf de nos collègues. Enfin si on peut toujours en cherchant bien, mais faut être tordu. Le « problème » des outils de gestion de confs, c’est qu’on ne peut plus bidouiller des trucs à la main. L’outil de gestion de conf  est garant de la conf du parc. C’est bizarre et dangereux de gérer qu’une partie de sa conf avec cet outil, ça détruit toute la cohérence. On va pas copier et exécuter un script à la main et gérer le reste de la conf avec Puppet. Ce que j’ai observé à mon travail, c’est qu’on se sert alors de la gestion de conf pour savoir ce qui est fait sur un serveur. Lire le catalogue permet d’avoir toutes les infos sur ce que les admins ont fait. On ne regarde plus d’un œil discret dans l’historique de commandes … qui est souvent incomplet qui plus est. C’est aussi l’avantage d’avoir les données agrégées au même endroit : tout le monde modifie une seule chose commune. On sait que notre travail et celui des autres, tout ce qui peut nous impacter, est à cet endroit là. La sauvegarde du savoir faire de l’équipe est donc plus facile à sauvegarder et quantifier !

Un outil de gestion de configurations est donc un outil collaboratif, mais également fédérateur. Vu qu’on ne peut plus faire ses bidouilles dans son coin, faut communiquer avec ses collègues pour être sur qu’on ne va pas faire n’importe quoi. Ca permet également de mieux savoir ce qu’ils font et comment ils le font : s’intéresser à leur travail. Finalement, vu que c’est un outil central dans l’admin, ça donne un socle commun à des compétences parfois très diverses.

 

Pour conclure ce premier billet théorique, Puppet est un outil très puissant qui permet d’automatiser tout un parc informatique, qu’il soit hétérogène ou avec des environnements différents : dev, prod, test, qualif, etc. On peut quasiment tout faire avec, ce qui peut aussi en faire une usine à gaz … L’important est que tout le monde travail avec pour ne pas qu’il y ait de conflit de configurations et qu’on soit capable de retrouver rapidement ce qui est fait ou non sur une machine. Puppet aujourd’hui s’est imposé comme le numéro 1 alors qu’il a été créé en 2005. CFEngine, l’outil historique date de 1992 et est de moins en moins utilisé car vraiment très complexe : la syntaxe n’est pas user-friendly pour un sous. Deux autres outils commencent à s’imposer : Chef et Saltstack.

Chef, car c’est un mix entre Puppet et CFEngine, mais surtout car la syntaxe n’est pas propriétaire mais du vrai Ruby. Saltstack lui pour deux grandes raisons : c’est un outil de déploiement ET un outil de gestion de configurations : on peut faire un push sur des machines et en même temps on a un socle de configurations qui sont récupérés en pull. La deuxième raison est la grande simplicité annoncée du logicielle et semble-t’il validée par les utilisateurs. Je ne l’ai pas testé, je peux pas dire. Des trois autres logiciels, c’est certain que Puppet est de loin le plus facile à prendre en main pour gérer des configurations moyennement compliquées. Dès qu’on devra directement parler avec une API ou quoi, Chef saura s’imposer. CFEngine lui … RIP

 

Vincent

4 thoughts on “Puppet, outil de gestion de configurations – Partie 1”

  1. Arnaudm dit :

    Nice article, thx!

  2. Aurélien dit :

    Bonjour,
    Je serai intéresser pour lire votre mémoire es-ce possible ?

    1. N.i.c.O dit :

      Alors, juste comme ça en passant. Maintenant que Ansible a été racheté par Redhat, je vous recommande plutôt cette solution qui profite de la communauté la plus importante aujourd’hui. Elle gère en plus les dernière techno tel que Docker / openstack etc… Et surtout elle est agentless et ne demande q’un accès SSH.

  3. Theo Poccard dit :

    Bonjour,

    Je serai également très intéressée de voir votre mémoire sur Puppet. Est il possible de le consulter ?

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *