Puppet est la solution utilisée par l'association afin de synchroniser l'état de certains éléments de son infrastructure. Avec la multiplication des machines virtuelles au sein de notre parc, il est rapidement devenu nécessaire de mettre en place une solution pour automatiser la configuration de ces machines. Cette page a pour but de détailler quelles sont les spécificités de l'installation de Puppet présente au sein de l'infrastructure d'ATILLA.

Note importante : Si vous souhaitez travailler sur ce projet vous aurez besoin de vous référer à la documentation en ligne de Puppet. Le but de cet article n'est pas de vous apprendre les différentes particularités des fonctionnalités offertes par Puppet, mais la manière dont ces différentes fonctionnalités sont mises en place au sein d'ATILLA.

• Fonctionnement général
• Mettre à jour le catalogue
• Machines de développement
• Questions - Réponses
  • Pourquoi avoir choisi Puppet ?
  • Depuis combien de temps Puppet est-il en place ?
• Glossaire

Fonctionnement général

Nous disposons d'un serveur sur lequel est installé le Puppet master, le serveur chargé de fournir un catalogue de ressources à chacun de nos agents. Le Puppet master dipose d'un répertoire dans lequel se trouve l'entièreté du code Puppet chargé de définir ces ressources pour un, plusieurs ou l'ensemble des agents du parc. Par souci de traçabilité, ce répertoire est versionné sur gitlab.atilla.org (ce projet est visible pour tous les utilisateurs authentifiés).

À chaque fois qu'un agent souhaite se synchroniser avec le Puppet master (ce qui arrive par défaut toutes les 30 minutes), il contacte donc le serveur Puppet qui se charge ensuite de compiler un catalogue spécifique à l'agent et de le lui renvoyer.

Mettre à jour le catalogue

De manière générale, modifier du code en production, ce n'est pas la meilleure des idées. Ainsi, de manière à éviter les accidents qui pourraient provoquer plus qu'une petite interruption de service, nous utilisons un processus pour le développement du code et de la configuration de Puppet semblable à tout projet informatique d'envergure. Le dépôt principal de Puppet dispose de deux branches distinctes : development et production ; sauf cas exceptionnel, le développement de nouvelles fonctionnalités ou la mise en place de nouvelles configurations s'effectue sur la branche development. Une fois le code de cette branche stable, on peut fusionner la branche avec celle de production.

Machines de développement

Comme la mise en place d'une infrastructure Puppet peut se révéler laborieuse si vous souhaitez simplement effectuer des modifications mineures à la codebase, nous disposons de deux machines virtuelles au sein de l'infrastructure vous permettant d'effectuer vos tests : puppet-master-dev et puppet-agent1-dev. Quelques points importants sont à noter concernant ces machines:

• Elles ne sont pas liées au Puppet Master en production et forment une infrastructure Puppet indépendante.
• Comme ces machines sont utilisées pour le développement de la codebase de Puppet par différentes personnes, il existe différentes configurations de git disponibles pour l'utilisateur root de la machine puppet-master-dev. Ces configurations sont gérées par update-alternatives (pourquoi pas ?).
  • Pour créer un nouveau profil git :
    • cp /root/gitconfigs/default /root/gitconfigs/<USER_NAME> : on crée une nouvelle configuration à partir de la configuration par défaut
    • vim /root/gitconfigs/<USER_NAME> : on édite la configuration en question (modification du nom, de l'email, …)
    • update-alternatives --install /root/.gitconfig gitconfig gitconfig /root/gitconfigs/<USER_NAME> 10
      : on installe la nouvelle configuration
  • Pour sélectionner une configuration de git : update-alternatives --config gitconfig
    
  • Pour retourner à la configuration par défaut : update-alternatives --auto gitconfig
    

Questions - Réponses

Pourquoi avoir choisi Puppet ?

En terme d'orchestration, plusieurs solutions FOSS existent sur le marché. On peut notamment citer Ansible, Chef ou encore Salt, qui ont toutes leurs spécificités. Pour mettre en place un logiciel d'orchestration au sein de l'infrastructure, il a bien fallu tester une solution, nous avons préféré choisir Puppet car il se trouve que l'EISTI l'utilise également dans certains endroits de son infrastructure. Cela nous permet ainsi de disposer des précieux conseils des admins EISTI si besoin est  .

Depuis combien de temps Puppet est-il en place ?

Nous avons commencé à expérimenter la mise en place de Puppet au sein de l'infrastructure à partir de février 2015 de manière à gérer les clés SSH déployées sur les serveurs.

Nous avons ensuite travaillé à la mise en place de l'outil Foreman au-dessus de Puppet au cours de l'été 2016. La mise en place de Foreman eut un succès mitigé, la machine chargée de l'hébergement de Puppet et de Foreman ne tenant pas la charge. En septembre 2017, la mise à jour de notre parc de Debian Jessie à Debian Stretch a entrainé une incompatibilité entre les agents Puppet déployées sur les machines, le serveur Puppet et le serveur Foreman. Après quelques tentatives infructueuses pour arranger les choses, nous avons choisi de supprimer Foreman, le logiciel nous causant plus de problèmes qu'il n'en solvait. Une fois Foreman retiré de l'équation, nous avons réinstallé notre serveur Puppet ainsi que ses agents de manière à repartir sur une base stable.

La dernière mise à jour de Puppet date d'avril 2021, avec la migration de Puppet 4 vers Puppet 7.

Glossaire

Voici ci-après un ensemble de termes pouvant vous être utile afin de mieux comprendre certains aspects de Puppet décris dans cette page ou ailleurs. Vous pouvez obtenir davantage d'information sur ces termes en consultant la documentation du projet.

• Agent : machine gérée par un serveur Puppet (ou Puppet master).
• Catalogue : lors de la configuration d'un nœud, l'agent Puppet utilise un document appelé «catalogue» qu'il récupère du Puppet master. Le catalogue décrit l'état souhaitable de chacune des ressources devant être orchestrée par Puppet sur le système. Le catalogue est également capable de décrire les dépendances existant entre telle ou telle ressource à orchestrer.
• Master (Puppet master) : Le serveur Puppet principal, celui contenant le catalogue utilisé par les agents.
• Ressources : représente un aspect de la configuration d'un système.