Pendant longtemps et même encore aujourd’hui, beaucoup de personnes gèrent leur petit serveur au jour le jour, sans réelle stratégie de gestion tout au long du cycle de vie de leur projet.
Avec de la chance, ces personnes ont réalisé des documentations techniques sur la préparation du petit serveur ou de leur petite infrastructure pour supporter leur projet.
Les développeurs les plus talentueux et les plus résistants, face à leur administrateur système dépassé par les évolutions, ont décidé de s’enfermer dans leur monde à l’aide de Docker, rendant hermétique la communication, réellement rompue pour le coup, entre l’administrateur système et le développeur.
Docker est utile quand il s’agit de distribuer une application gérée par un tier et étranger à votre entreprise. Sinon je pense qu’un effort doit être fait pour permettre aux administrateurs systèmes de maîtriser le cycle de vie da l’application, de son installation à son optimisation.
Un des premiers outil, utilisé à l’époque pour automatiser la configuration était CFEngine.
Puis est apparu Puppet, développé par un ancien développeur de CFEngine.
Et enfin est apparu Ansible (outil de Red Hat), qui a permis de rendre populaire la gestion de configuration, par sa simplicité de prise en main.
Puppet vs Ansible
Ansible est apparu, sans doute pour rendre l’adoption d’un gestionnaire de configuration plus accessible à une population d’administrateurs systèmes, peu habitué au développement.
De ce fait, Ansible permet aux sysadmin de faire le parallèle avec les scripts, exécutés séquentiellement.
Puppet a une autre vision, d’une méthode plutôt déclarative. La notion d’exécution séquentielle n’était pas présente au départ. Désormais, il y une notion implicite d’exécution séquentielle au sein même d’une classe d’exécution.
Au départ, Puppet était assez lent à s’exécuter et il fallait passer du temps à gérer l’ordre d’application de la configuration demandée, ce qui était compliquée.
Ansible était plus rapide. Désormais c’est l’inverse. Puppet a réussi à optimiser son fonctionnement.
Ansible et Puppet propose un dépôt communautaire de recettes de configuration. Mais le soucis est que la popularité de Ansible a aussi apporté des recettes de mauvaise qualité. Les recettes Puppet sont, en revanche, moins nombreuses, mais d’excellente qualité.
Puppet est moins limité qu’Ansible fonctionnellement. J’ai essayé Ansible en réimplantant une recette complexe et j’ai été bloqué par des manques de fonctionnalités.
Puppet a été racheté en 2022 et leur but est de populariser Puppet en tant que solution plus aboutie et non vendre l’outil lui-même. Peut-être avec plus de recettes clé en main pour déployer des infrastructures et une orientation sur le contrôle de conformité de sécurité des systèmes et applications.
Le fait d’écrire des recettes, au lieu de scripts bash ou autre, évite de se retrouver avec des scripts ou des tâches Ansible avec des noms sans aucun sens ou de se demander ce que ça peut bien faire. Il y a moins de variantes possible en fonction de qui écrit la configuration, moins de hasard, moins d’erreurs.
Puppet souffre actuellement d’un manque de popularité alors que techniquement, je sens qu’il est bien meilleur qu’Ansible. Mais il nécessite d’apprendre un nouveau language. Puppet, est lui, écrit en Ruby.
Une autre demande semble de pouvoir construire une infrastructure entière, sans doute, faire du Terraform ou remplacer kubernetes qui n’est pas autant adopté qu’on le croit.
Donc même si actuellement, sa popularité est faible, il me semble que ça devrait s’améliorer avec le temps.
J'ai adopté Puppet en 2009
J’ai commencé à apprendre Puppet pour mettre en place une force logicielle à Inria.
Au départ, les recettes ressemblaient à un gros sacs de nœuds et beaucoup de difficultés à définir l’ordre d’exécution des déclarations de ressources.
Ensuite, il y a eu un besoin de pouvoir surveiller l’application des recettes. Pour ma part, j’utilise Prometheus pour surveiller et remonter une alerte en cas de problème.
Mon interface graphique à Puppet est Foreman mais je n’utilise que très peu de fonctionnalité.
J’ai écrit des recettes pour divers services dont une pile NGINX/MySQL/(PHP ou Python).
Je l’utilise aussi pour mettre à jour la configuration de quelques serveurs utilisés dans un logiciel d’e-mailing de masse (que j’ai écrit en Django). On peut ajouter/configurer des noms de domaine pour l’e-mailing, et gérer les IPs des serveurs relais. La configuration est appliquée ensuite sur les serveurs.
Le fait de savoir que deux fois par heure, toutes mes recettes Puppet sont exécutées est rassurant. J’évite de penser qu’il puisse y avoir une dérive dans la configuration. Et toute évolution est faite dans les recettes.
C’est loin d’être parfait car ça demande du temps, mais je suis satisfait.
Je t’invite, si tu veux avoir un contrôle plus strict de la configuration de tes serveurs, à te tourner vers Puppet.
