Comment maîtriser votre infrastructure Linux Debian avec Puppet ?
Est-ce que vous gérez vos serveurs à l'aide de mémos trouvés sur Internet ?
Beaucoup de personnes installent, encore de nos jours, leurs serveurs à l’aide de petits bouts de mémos trouvés sur Internet.
Donc elles gardent précieusement l’URL du mémo dans leur bookmark.
Mais elles seraient bien incapables de reproduire le serveur exactement comme il a été installé.
Pourquoi ?
Parce que le mémo n’était de toute façon, pas écrit exactement pour le besoin initial.
Donc des packages ou de la configuration a été faite en plus du mémo.
Ces personnes ont peut-être écrit ou mis de côté leur mémo.
Mais avec le temps, l’installation du serveur finit par ne plus coïncider avec le mémo.
A partir de cet instant et sans doute dès le départ, l’installation du serveur n’est plus maîtrisée.
En cas de panne, il sera plus difficile d’intervenir, surtout si l’installation a été faite par une autre personne.
Votre serveur de prod était-il en fait le serveur de dev ? (au tout départ)
Au départ, vous avez commencé à préparer votre serveur au fil de l’eau en aspirant des infos par-ci par-là et tâtonné pour installer le serveur jusqu’à ce qu’il marche.
C’est ce qu’on devrait appeler un serveur de test ou de dev. Mais finalement, c’est devenu le serveur final.
Du coup, chaque modification peut provoquer un problème ou une panne.
Le serveur n’est pas assez maîtrisé.
Alors imaginons maintenant que la sauvegarde soit quasi-inexistante
Et oui, le serveur de prod fonctionne mais il n’y a peut-être aucune sauvegarde incrémentale. (Un simple snapshot automatique n’est pas une vraie sauvegarde).
Parce qu’en plus de réussir à mettre en ligne un serveur de prod stable, mettre une sauvegarde est compliquée.
Parfois, un espace de sauvegarde est fourni par l’hébergeur mais ça ne sert à rien. Il faut pouvoir s’en servir réellement comme stockage de sauvegarde incrémentale.
La sauvegarde doit être distante ou avoir une archive de secours distante chez un hébergeur différent.
Là aussi, c’est une étape nécessaire et je suis conscient que ça devient prise de tête quand on ne sait pas s’y prendre, quel outil choisir,…
Et si maintenant la documentation et les scripts d'installation ne faisaient qu'un ?
Finalement, plutôt que d’avoir une documentation jamais à jour par rapport à la configuration des serveurs, autant ne pas écrire de documentation.
Je suggère de ne pas mettre de méthode d’installation dans la documentation et de la garder pour le reste (schéma infrastructure,…).
L’idée est maintenant d’utiliser des scripts ou un langage qui sert également de recette d’installation.
Il y a très longtemps, il y avait un outil « cfengine », un automate pour configurer les serveurs en rapport avec un état d’installation supposé être.
Et puis un des développeurs voulaient le réécrire pour le rendre rapide, il n’a jamais pu. Enfin, si, il a quitté le projet et a fondé son propre système, nommé « Puppet ».
Depuis, d’autre outils sont aussi apparus dont un, très connu : « ansible ». De nos jours, celui-ci est plus lent à s’exécuter que Puppet. Il est très accessible car il ne nécessite pas d’apprendre le langage Puppet. Mais la contre-partie aussi, il est plus limité par moment (je n’ai plus les limites en tête, j’avais essayé de réécrire une recette Puppet avec Ansible et le niveau n’est clairement pas le même). Les modules Ansible (autre que les modules intégrés) sont de mauvaises qualité. Les modules de la forge Puppet qui sont très utiles, sont très bien écrits et maintenus.
J’utilise Puppet depuis 2004 dans une configuration « simple » (juste un seul serveur Puppet) : on peut en avoir plusieurs si l’infrastructure est énorme.
L’utilisation de Puppet pousse vers une meilleure maîtrise de son infrastructure donc, moins de hasard dans son fonctionnement, une meilleure qualité de service.
Régulièrement, un agent Puppet contrôle la configuration pour en vérifier l’état et agir si nécessaire.
Bien sûr, l’idée est de ne pas le contourner et d’écrire un maximum de configuration dans Puppet.
J'utilise également Ansible (mais pour autre chose)
Comme j’ai développé des applications Django, je me sers de Ansible pour déployer et mettre à jour une application python.
J’ai trouvé ça plus simple de faire comme ça, j’ai quelques « tâches » Ansible pour ça que je lance en tant qu’utilisateur du serveur où est installé Django.
Puppet a aussi un système équivalent (BOLT) mais je ne l’ai pas utilisé.
Avec Ansible, j’ai automatisé les mises à jour de fichier, de la base de données, le rechargement de l’application,…
Surveiller l'exécution de Puppet et recevoir des alertes
Il ne suffit pas de laisser Puppet se lancer automatiquement. Il faut le surveiller car en cas d’erreur, il ne sert plus à rien.
J’installe un serveur Prometheus qui interroge le serveur Puppet et en cas d’erreur, je reçois une alerte. Si vous avez déjà un autre système de surveillance, il faudrait adapter.
Éliminer le chaos et le hasard dans votre 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 et pouvoir en parler dans son milieu professionnel.
S’appuyer sur quelqu’un qui connaît Puppet et Linux et qui pourra vous accompagner.
J'utilise Puppet depuis 2008
J’ai commencé à apprendre Puppet lorsque j’ai mis en place la forge logicielle d’Inria (centre de recherche en Informatique). Ensuite, je m’en suis servi pour un cluster de calcul.
Je dispose de quelques recettes pour préparer la base d’un système Debian et la configuration de services NGINX, php, python.
Le reste s’écrit à l’aide des modules de la communauté Puppet, très bien écrit en général.