Depuis plus de 15 ans, je me repose au maximum sur le language Puppet pour décrire via des recettes d’installation de serveur.
TOUS les serveurs que je gère de façon régulière, sauf exception, reposent sur ce modèle de gestion.
Pourquoi utiliser Puppet ?
L’idée est de pouvoir décrire l’état d’installation d’un serveur et que ce serveur corresponde à cet état, tout au long du cycle de vie du serveur. On ne change jamais directement la configuration d’un serveur sans passer par Puppet, sauf urgence.
Puppet permet de décrire via une documentation programmable (recette) cet état.
L’application de ces recettes est répétitif par nature, contrairement à Ansible par exemple.
Le language est assez puissant pour gérer des dépendances entre les étapes d’installation.
La préparation d’une recette consiste en partie à répéter son application pour vérifier que les dépendances sont correctes dès le premier lancement.
Puppet nécessite un serveur (puppetmaster) et un client installé sur chaque serveur, qui s’exécute plusieurs fois par jour.
OpenVox est un fork de Puppet, créé en 2025, suite à un changement de licence de Puppet : les binaires de Puppet ne correspondent plus aux sources du logiciel libre du projet et limitent le nombre de client Puppet.
Je veux être sûr que la configuration système du serveur soit entièrement documentée en permanence et en tout temps.
Réduire les risques de dépendances à une seule personne
Pour éviter de déranger Gérard pendant qu’il jardine pendant sa retraite, Gérard a tout prévu.
Il a documenté toutes les installations au fil de l’eau avec Puppet et les serveurs ne reposent que sur Puppet.
Le remplaçant de Gérard comprend ce qui est installé.
Le risque humain est réduit.
Gérard est parti à la retraite et plus personne ne sait comment ça marche.
Le problème quand ça marche trop bien
Il est possible de reproduire un serveur en un temps record avec Puppet.
Par exemple, après un incendie dans un datacenter il y a quelques années, j’ai pu réinstaller un serveur en moins d’une heure, données comprises (avec la sauvegarde).
Quand ça fonctionne tout seul et qu’un désastre arrive, tout le monde est perdu.
Compléter Puppet avec une surveillance de sa bonne exécution 🚨
Pour ne pas avoir de surprise, il faut penser à surveiller la bonne exécution des recettes à l’aide d’un outil comme Prometheus et Foreman (API).
En combinant les deux, on peut surveiller la bonne exécution.
Car Puppet ne sert à rien si son exécution est en retard.
Les erreurs d’application de recettes Puppet doivent remonter à l’administration système.
🛏 Éliminer le chaos et le hasard dans ton infra et dormir tranquille
Finalement, c’est ce qu’on veut à la fin.
Avoir un fonctionnement général maîtrisé, éviter les pannes sans être obligé d’avoir une astreinte forte.
Passer plus de temps dans la préparation d’un service pour en améliorer la qualité finale.
Et obtenir le prestige d’une infrastructure système professionnel parfaite qui suit l’ambition de l’entreprise.
Des projets qui avancent… enfin.
