Introduction
L'exécution d'un playbook ne constitue qu'une partie du travail avec Ansible. Vous devez également être capable d'inspecter la sortie des tâches, de comprendre le récapitulatif (recap) et de vérifier l'état final des nœuds gérés.
Dans ce laboratoire, vous allez exécuter un playbook avec ansible-navigator, créer des fichiers gérés, relancer le playbook et inspecter les preuves que l'état souhaité est bien atteint.
Préparer la configuration du projet
Dans cette étape, vous allez créer un projet que navigator peut exécuter sans options de ligne de commande supplémentaires. La configuration est similaire à celle du laboratoire précédent, mais cette fois, le playbook gérera plusieurs fichiers.
Créez et accédez au projet.
cd /home/labex/project
mkdir -p rhce-ansible/{inventory/group_vars,playbooks,files}
cd rhce-ansible
Créez les fichiers d'inventaire et de configuration.
cat > inventory/hosts <<'EOF'
[managed]
node1 ansible_connection=local
EOF
cat > ansible.cfg <<'EOF'
[defaults]
inventory = ./inventory/hosts
retry_files_enabled = False
interpreter_python = auto_silent
EOF
L'inventaire crée un groupe managed avec un alias d'hôte local. Le fichier ansible.cfg définit cet inventaire par défaut, permettant ainsi à navigator d'exécuter le playbook depuis le répertoire du projet sans indicateurs d'inventaire supplémentaires.
cat > ansible-navigator.yml <<'EOF'
---
ansible-navigator:
mode: stdout
execution-environment:
enabled: false
playbook-artifact:
enable: false
EOF
Les paramètres de navigator maintiennent ce laboratoire orienté vers le terminal. Le mode: stdout affiche directement la sortie des tâches, l'exécution locale évite la configuration de conteneurs, et la désactivation des artefacts limite les fichiers visibles du projet à ceux que vous créez.
Créer le contenu source pour le Playbook
Dans cette étape, vous allez créer le contenu source que le playbook déploiera. Conserver les fichiers sources dans le projet permet de clarifier ce qui est sous la responsabilité d'Ansible.
Avant d'exécuter les commandes de cette étape, retournez dans le répertoire du projet afin que les chemins relatifs pointent vers le projet Ansible.
cd /home/labex/project/rhce-ansible
Créez un fichier source.
cat > files/motd.txt <<'EOF'
RHCE Ansible navigator practice host
EOF
Il s'agit du contenu source : c'est le fichier que vous souhaitez qu'Ansible déploie, et non la copie gérée finale. Séparer les fichiers sources de la sortie générée permet de voir plus facilement ce que le playbook contrôle.
Créez une variable de chemin de répertoire cible dans un fichier de variables de groupe d'inventaire. Placer ce fichier sous inventory/group_vars garantit qu'il est chargé de manière cohérente lorsque les playbooks sont stockés dans un sous-répertoire.
mkdir -p inventory/group_vars
cat > inventory/group_vars/all.yml <<'EOF'
managed_dir: /home/labex/project/rhce-ansible/managed-state
EOF
managed_dir est une variable spécifique au projet. La définir dans inventory/group_vars/all.yml permet au playbook de faire référence à un nom plutôt que de répéter le même chemin absolu dans chaque tâche.
Rédiger le Playbook de gestion d'état
Dans cette étape, vous allez rédiger un playbook qui crée un répertoire et y copie un fichier. Le module file gère les répertoires et les permissions ; le module copy déploie le contenu du fichier. Comme ce playbook se trouve dans le répertoire playbooks, le chemin source ../files/motd.txt pointe vers le répertoire files au niveau du projet.
Avant d'exécuter les commandes de cette étape, retournez dans le répertoire du projet afin que les chemins relatifs pointent vers le projet Ansible.
cd /home/labex/project/rhce-ansible
Créez playbooks/manage-state.yml.
cat > playbooks/manage-state.yml <<'EOF'
---
- name: Manage local state with navigator
hosts: managed
gather_facts: false
tasks:
- name: Create managed state directory
ansible.builtin.file:
path: "{{ managed_dir }}"
state: directory
mode: '0755'
- name: Deploy managed message
ansible.builtin.copy:
src: ../files/motd.txt
dest: "{{ managed_dir }}/motd.txt"
mode: '0644'
EOF
Lisez le playbook dans l'ordre. La première tâche garantit que le répertoire de destination existe, et la seconde tâche copie le fichier source dans ce répertoire. Les expressions {{ managed_dir }} sont remplacées par la valeur chargée depuis inventory/group_vars/all.yml.
Effectuez une vérification de syntaxe avant de modifier le système.
ansible-playbook playbooks/manage-state.yml --syntax-check
Cette vérification reste utile même si vous exécutez le playbook avec navigator. Navigator transmet le playbook à Ansible ; par conséquent, un playbook qui échoue à l'analyse syntaxique normale échouera également via navigator.
Exécuter le Playbook avec Navigator
Dans cette étape, vous allez exécuter le playbook. La ligne de récapitulatif est importante : ok compte les tâches ayant atteint l'état souhaité, changed compte les tâches ayant modifié quelque chose, et failed=0 signifie que l'exécution s'est terminée avec succès.
Avant d'exécuter les commandes de cette étape, retournez dans le répertoire du projet afin que les chemins relatifs pointent vers le projet Ansible.
cd /home/labex/project/rhce-ansible
Exécutez le playbook.
ansible-navigator run playbooks/manage-state.yml
Inspectez directement le fichier de sortie géré.
Le récapitulatif vous indique si l'exécution est terminée, mais le fichier géré prouve que l'état demandé existe. Vous devriez voir le même texte que celui que vous avez placé dans files/motd.txt.
cat managed-state/motd.txt
Relancer et inspecter l'idempotence
Dans cette étape, vous allez exécuter à nouveau le même playbook. Un playbook bien écrit doit pouvoir être répété sans risque. Si le fichier possède déjà le contenu et les permissions demandés, Ansible ne devrait pas avoir besoin de le modifier à nouveau.
Avant d'exécuter les commandes de cette étape, retournez dans le répertoire du projet afin que les chemins relatifs pointent vers le projet Ansible.
cd /home/labex/project/rhce-ansible
Exécutez le playbook une seconde fois et enregistrez la sortie.
ansible-navigator run playbooks/manage-state.yml | tee navigator-second-run.txt
Recherchez le récapitulatif. L'espacement exact peut varier, mais le récapitulatif ne devrait toujours afficher aucune erreur.
La seconde exécution concerne la répétabilité. Une exécution propre avec failed=0 prouve que le playbook peut être appliqué à nouveau sans corrompre l'état géré ; si changed=0 apparaît également, cela montre que les tâches étaient déjà satisfaites.
grep -E 'failed=0' navigator-second-run.txt
Résumé
Vous avez exécuté un playbook avec ansible-navigator, inspecté le fichier géré qu'il a créé et répété le playbook pour vérifier qu'il peut s'exécuter à nouveau proprement. Il s'agit de la boucle de base "exécuter-inspecter-vérifier" utilisée tout au long du travail d'automatisation avec Ansible.
