Puppet

De wiki.nexiat.fr
Aller à la navigation Aller à la recherche
Fiche express
Type Outil de gestion de configuration (IaC déclaratif)
Contexte Décrit l'état cible des machines (paquets, fichiers, services) en DSL Ruby ; un agent applique périodiquement cet état
Éditeur Puppet, Inc. — racheté par Perforce en 2022 (à vérifier selon la période)
Distributions Open Source · Enterprise
Voir aussi Puppet client · Puppet forge · Puppet-dashboard · Ansible · SaltStack

Puppet est un outil de gestion de configuration déclarative : on décrit dans des manifestes (fichiers .pp) l'état voulu d'une machine (paquets installés, contenu de fichiers, services démarrés...), et un agent installé sur chaque nœud interroge périodiquement un serveur central (le master) pour récupérer et appliquer cette configuration. C'est l'un des outils historiques de l'Infrastructure as Code, aux côtés d'Ansible, SaltStack et Chef.

Cette page sert de hub vers les autres fiches Puppet du wiki ; voir la section Pages liées ci-dessous pour l'installation, le module Forge, l'ENC, etc.

Architecture

Deux modes de fonctionnement principaux :

  • Agent / master : les agents interrogent périodiquement (par défaut toutes les 30 minutes) le master via une API HTTPS sur le port TCP 8140 pour récupérer leur catalogue compilé et l'appliquer localement.
  • Serverless (puppet apply) : le manifeste est appliqué en local, sans master, utile pour du test ou des architectures sans agent (via Ansible/orchestrateur externe par exemple).

L'ancien mécanisme puppet kick (déclenchement à distance d'un run agent, aujourd'hui obsolète) utilisait le port TCP 8139 côté agent — à ne pas confondre avec le port 8140 du master.

Voir aussi la fiche Puppet-dashboard pour le rôle d'ENC (External Node Classifier), qui détermine quelles classes s'appliquent à quel nœud.

Installation

Voir Puppet install (procédure générique), Puppet opensource (version communautaire) et Puppet enterprise (distribution commerciale avec console web). Pour le déploiement de l'agent sur un nœud, voir Puppet client (paquets historiques, Puppet 3.x et antérieur) et Puppet client 4 (agent tout-en-un puppet-agent, Puppet 4 et suivants).

Commandes usuelles

Génération et application de manifestes

Générer un manifeste à partir de l'état actuel d'une ressource (utile pour partir d'un existant) :

puppet resource user root > root.pp

Appliquer un manifeste localement :

puppet apply root.pp

Mode simulation (dry-run), sans rien modifier réellement :

puppet apply root.pp --noop

Appliquer uniquement les ressources taguées avec un module donné :

puppet agent -t --tags module_name

Configuration

Afficher la valeur d'un paramètre de configuration (syntaxe moderne) :

puppet config print <config>

Trouver le répertoire de configuration :

puppet agent --configprint confdir

Afficher le modulepath (ancienne syntaxe, encore rencontrée sur les installations historiques) :

puppet master --configprint modulepath

Récupérer le chemin des facts personnalisés, puis forcer une resynchronisation des plugins :

puppet agent --configprint factpath | awk '{ print $1 }'
puppet agent --pluginsync

Note : puppet doc --reference configuration permettait de générer une page de référence de la configuration sur les versions anciennes (Puppet 2.x/3.x) ; cette sous-commande a été retirée en Puppet 4+. Utiliser désormais puppet config print --section all ou la documentation officielle.

Modules (Forge)

Voir Puppet forge pour le détail. En résumé :

puppet module install puppetlabs-apache
puppet module uninstall puppetlabs-apache
puppet module list --tree

Pages liées

Voir aussi

  • Ansible — alternative sans agent (SSH), approche impérative/déclarative hybride
  • SaltStack — alternative avec master, protocole ZeroMQ
  • Chef — alternative en Ruby DSL, également agent/master
  • Foreman — peut servir de console/ENC pour Puppet, avec provisioning intégré
  • Hiera — hiérarchie de données externalisées, intégrée à Puppet depuis la version 3
  • Augeas — outil d'édition de fichiers de config, embarqué dans Puppet (module augeas)