Puppet : configuration management Ubuntu 24.04 et manifests (hub 2026)

À la fin de cette page hub, vous saurez pourquoi Puppet reste un pilier du configuration management en 2026, comment installer Puppet 8 (primary + agents) sur Ubuntu 24.04 LTS, écrire des manifests déclaratifs (resources, classes, templates EPP, modules), comprendre l’idempotence, signer les certificats et éviter les erreurs classiques — puis enchaîner vers Hiera, Bolt et le reste du parcours DevOps du site.

Niveau : Débutant → Intermédiaire · Temps estimé : 55–75 min · Versions cibles : Puppet 8 · Ubuntu 24.04 LTS · port agent 8140 · Terraform 1.9+ (provisionnement optionnel) · Dernière vérification : 2026-09-13

Prérequis

• [ ] Une VM Ubuntu 24.04 LTS (primary) : 4 Go RAM, 2 vCPU, 20 Go disque
• [ ] Une ou plusieurs VM agents Ubuntu 24.04 (lab) avec résolution DNS / hosts vers le primary
• [ ] Accès sudo sur primary et agents
• [ ] Connectivité réseau TCP 8140 (catalog / certificats) entre agents et primary
• [ ] Notions Linux (packages, services, fichiers) — série Linux si besoin
• [ ] (Optionnel) Terraform 1.9+ pour provisionner les VMs ; Vagrant pour un lab local
• [ ] Coût estimé : 0 € en lab local / VM perso

Ce hub enrichit /puppet/ en français pédagogique SEO : architecture, install, idempotence, resources, classes, EPP, modules et FAQ — page pilier menu configuration management.

Ce que nous allons construire

Hub Puppet (menu DevOps)
  ├── Pourquoi Puppet en 2026 vs Ansible / autres outils CM
  ├── Architecture : primary, agents, catalog, facts, certificats
  ├── Install rapide Puppet 8 Ubuntu 24.04 (repo apt, puppetserver, agent)
  ├── Idempotence + premier manifest (package / service / file)
  ├── Classes, templates EPP, modules
  ├── Erreurs fréquentes (CA sign, facts, syntaxe) + FAQ (5)
  └── Carte du parcours → Ansible / Jenkins / Nagios / Terraform

(Schéma à remplacer par une image locale, alt : « Architecture Puppet : primary server, agents, catalog et facts ».)

Étape 1 — Pourquoi Puppet en 2026 (configuration management déclaratif)

Puppet est un outil de configuration management open source qui décrit l’état désiré des machines (paquets, fichiers, services, utilisateurs) dans un langage déclaratif. Le primary compile un catalog à partir des manifests ; les agents appliquent ce catalog et remontent les facts. En 2026, Puppet 8 reste pertinent pour les parcs hétérogènes, la conformité et les environnements où l’idempotence et le reporting agent-based sont critiques.

Critère	Puppet	Ansible
Modèle	Agent + primary (catalog)	Push SSH / agentless (souvent)
Style	Déclaratif (état désiré)	Procédural / playbooks YAML
Forces	Scale agent, reporting, modules Forge	Simplicité, ad-hoc, inventaire
Attention	Ops CA / primary	Drift si pas de mode récurrent
Cas typique	Drift control long terme	Automatisation rapide / CM léger

Choisir Puppet pour un état désiré centralisé et des agents périodiques. Préférer Ansible pour des playbooks push simples. Les deux coexistent souvent : Puppet pour le drift, Ansible pour le bootstrap ou les tâches one-shot (Bolt côté ad-hoc Puppet).

Étape 2 — Architecture : primary, agents, catalog, facts

Élément	Rôle
Primary (puppetserver)	Compile les catalogs, gère la CA, sert le port 8140
Agent	Collecte les facts, demande un catalog, applique les resources
Manifest / class	Code Puppet (DSL Ruby-like) décrivant l’état désiré
Catalog	Graphe de resources compilé pour un nœud
Facts	Inventaire (OS, IP, mémoire…) via Facter
Module	Paquet réutilisable (manifests, templates, files, data)
Hiera	Séparation données / code (environnements, secrets eyaml)

Flux lab : l’agent s’enregistre → le primary signe le certificat → l’agent tire un catalog → applique package/service/file → rapporte le statut. Mode agentless / puppet apply existe pour du local ; en production, le mode agent reste la norme.

Étape 3 — Installer Puppet 8 sur Ubuntu 24.04 LTS

Mettez à jour le système, puis ajoutez le dépôt officiel Puppet 8 (paquet release — pas apt-key) :

sudo apt update && sudo apt upgrade -y
sudo apt install -y curl wget ca-certificates

wget https://apt.puppet.com/puppet8-release-jammy.deb
sudo dpkg -i puppet8-release-jammy.deb
sudo apt update

Sur le primary, installez serveur + agent local :

sudo apt install -y puppetserver puppet-agent
sudo systemctl enable --now puppetserver
sudo systemctl enable --now puppet
sudo systemctl status puppetserver --no-pager

Attendu : Active: active (running). Ouvrez le pare-feu lab :

sudo ufw allow OpenSSH
sudo ufw allow 8140/tcp
sudo ufw enable
sudo ufw status

Sur chaque agent :

sudo apt install -y puppet-agent
sudo /opt/puppetlabs/bin/puppet config set server puppet-primary.example.com --section agent
sudo /opt/puppetlabs/bin/puppet config set certname agent01.example.com --section agent
sudo systemctl enable --now puppet
sudo /opt/puppetlabs/bin/puppet ssl bootstrap

Sur le primary, listez et signez les certificats en attente :

sudo /opt/puppetlabs/bin/puppetserver ca list --all
sudo /opt/puppetlabs/bin/puppetserver ca sign --all

Vérifiez un run agent : sudo /opt/puppetlabs/bin/puppet agent -t (sortie attendue : catalog applied, exit 0 si rien à changer).

Étape 4 — Idempotence et premier manifest (resources)

L’idempotence garantit qu’appliquer le même manifest N fois produit le même état sans effets de bord inutiles. Chaque resource compare l’état actuel à l’état désiré (ensure) et n’agit que si nécessaire.

Créez l’arborescence d’environnement :

sudo mkdir -p /etc/puppetlabs/code/environments/production/manifests

Exemple site.pp (nginx) :

# /etc/puppetlabs/code/environments/production/manifests/site.pp
node default {
  package { 'nginx':
    ensure => installed,
  }

  service { 'nginx':
    ensure  => running,
    enable  => true,
    require => Package['nginx'],
  }

  file { '/var/www/html/index.html':
    ensure  => file,
    content => 'Bienvenue - site gere par Puppet',
    require => Package['nginx'],
  }
}

Test local sans appliquer (noop) :

sudo /opt/puppetlabs/bin/puppet apply --noop 
  /etc/puppetlabs/code/environments/production/manifests/site.pp
sudo /opt/puppetlabs/bin/puppet parser validate 
  /etc/puppetlabs/code/environments/production/manifests/site.pp

Attendu : validation OK ; en --noop, Puppet annonce les changements sans les écrire. Relancez sans --noop puis une seconde fois : la deuxième run doit être quasi vide (idempotence).

Étape 5 — Classes, templates EPP et modules

Classes

Les classes regroupent des resources réutilisables (rôles : webserver, db, bastion) :

# manifests/webserver.pp
class webserver (
  String $server_name = $facts['networking']['fqdn'],
) {
  package { 'nginx': ensure => installed }
  service { 'nginx':
    ensure  => running,
    enable  => true,
    require => Package['nginx'],
  }
  file { '/etc/nginx/sites-available/default':
    ensure  => file,
    content => epp('webserver/vhost.epp', { 'server_name' => $server_name }),
    notify  => Service['nginx'],
  }
}

node default {
  include webserver
}

Templates EPP

Les templates EPP (Embedded Puppet) injectent des variables / facts dans des fichiers de config :

# modules/webserver/templates/vhost.epp
server {
  listen 80;
  server_name <%= $server_name %>;
  root /var/www/html;
}

Préférez EPP à ERB pour le code Puppet moderne. notify => Service['nginx'] redémarre le service uniquement si le fichier change.

Modules

Générez un squelette module (Forge-compatible) :

sudo /opt/puppetlabs/bin/puppet module generate example-webserver --skip-interview
sudo /opt/puppetlabs/bin/puppet module list

Placez manifests, templates et files dans la structure module, puis déclarez la class depuis site.pp ou via des rôles/profils. Pour les données (ports, versions, listes d’hôtes), externalisez vers Hiera plutôt que de hard-coder dans la class.

Bonnes pratiques de convergence (lab → prod)

• Versionnez les modules dans Git ; validez avec puppet parser validate et un environnement staging avant production.
• Préférez des rôles / profils (wrapper classes) plutôt qu’un site.pp monolitique de centaines de resources.
• Limitez les exec : chaque exec casse facilement l’idempotence si unless / onlyif / creates sont absents.
• Documentez le run interval agent (souvent 30 min) et surveillez les reports (échec de catalog = alerte).
• Couplez Terraform pour créer les VMs, puis laissez Puppet garantir paquets, users, sshd et services — chacun son périmètre.

Lab recommandé (45 minutes)

Objectif : un primary + un agent Ubuntu 24.04, module webserver minimal, puis preuve de drift repair.

1. Deux VMs avec DNS ou /etc/hosts vers puppet-primary.example.com (Terraform, Vagrant ou cloud).
2. puppetserver sur le primary, puppet-agent sur l’agent ; TCP 8140 ; signature CA.
3. Class webserver + template EPP en module ; include depuis site.pp pour le certname agent.
4. Deux runs puppet agent -t : la seconde doit être quasi vide (idempotence).
5. Altérez /var/www/html/index.html, relancez : Puppet répare le drift.

En cas d’échec catalog : logs puppetserver + sortie agent (DNS, CA, environment). Versionnez le module et un runbook (sign / noop / apply) pour un job CI (Jenkins).

Ce lab couvre le chemin critique primary → CA → catalog → drift. Une fois maîtrisé, branchez Hiera pour les données d’environnement et un job CI qui exécute puppet parser validate sur chaque merge request. Vous réduisez ainsi les surprises en production tout en gardant Ansible pour le bootstrap ponctuel.

Étape 6 — Erreurs fréquentes

Symptôme	Cause probable	Correction
Échec SSL / certificat	Cert non signé ou certname / server faux	puppetserver ca list puis ca sign ; vérifier DNS/hosts
Facts incomplets / agent injoignable	Hostname, firewall 8140, service down	ufw allow 8140/tcp ; systemctl status puppetserver
Erreur de syntaxe manifest	DSL invalide	puppet parser validate chemin.pp avant déploiement
Conflit de resources	Deux titles / mêmes resources divergentes	Titles uniques ; require / before / notify explicites
puppet apply OK mais agent non	Code hors environnement production	Vérifier environmentpath et chemins modules
Package release Ubuntu	Repo / codename	Paquet puppet8-release-jammy + apt update

Étape 7 — Carte du parcours configuration management

Ordre	Page	Rôle
1 (hub)	puppet (cette page)	Pilier menu : install, architecture, manifests, modules
2	Ansible	Alternative / complément agentless
3	Jenkins	CI qui peut valider / déployer du code Puppet
4	Nagios	Supervision après convergence
5	Terraform	Provisionner l’infra avant Puppet
6	Vagrant	Lab local multi-VM

Suite DevOps : Git → Terraform (VMs) → Puppet (état OS) → Docker / Kubernetes pour les workloads conteneurisés.

FAQ

1. Quelle est la différence entre puppet apply et le mode agent ?
puppet apply exécute un manifest localement sans primary. Le mode agent tire un catalog compilé par le primary (centralisation, reporting, CA). Lab : apply ; prod : agent.

2. Comment Puppet garantit-il l’idempotence ?
Chaque resource lit l’état système et n’écrit que si ensure / attributs diffèrent. Relancer le même catalog ne doit pas « casser » une machine déjà conforme.

3. Peut-on gérer Kubernetes avec Puppet ?
Oui via des modules (ex. écosystème puppetlabs) pour des aspects cluster/nœuds, mais le jour le jour K8s passe souvent par Helm / GitOps. Voir le hub Kubernetes.

4. Où stocker les secrets avec Puppet ?
Pas en clair dans Git. Utilisez Hiera eyaml, un coffre (Vault) ou des modules secrets, et limitez l’accès au primary.

5. Puppet 8 est-il compatible avec Ubuntu 24.04 LTS ?
Oui : dépôts officiels apt.puppet.com (release puppet8), packages puppetserver / puppet-agent. Préférez keyrings / paquets release modernes, jamais apt-key.

Points clés à retenir

• Puppet décrit un état désiré ; primary + agents assurent convergence et reporting.
• Install Ubuntu 24.04 : dépôt Puppet 8, puppetserver, agent, port 8140, signature CA.
• Idempotence = resource qui ne change que si nécessaire (puppet apply --noop pour prédire).
• Structurez avec classes, EPP, modules ; données dans Hiera.
• Maillage DevOps : Terraform provisionne, Puppet configure, Jenkins valide, Nagios surveille.

Tenir la route en équipe

Puppet ne remplace ni Git ni la CI : il consomme un code de configuration versionné. Traitez chaque module comme une bibliothèque : revue de merge request, puppet parser validate, tests smoke sur un agent staging, puis promotion vers production. Les profiles (rôles applicatifs) restent fins ; les données (ports, versions, listes de paquets) vivent dans Hiera pour éviter les forks de manifests.

Côté exploitation, surveillez trois signaux : échecs de catalog, dérive (ressources qui changent à chaque run), et latence de compilation sur le primary. Un primary saturé se voit avant les symptômes métier — dimensionnez JVM/puppetserver et limitez les facts inutiles. Pour le bootstrap one-shot ou les correctifs urgents hors intervalle agent, gardez Ansible ou Bolt ; pour le drift long terme sur des centaines de nœuds, Puppet reste le bon outil.

Enfin, documentez le contrat d’équipe : qui signe les certificats, quel environment est sacré, comment rollback un module (tag Git + environnement précédent). Sans ce cadre, même un hub technique parfait finit en snowflakes. Reliez ensuite supervision (Nagios) et pipelines (Jenkins) pour fermer la boucle detect → fix → converge.

En résumé opérationnel : inventaire fiable (facts), code review des modules, CA maîtrisée, et un lab de drift avant chaque release majeure. C’est ce rythme — plus que la syntaxe DSL — qui transforme Puppet en avantage durable face au configuration drift.

Pour aller plus loin

• Documentation officielle Puppet : install Linux, language reference, modules
• Hiera pour séparer données / code ; eyaml pour secrets
• Puppet Bolt pour tâches ad-hoc sans agent permanent
• Puppet Enterprise : RBAC, reporting avancé, orchestration
• Provisionner les nœuds avec Terraform puis laisser Puppet converger

Maillage série DevOps (CTA)

← Connexe	Ansible · Vagrant
→ Suite CM / CI	Jenkins · Nagios · Terraform
Aussi	Docker · Kubernetes · Git