Versionner ses playbooks Ansible avec Git (objectif RHCE EX294)

« Git (clone, add) » figure aux objectifs officiels de l'EX294. Cette page couvre le cycle complet appliqué à des playbooks : initialiser un dépôt, déclarer qui écrit, choisir ce qui entre dans le dépôt, construire un historique, puis publier vers un dépôt bare local. Aucune forge à installer, aucun compte à créer, tout tient sur la machine, ce qui correspond aux conditions d'examen.

Le sujet dépasse la certification. Un playbook versionné, c'est un playbook dont on sait qui l'a modifié, pourquoi, et vers quel état revenir.

Ce que vous allez apprendre

Initialiser un dépôt directement sur la branche main.
Déclarer une identité d'auteur locale au dépôt, sans toucher à la configuration globale.
Choisir ce qui entre dans le dépôt, et ce qui n'y entre jamais.
Construire un historique lisible plutôt qu'un commit unique.
Publier vers un dépôt bare local, et vérifier que la publication a abouti.

Prérequis

Git installé, vérifiable avec git --version.
Avoir écrit au moins un playbook, par exemple celui de Premier playbook.

Le cycle complet

Cinq gestes, dans cet ordre, suffisent à passer d'un dossier de playbooks à un dépôt publié.

Étape	Commande	Ce qu'elle produit
Initialiser	`git init -b main`	un dépôt vide sur la branche `main`
Déclarer l'auteur	`git config user.name`	une identité valable pour ce dépôt
Choisir les fichiers	`.gitignore` puis `git add`	un index qui contient le code, pas les secrets
Historiser	`git commit`	un point de retour daté et signé
Publier	`git push`	une copie sur un dépôt distant

La suite reprend ces cinq étapes, chacune avec les commandes exactes et le moyen de vérifier le résultat.

Initialiser le dépôt

Git a longtemps créé la branche master par défaut. Les dépôts modernes attendent main, et l'option -b règle la question dès l'initialisation.

# Crée le dossier playbooks/, y initialise un dépôt, et nomme la branche main
git init -b main playbooks
cd playbooks

# Vérification : la sortie doit afficher main
git branch --show-current

Sans -b, la branche dépend du réglage init.defaultBranch de la machine. Sur un poste que vous découvrez, vous ignorez ce qu'il vaut, et fixer la branche explicitement rend le geste reproductible. Sur un dépôt déjà créé en master, git branch -m master main le renomme.

Déclarer qui écrit

Chaque commit porte un nom et une adresse. Git les cherche dans la configuration, à deux niveaux, et la distinction compte dès que la machine est partagée.

# Portée globale : tout votre compte utilisateur, sur cette machine
git config --global user.name "Stephane"

# Portée locale : ce dépôt seulement, écrit dans .git/config
git config user.name "Stephane"
git config user.email "stephane@example.com"

La forme sans --global est celle à retenir en examen, en formation, ou sur un serveur mutualisé : elle attache l'identité au dépôt et ne laisse aucune trace ailleurs sur la machine. Vous pouvez relire ce que Git a enregistré :

git config --local user.name
git config --local user.email

Faites-le avant le premier commit. Si Git ne trouve aucune identité, il n'interrompt pas le travail : il en fabrique une à partir de votre nom d'utilisateur et du nom d'hôte, puis signale ce choix.

[main (root-commit) 8a0f9f4] test
 Committer: bob <bob@master1.internal>
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.

Le commit part donc avec une identité plausible mais fausse, qui restera dans l'historique.

Choisir ce qui entre dans le dépôt

Un projet Ansible mélange du code à versionner et des fichiers qui doivent rester locaux. Le tri se fait dans un fichier .gitignore, à la racine du dépôt.

# Le mot de passe du coffre, jamais le contenu chiffré
.vault_pass
*.retry

# Artefacts locaux
*.log
__pycache__/
.venv/

# Inventaire dynamique généré à l'exécution
inventory/generated_*.yml

La distinction sur Vault mérite d'être posée : le fichier chiffré se versionne, c'est précisément ce que le chiffrement permet. Seul le mot de passe qui l'ouvre reste dehors. Le sujet est traité dans la section Secrets et Vault.

Ce fichier se pose avant le premier git add, car .gitignore ne filtre que les fichiers non encore suivis. Un fichier déjà indexé continue d'être suivi malgré la règle, et il faut alors le retirer explicitement de l'index :

git rm --cached .vault_pass

Avant de committer, regardez ce que Git s'apprête à enregistrer :

git add .
git status --short

Construire l'historique

Un dépôt avec un unique commit « init » ne raconte rien. L'historique sert à répondre à « qu'est-ce qui a changé, et pourquoi », donc chaque commit regroupe une modification cohérente.

git add site.yml inventory.ini ansible.cfg
git commit -m "Ajoute le playbook de base et l'inventaire"

git add webserver.yml
git commit -m "Ajoute le playbook webserver"

Le message décrit l'intention plutôt que la mécanique. « Ajoute le rôle nginx avec template de vhost » sera utile dans six mois, « update files » non.

# Relire l'historique construit
git log --oneline

# Vérifier qu'il ne reste rien de côté : sortie vide attendue
git status --porcelain

Publier vers un dépôt bare local

Un dépôt bare ne contient que l'historique, sans copie de travail. C'est ce qu'est un serveur Git, et rien n'empêche d'en créer un dans un dossier voisin, sans réseau ni forge.

# Le dépôt qui joue le rôle de serveur
git init --bare ../playbooks.git

# On le déclare comme destination, puis on publie
git remote add origin ../playbooks.git
git push -u origin main

L'option -u associe votre branche main locale à celle du remote, ce qui permet ensuite un git push sans argument.

Pour vérifier que la publication a abouti, comparez les empreintes de part et d'autre plutôt que de vous fier au message affiché :

git rev-parse HEAD              # dernier commit local
git ls-remote origin main       # ce que le dépôt distant connaît

Les deux renvoient le même SHA quand tout s'est bien passé.

Pratiquer dans le lab

Versionner ses playbooks avec Git

$ dsoxlab run pratiques-versionner-git

Environnement : Shell·Durée : ~25 min

Validé : la sortie produite est comparée au résultat attendu.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI dsoxlab, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
git clone https://github.com/stephrobert/ansible-training.git
cd ansible-training

Lancer ce lab, puis valider votre travail :

dsoxlab run pratiques-versionner-git
dsoxlab check pratiques-versionner-git

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress.

Le challenge demande d'écrire un script solution.sh qui automatise tout le cycle dans un dossier isolé : initialisation sur main, identité locale, playbooks suivis, deux commits minimum, arbre propre, dépôt bare et publication.

Les neuf tests n'inspectent pas le texte de votre script, ce qui serait falsifiable. Ils l'exécutent, puis interrogent l'état réel du dépôt produit avec git log, git ls-files, git ls-remote et git config --local.

dsoxlab run pratiques-versionner-git
dsoxlab challenge
# ... vous écrivez challenge/solution.sh ...
dsoxlab check

Pour aller plus loin, le lab suggère d'ajouter un git tag v1.0 après le second commit, puis de cloner le bare ailleurs pour constater que l'historique est intact.

Pièges courants

Symptôme	Cause	Solution
Les commits portent une identité inconnue	Aucune identité déclarée, Git l'a déduite du nom d'hôte	`git config user.name` et `user.email` avant le premier commit
`fatal: empty ident name`	Identité déclarée mais vide	Renseigner les deux valeurs
Le commit part sur `master`	`git init` sans `-b main`	`git branch -m master main`
Un secret reste suivi malgré le `.gitignore`	Fichier déjà indexé avant la règle	`git rm --cached`, réécrire l'historique, puis changer le secret
`branch is currently checked out` au push	Destination non bare	Créer le remote avec `git init --bare`
`git status` non vide en fin de séance	Fichiers oubliés	`git add` puis `git commit`

À retenir

git init -b main fixe la branche dès le départ, indépendamment du réglage de la machine.
git config sans --global attache l'identité au seul dépôt courant, la bonne pratique sur une machine partagée.
Le .gitignore se pose avant le premier git add : il ne filtre que les fichiers non encore suivis.
Le fichier Vault chiffré se versionne, seul le mot de passe qui l'ouvre reste dehors.
Un dépôt bare joue le rôle de serveur Git en local, sans réseau ni forge.
Le même SHA entre git rev-parse HEAD et git ls-remote origin main confirme la publication.