Depuis plus de 15 ans, je me repose au maximum sur le language Puppet pour décrire via des recettes, l’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.
Es-tu certain de comprendre la configuration actuelle de tes serveurs ?
As-tu l’esprit tranquille de savoir que tout peut s’arrêter du jour au lendemain ?
📜 Tu gères tes serveurs à l’aide de mémos ?
Tu as des petites notes sur la configuration utilisée par tes serveurs.
Tu les as préparées au tout début, lors de l’installation initiale du serveur.
Mais avec le temps, tu as commencé à changer la configuration sur les serveurs en essayant, plus ou moins, de mettre à jour le mémo.
C’est là que ça commence à dériver, un mémo qui n’est déjà plus exact. Et au fil du temps, le mémo ne sera plus qu’un document périmé.
Au delà du problème d’obsolescence du mémo, réinstaller un serveur ou autre identique prend plus de temps et on n’est jamais certain de ne pas manquer une étape.
L’installation du serveur n’est plus maîtrisée.
🚧 Ton serveur de prod était-il en fait le serveur de dev ? (au tout départ)
Au départ, on commence par préparer un serveur afin de tester un service ou de chercher la bonne configuration (plus rapide que d’utiliser Puppet ou autre). Puis finalement, le serveur de dev se retrouve promu serveur de prod.
Et cette situation dure depuis longtemps (années ?), le système n’est peut-être plus à jour, une vieille Debian obsolète ?
Chaque moindre changement dans la configuration peut aboutir plus facilement à une panne.
👉 Puppet
L’idée de Puppet 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 clients 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.