GUIDE TECHNIQUE · PUPPET
Puppet : PDK : tester et déployer un module
Fiabiliser un module Puppet avant son déploiement grâce aux contrôles PDK, aux tests d'unités et à une promotion progressive entre environnements.
L’ESSENTIEL EN BREF
Les étapes clés
Ce guide présente 4 étapes, de « Fixer une politique de qualité et de version » à « Préparer la promotion entre environnements ».
Avant de commencer : Dépôt Git contenant un module Puppet et ses metadata de version.
01 · CADRAGE
Périmètre et résultat visé
Résultat attendu : PDK validate et unit passent dans les versions ciblées.
Public concerné : Développeurs Puppet, équipes plateformes et responsables des mises en production
Puppet Development Kit et outils de tests pris en charge par la version du module ; les commandes PDK varient avec le template et le contexte du projet.
Contrôlez les versions, les droits et les options disponibles dans votre environnement avant de suivre la procédure.
02 · AVANT DE COMMENCER
Prérequis et points de contrôle
- Dépôt Git contenant un module Puppet et ses metadata de version.
- PDK compatible avec la version Puppet déclarée et une chaîne CI de recette.
- Critères d'acceptation et propriétaire de déploiement identifiés.
03 · VUE D’ENSEMBLE
Comprendre l’architecture et les flux
04 · TUTORIEL
Procédure complète, étape par étape
Suivez les étapes dans l’ordre et contrôlez chaque résultat avant de poursuivre. Renseignez les paramètres adaptés à votre environnement.
ÉTAPE 1 / 4
Fixer une politique de qualité et de version
La validation est utile si son résultat conditionne réellement la fusion.
- Épingler les versions du module et des dépendances dans les fichiers adaptés.
- Définir les plateformes Puppet prises en charge et documenter les ruptures de compatibilité.
pdk --version
# Vérifier metadata.json et les versions supportéesÀ vérifier : La matrice des versions est connue avant de lancer les contrôles.
Point de vigilance : Exécuter les opérations uniquement sur un environnement de recette autorisé, sans secret ni donnée de production.
ÉTAPE 2 / 4
Exécuter les contrôles statiques
Syntaxe et style doivent être cohérents avant les essais fonctionnels.
- Lancer pdk validate dans la racine du module.
- Corriger d'abord les erreurs bloquantes ; traiter les avertissements documentés.
pdk validateÀ vérifier : Le module passe les validations applicables.
Point de vigilance : Exécuter les opérations uniquement sur un environnement de recette autorisé, sans secret ni donnée de production.
ÉTAPE 3 / 4
Écrire et jouer des tests de catalogue
Les tests portent sur les ressources attendues et les paramètres de classes.
- Créer des tests RSpec adaptés au module (catalogue compilable, fichier présent, paramètres).
- Exécuter les tests dans la combinaison de versions supportée.
pdk test unitÀ vérifier : La compilation attendue est vérifiée par des assertions de test.
Point de vigilance : Exécuter les opérations uniquement sur un environnement de recette autorisé, sans secret ni donnée de production.
ÉTAPE 4 / 4
Préparer la promotion entre environnements
Une réussite CI ne justifie pas à elle seule une diffusion sur tout le parc.
- Compiler en noop sur un petit échantillon de recette représentant les familles de nœuds.
- Comparer les différences, valider le plan de retour arrière, puis déployer progressivement via le mécanisme du parc.
# Sur un nœud de recette autorisé :
puppet agent --test --noopÀ vérifier : Un rapport de changement acceptable et un Go/NoGo explicite sont enregistrés.
Point de vigilance : Exécuter les opérations uniquement sur un environnement de recette autorisé, sans secret ni donnée de production.
RÉFÉRENCES TECHNIQUES
Documentation officielle
Retrouvez les prérequis, les fonctionnalités et les versions prises en charge par Puppet. Vérifiez les commandes sur un environnement de test avant leur utilisation en production.
05 · RECETTE
Comment vérifier que tout fonctionne ?
PDK validate et unit passent dans les versions ciblées.
Les changements noop attendus sont relus en recette.
La diffusion dispose d'une décision de Go/NoGo et d'une procédure de retour arrière.
06 · DIAGNOSTIC
Problèmes fréquents et résolution
Test d'unité en échec
Cause probable : Dépendance manquante ou comportement modifié
Que faire : Lire l'échec RSpec et mettre à jour le module ou le test de façon motivée.
Noop très différent selon les hôtes
Cause probable : Facts ou hiérarchie Hiera divergents
Que faire : Comparer les groupes de nœuds et reproduire en recette avant élargissement.
Aucune ressource en catalogue
Cause probable : Classe non déclarée ou environnement erroné
Que faire : Vérifier la classification et le Puppet environment sélectionné.
07 · QUESTIONS PRATIQUES
Questions fréquentes
PDK validate suffit-il pour publier ?
Non. Il faut compléter par tests de catalogue, recette réelle et revue des impacts.
Puppet agent --test --noop déploie-t-il ?
Non : le mode noop présente les changements prévus sans appliquer les ressources couvertes.
Qui valide le Go/NoGo ?
Le propriétaire de la mise en production selon la gouvernance de l'organisation.
AUTRES TECHNOLOGIES
Guides complémentaires
VOTRE ENVIRONNEMENT
Besoin d’aller plus loin sur votre environnement ?
Automatisation, sécurité et exploitation : échangeons sur vos pratiques Puppet.
Échanger avec ADN Consulting