Dépannage des Playbooks et Hôtes Ansible sur RHEL

Introduction

Dans ce laboratoire, vous apprendrez à dépanner les problèmes courants rencontrés lors de l'utilisation d'Ansible sur Red Hat Enterprise Linux. Vous acquerrez une expérience pratique dans l'identification et la résolution d'une variété de problèmes, de la configuration initiale de l'environnement aux erreurs courantes de playbooks et aux problèmes de connectivité des hôtes gérés. Les exercices couvrent la correction de la syntaxe YAML, la correction des erreurs de templating Jinja2 et le diagnostic des problèmes sur les systèmes distants.

Vous commencerez par préparer un environnement RHEL et configurer Ansible pour une journalisation efficace. Ensuite, vous plongerez dans des scénarios de dépannage pratiques, en utilisant le mode de vérification (check mode) d'Ansible pour diagnostiquer les problèmes liés aux services et en corrigeant les configurations de pare-feu pour résoudre l'inaccessibilité des hôtes. À la fin de ce laboratoire, vous disposerez d'un ensemble complet de compétences pour maintenir des flux de travail d'automatisation Ansible robustes.

Préparer l'environnement RHEL et configurer la journalisation Ansible

Dans cette étape, vous préparerez votre environnement Red Hat Enterprise Linux pour l'automatisation Ansible. Cela implique l'installation du logiciel nécessaire, la création d'un répertoire de projet dédié et la configuration d'un fichier de configuration de base pour contrôler le comportement d'Ansible et activer la journalisation. Une configuration adéquate est la première étape vers une automatisation et un dépannage efficaces.

1. Installation d'Ansible

   Tout d'abord, vous devez installer Ansible. Le moteur d'automatisation principal est fourni par le package ansible-core. Utilisez le gestionnaire de paquets dnf avec sudo pour l'installer. Le drapeau -y répond automatiquement "oui" à toute invite de confirmation.

   sudo dnf install -y ansible-core
   

   Vous devriez voir une sortie indiquant que le package est en cours d'installation avec ses dépendances.

   Last metadata expiration check: ...
   Dependencies resolved.
   ================================================================================
    Package             Architecture   Version                Repository      Size
   ================================================================================
   Installing:
    ansible-core        x86_64         <version>              <repo>          2.8 M
   ...
   Transaction Summary
   ================================================================================
   Install  XX Packages
   
   Total download size: XX M
   Installed size: XX M
   ...
   Complete!
   

2. Création d'un répertoire de projet

   Il est recommandé d'organiser vos projets Ansible dans des répertoires dédiés. Cela permet de séparer proprement vos playbooks, votre inventaire et vos fichiers de configuration. Créons un répertoire nommé ansible_troubleshooting dans votre dossier de projet personnel et naviguons à l'intérieur.

   mkdir -p ~/project/ansible_troubleshooting
   cd ~/project/ansible_troubleshooting
   

   Désormais, toutes les commandes de ce laboratoire seront exécutées depuis le répertoire ~/project/ansible_troubleshooting.

3. Création d'un fichier d'inventaire Ansible

   Un inventaire est un fichier qui liste les hôtes (ou nœuds) qu'Ansible gérera. Comme vous travaillez sur une seule VM LabEx, vous configurerez Ansible pour gérer la machine locale elle-même.

   Créez un fichier nommé inventory et ajoutez-y localhost. La partie ansible_connection=local indique à Ansible d'exécuter les commandes directement sur le nœud de contrôle (votre VM) sans utiliser SSH.

   echo "localhost ansible_connection=local" > inventory
   

   Vous pouvez vérifier le contenu du fichier en utilisant la commande cat :

   cat inventory
   

   Sortie attendue :

   localhost ansible_connection=local
   

4. Configuration de la journalisation Ansible

   Un fichier ansible.cfg vous permet de personnaliser le comportement d'Ansible pour un projet spécifique. Lorsqu'il est placé dans le répertoire du projet, ses paramètres remplacent les valeurs par défaut du système. Ici, vous créerez ce fichier pour spécifier l'emplacement de votre inventaire et activer la journalisation. La journalisation est cruciale pour le dépannage, car elle enregistre des informations détaillées sur chaque exécution de playbook.

   Utilisez l'éditeur nano pour créer le fichier ansible.cfg.

   nano ansible.cfg
   

   Maintenant, copiez et collez le contenu suivant dans l'éditeur nano. Cette configuration indique à Ansible d'utiliser le fichier inventory dans le répertoire courant et d'écrire toutes les sorties de journalisation dans un fichier nommé ansible.log.

   [defaults]
   inventory = /home/labex/project/ansible_troubleshooting/inventory
   log_path = /home/labex/project/ansible_troubleshooting/ansible.log
   

   Pour enregistrer le fichier dans nano, appuyez sur Ctrl+X, puis sur Y pour confirmer, et enfin sur Entrée pour écrire le fichier.

   Votre environnement est maintenant entièrement préparé. Vous avez Ansible installé et un répertoire de projet configuré avec un inventaire local et la journalisation activée, prêt pour les étapes suivantes.

Corriger les erreurs de syntaxe et d'indentation YAML dans un Playbook

Dans cette étape, vous apprendrez à diagnostiquer et à corriger deux des types d'erreurs les plus courants dans les playbooks Ansible : les erreurs de syntaxe YAML et l'indentation incorrecte. YAML, le langage utilisé pour écrire les playbooks, est très strict quant à sa structure. Un seul espace mal placé ou un caractère spécial non cité peut empêcher un playbook de s'exécuter. Vous utiliserez la commande ansible-playbook --syntax-check, un outil essentiel pour valider vos playbooks avant leur exécution.

1. Création d'un Playbook avec des erreurs intentionnelles

   Tout d'abord, vous allez créer un nouveau fichier de playbook nommé webserver.yml dans votre répertoire de projet (~/project/ansible_troubleshooting). Ce fichier contient des erreurs délibérées que vous allez corriger.

   Utilisez nano pour créer le fichier :

   nano webserver.yml
   

   Copiez et collez le contenu suivant dans l'éditeur. Notez les deux erreurs délibérées : une chaîne non citée contenant un deux-points et une indentation incorrecte pour la deuxième tâche.

   ---
   - name: Configure Web Server
     hosts: localhost
     vars:
       ## ERROR 1: Unquoted colon in string
       package_comment: This is a package: httpd
     tasks:
       - name: Install httpd package
         ansible.builtin.dnf:
           name: httpd
           state: present
   
       ## ERROR 2: Incorrect indentation
         - name: Create a test index page
           ansible.builtin.copy:
             content: "<h1>Welcome to Ansible</h1>"
             dest: /var/www/html/index.html
   

   Enregistrez le fichier et quittez nano en appuyant sur Ctrl+X, puis Y, et Entrée.

2. Identification et correction de l'erreur de syntaxe YAML (deux-points non cités)

   Maintenant, exécutez une vérification de syntaxe sur le playbook que vous venez de créer. Cette commande analysera le fichier et signalera tout problème de syntaxe sans exécuter réellement les tâches.

   ansible-playbook --syntax-check webserver.yml
   

   Sortie attendue (Erreur) : Vous verrez une erreur car la valeur de package_comment contient un deux-points (:) mais n'est pas entourée de guillemets. YAML interprète le deux-points comme un séparateur clé-valeur, ce qui entraîne une erreur de syntaxe.

   ERROR! We were unable to read either as JSON nor YAML, these are the errors we found:
   - Syntax Error while loading YAML.
     did not find expected ':'
   
   The error appears to be in '/home/labex/project/ansible_troubleshooting/webserver.yml': line 6, column 41, but may be elsewhere in the file depending on the exact syntax problem.
   
   The offending line appears to be:
   
     vars:
       package_comment: This is a package: httpd
                                           ^ here
   

   Solution : Pour corriger cela, vous devez entourer la chaîne de guillemets doubles. Ouvrez à nouveau le fichier avec nano :

   nano webserver.yml
   

   Modifiez la ligne sous vars pour ajouter des guillemets :

   ## ... (reste du fichier)
   vars:
     ## FIX: Add quotes around the string with a colon
     package_comment: "This is a package: httpd"
   ## ... (reste du fichier)
   

   Enregistrez et quittez l'éditeur.

3. Identification et correction de l'erreur d'indentation YAML

   Une fois la première erreur corrigée, exécutez à nouveau la vérification de syntaxe.

   ansible-playbook --syntax-check webserver.yml
   

   Sortie attendue (Erreur) : Cette fois, Ansible signalera une erreur différente liée à la structure du playbook.

   ERROR! A malformed block was encountered.
   
   The error appears to be in '/home/labex/project/ansible_troubleshooting/webserver.yml': line 13, column 11, but may be elsewhere in the file depending on the exact syntax problem.
   
   The offending line appears to be:
   
   
         ## ERROR 2: Incorrect indentation
         - name: Create a test index page
           ^ here
   

   Cette erreur se produit car YAML utilise l'indentation pour définir la structure. Tous les éléments d'une liste (dans ce cas, les tâches, qui sont des éléments de liste commençant par -) doivent avoir le même niveau d'indentation. La deuxième tâche, Create a test index page, est indentée trop loin.

   Solution : Ouvrez le fichier une dernière fois pour corriger l'indentation.

   nano webserver.yml
   

   Supprimez les espaces supplémentaires avant la deuxième tâche afin que son tiret (-) s'aligne parfaitement avec le tiret de la première tâche.

   ## ... (reste du fichier)
   tasks:
     - name: Install httpd package
       ansible.builtin.dnf:
         name: httpd
         state: present
   
     ## FIX: Correct the indentation to align with the previous task
     - name: Create a test index page
       ansible.builtin.copy:
         content: "<h1>Welcome to Ansible</h1>"
         dest: /var/www/html/index.html
   

   Enregistrez et quittez l'éditeur.

4. Vérification du Playbook corrigé

   Enfin, exécutez la vérification de syntaxe une dernière fois.

   ansible-playbook --syntax-check webserver.yml
   

   Cette fois, la commande devrait se terminer sans aucune erreur, et le nom du playbook sera affiché, confirmant que la syntaxe est maintenant correcte.

   Sortie attendue (Succès) :

   playbook: webserver.yml
   

Résoudre les erreurs de guillemets et de chemins de modèles Jinja2

Dans cette étape, vous allez résoudre les erreurs liées à Jinja2, le puissant moteur de templating d'Ansible. Vous apprendrez pourquoi les expressions Jinja2 doivent souvent être mises entre guillemets et comment déboguer les problèmes lorsque le playbook ne trouve pas un fichier de modèle spécifié. Ce sont des erreurs d'exécution courantes qui surviennent après qu'un playbook a déjà passé une vérification de syntaxe.

1. Création d'un fichier de modèle Jinja2

   Tout d'abord, vous avez besoin d'un fichier de modèle. Contrairement à un fichier statique, un modèle peut contenir des variables qu'Ansible remplacera par des valeurs réelles lors de l'exécution du playbook. Vous allez créer un modèle HTML simple.

   Utilisez nano pour créer un fichier nommé index.html.j2 dans votre répertoire de projet (~/project/ansible_troubleshooting). L'extension .j2 est une convention courante pour les modèles Jinja2.

   nano index.html.j2
   

   Copiez et collez le contenu HTML suivant dans l'éditeur. Notez le placeholder {{ welcome_message }}, qui est une variable Jinja2.

   <h1>{{ welcome_message }}</h1>
   <p>This page was deployed by Ansible.</p>
   

   Enregistrez le fichier et quittez nano (Ctrl+X, Y, Entrée).

2. Modification du Playbook pour utiliser le modèle et introduire des erreurs

   Maintenant, modifiez votre playbook webserver.yml pour utiliser le module ansible.builtin.template. Vous introduirez également deux nouvelles erreurs : une variable Jinja2 non citée et un chemin de modèle incorrect.

   Ouvrez webserver.yml avec nano :

   nano webserver.yml
   

   Remplacez tout le contenu du fichier par ce qui suit. La directive become: true indique à Ansible d'exécuter les tâches avec des privilèges administratifs (en utilisant sudo), ce qui est nécessaire pour installer des logiciels et écrire des fichiers dans des répertoires système comme /var/www/html.

   ---
   - name: Configure Web Server
     hosts: localhost
     become: true
     vars:
       package_name: httpd
       welcome_message: "Welcome to Ansible with Jinja2"
     tasks:
       - name: Install httpd package
         ansible.builtin.dnf:
           ## ERROR 1: Unquoted Jinja2 variable
           name: { { package_name } }
           state: present
   
       - name: Create a test index page from template
         ansible.builtin.template:
           ## ERROR 2: Incorrect template source path
           src: index.j2
           dest: /var/www/html/index.html
   

   Enregistrez et quittez l'éditeur.

3. Identification et correction de l'erreur de guillemets Jinja2

   Même s'il s'agit d'un problème Jinja2, il peut se manifester par une erreur de syntaxe YAML. Exécutez le vérificateur de syntaxe pour voir comment Ansible l'interprète.

   ansible-playbook --syntax-check webserver.yml
   

   Sortie attendue (Erreur) : Vous obtiendrez une erreur de syntaxe car une valeur YAML commençant par {{ est traitée comme une construction spéciale et doit être mise entre guillemets pour être interprétée comme une chaîne.

   ERROR! A malformed block was encountered.
   
   The error appears to be in '/home/labex/project/ansible_troubleshooting/webserver.yml': line 11, column 19, but may be elsewhere in the file depending on the exact syntax problem.
   
   The offending line appears to be:
   
             ## ERROR 1: Unquoted Jinja2 variable
             name: {{ package_name }}
                     ^ here
   

   Solution : Ouvrez webserver.yml et entourez la variable Jinja2 de guillemets doubles.

   nano webserver.yml
   

   Modifiez la tâche Install httpd package :

   ## ... (reste du fichier)
   tasks:
     - name: Install httpd package
       ansible.builtin.dnf:
         ## FIX: Quote the Jinja2 expression
         name: "{{ package_name }}"
         state: present
   ## ... (reste du fichier)
   

   Enregistrez et quittez. La vérification de syntaxe devrait maintenant réussir.

4. Identification et correction de l'erreur de chemin de modèle

   Maintenant que la syntaxe est correcte, essayez d'exécuter le playbook.

   ansible-playbook webserver.yml
   

   Sortie attendue (Erreur) : Le playbook échouera, mais cette fois, il s'agit d'une erreur d'exécution, pas d'une erreur de syntaxe. Le message d'erreur indique clairement que le fichier source index.j2 n'a pas pu être trouvé.

   TASK [Create a test index page from template] **********************************
   fatal: [localhost]: FAILED! => {"changed": false, "msg": "Could not find or access '/home/labex/project/ansible_troubleshooting/index.j2' on the Ansible Controller."}
   

   Cela se produit car le paramètre src de votre playbook pointe vers index.j2, mais le fichier que vous avez créé s'appelle index.html.j2.

   Solution : Ouvrez webserver.yml une dernière fois et corrigez le nom du fichier.

   nano webserver.yml
   

   Modifiez le paramètre src dans la tâche Create a test index page from template :

   ## ... (reste du fichier)
   - name: Create a test index page from template
     ansible.builtin.template:
       ## FIX: Correct template source filename
       src: index.html.j2
       dest: /var/www/html/index.html
   ## ... (reste du fichier)
   

   Enregistrez et quittez l'éditeur.

5. Exécution réussie du Playbook

   Exécutez à nouveau le playbook. Il devrait maintenant terminer toutes les tâches avec succès.

   ansible-playbook webserver.yml
   

   Sortie attendue (Succès) :

   PLAY [Configure Web Server] ****************************************************
   
   TASK [Gathering Facts] *********************************************************
   ok: [localhost]
   
   TASK [Install httpd package] ***************************************************
   changed: [localhost]
   
   TASK [Create a test index page from template] **********************************
   changed: [localhost]
   
   PLAY RECAP *********************************************************************
   localhost                  : ok=3    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
   

Utiliser le mode de vérification pour dépanner les erreurs de service sur les hôtes gérés

Dans cette étape, vous apprendrez à utiliser l'une des fonctionnalités de dépannage les plus puissantes d'Ansible : le mode de vérification (Check Mode). Le mode de vérification (activé avec le drapeau --check) vous permet d'exécuter un playbook pour voir quelles modifications seraient apportées, sans modifier réellement quoi que ce soit sur le système. Ceci est incroyablement utile pour tester en toute sécurité les playbooks et diagnostiquer les problèmes, tels que les noms de service incorrects, avant qu'ils ne causent de réels problèmes.

1. Création d'un Playbook pour gérer un service

   Vous allez maintenant créer un nouveau playbook, service.yml, conçu pour s'assurer que le service du serveur web httpd est en cours d'exécution. Cependant, vous utiliserez intentionnellement un nom de service incorrect pour simuler une erreur courante.

   Utilisez nano pour créer le fichier service.yml dans votre répertoire ~/project/ansible_troubleshooting.

   nano service.yml
   

   Copiez et collez le contenu suivant. Notez que le nom du service est défini sur apache2, ce qui est un nom courant pour le serveur web Apache sur d'autres distributions Linux, mais incorrect pour RHEL.

   ---
   - name: Manage Web Server Service
     hosts: localhost
     become: true
     tasks:
       - name: Ensure web server service is started
         ansible.builtin.service:
           ## ERROR: Incorrect service name for RHEL
           name: apache2
           state: started
           enabled: true
   

   Enregistrez le fichier et quittez nano (Ctrl+X, Y, Entrée).

2. Utilisation du mode de vérification pour identifier l'erreur de service

   Au lieu d'exécuter le playbook normalement, exécutez-le en mode de vérification. Cela empêchera Ansible d'apporter des modifications, mais lui permettra de vérifier l'état du système et de signaler ce qu'il ferait en réalité.

   ansible-playbook --check service.yml
   

   Sortie attendue (Erreur) : Le playbook échouera. Le message d'erreur indiquera clairement qu'il n'a pas pu trouver de service nommé apache2. Cela vous indique immédiatement que le paramètre name de votre playbook est incorrect.

   TASK [Ensure web server service is started] ************************************
   fatal: [localhost]: FAILED! => {"changed": false, "msg": "Could not find the requested service 'apache2': host"}
   
   PLAY RECAP *********************************************************************
   localhost                  : ok=1    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0
   

3. Recherche du nom de service correct

   Pour corriger le playbook, vous devez trouver le nom de service correct pour le package httpd sur RHEL. Un moyen fiable de le faire est de lister les fichiers installés par le package et de rechercher le fichier d'unité de service, qui se trouve généralement dans /usr/lib/systemd/system/.

   Utilisez la commande rpm pour interroger le package httpd :

   rpm -ql httpd | grep systemd
   

   Sortie attendue : Cette commande listera les fichiers liés à systemd, y compris le fichier de service.

   /usr/lib/systemd/system/httpd.service
   /usr/lib/systemd/system/httpd@.service
   ...
   

   La sortie httpd.service vous indique que le nom de service correct est httpd.

4. Correction du Playbook et ré-exécution en mode de vérification

   Maintenant que vous connaissez le nom de service correct, modifiez le fichier service.yml.

   nano service.yml
   

   Changez le nom du service de apache2 à httpd.

   ## ... (reste du fichier)
   - name: Ensure web server service is started
     ansible.builtin.service:
       ## FIX: Correct service name for RHEL
       name: httpd
       state: started
       enabled: true
   

   Enregistrez et quittez l'éditeur. Maintenant, exécutez à nouveau le playbook en mode de vérification.

   ansible-playbook --check service.yml
   

   Sortie attendue (Succès en mode de vérification) : Cette fois, le playbook devrait signaler un statut changed. En mode de vérification, changed signifie "une modification aurait été apportée si c'était une exécution réelle". Cela indique que la logique de votre playbook est maintenant correcte et qu'Ansible a identifié que le service httpd doit être démarré.

   TASK [Ensure web server service is started] ************************************
   changed: [localhost]
   
   PLAY RECAP *********************************************************************
   localhost                  : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
   

   Note : Dans cet environnement de laboratoire spécifique basé sur des conteneurs, un système d'initialisation systemd complet n'est pas en cours d'exécution. Bien que le mode de vérification fonctionne correctement, une exécution normale du module ansible.builtin.service pourrait toujours rencontrer des problèmes. La leçon clé ici est d'utiliser le mode de vérification pour valider la logique de votre playbook par rapport à la configuration du système.

Corriger la configuration du pare-feu et les problèmes d'inaccessibilité des hôtes

Dans cette dernière étape, vous aborderez deux problèmes critiques d'exécution : les échecs causés par des configurations système incorrectes, comme le pare-feu, et les problèmes de connectivité résultant d'erreurs dans votre fichier d'inventaire Ansible. La maîtrise de ces éléments vous aidera à résoudre certains des obstacles les plus courants en matière d'automatisation.

Partie 1 : Correction de la configuration du pare-feu

Une tâche courante dans la configuration des serveurs consiste à ouvrir des ports dans le pare-feu. Un playbook peut facilement échouer s'il fait référence à un service de pare-feu qui n'existe pas sur le système cible.

1. Installation et préparation de firewalld

   Tout d'abord, assurez-vous que le package firewalld est installé, car il fournit le service de gestion du pare-feu sur RHEL.

   sudo dnf install -y firewalld
   

   Démarrez le service firewalld.

   sudo systemctl start firewalld
   

   Vous devez également installer la collection ansible.posix, qui contient le module firewalld utilisé dans cet exercice.

   ansible-galaxy collection install ansible.posix
   

   Note : Vous pourriez voir un avertissement concernant la compatibilité de la version d'Ansible, mais la collection fonctionnera toujours correctement pour cet exercice.

2. Création d'un Playbook avec une erreur de pare-feu

   Créez un nouveau playbook nommé firewall.yml qui tente d'activer le service http. Cependant, vous utiliserez intentionnellement un nom de service incorrect, web, pour déclencher une erreur.

   nano firewall.yml
   

   Copiez et collez le contenu suivant dans l'éditeur :

   ---
   - name: Configure System Firewall
     hosts: localhost
     become: true
     tasks:
       - name: Allow web traffic through firewall
         ansible.posix.firewalld:
           ## ERROR: 'web' is not a standard firewalld service
           service: web
           permanent: true
           state: enabled
   

   Enregistrez et quittez nano (Ctrl+X, Y, Entrée).

3. Exécution du Playbook et diagnostic de l'échec

   Exécutez le playbook. Il échouera car firewalld ne reconnaît pas de service nommé web.

   ansible-playbook firewall.yml
   

   Sortie attendue (Erreur) : Le message d'erreur indique clairement que web n'est pas un service pris en charge, vous orientant directement vers le problème.

   TASK [Allow web traffic through firewall] **************************************
   fatal: [localhost]: FAILED! => {"changed": false, "msg": "web is not a supported service. This is what I have."}
   
   PLAY RECAP *********************************************************************
   localhost                  : ok=1    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0
   

4. Recherche du nom de service de pare-feu correct

   Pour trouver la liste des noms de services valides et prédéfinis, vous pouvez utiliser l'outil en ligne de commande firewall-cmd.

   firewall-cmd --get-services
   

   Sortie attendue : Vous verrez une longue liste de services disponibles. Parcourez la liste pour trouver celui qui convient au trafic web, qui est http.

   RH-Satellite-6 ... ftp http https imaps ipp ipp-client ...
   

5. Correction du Playbook et exécution réussie

   Modifiez firewall.yml et remplacez le nom de service incorrect web par le nom correct, http.

   nano firewall.yml
   

   La tâche corrigée devrait ressembler à ceci :

   ## ... (reste du fichier)
   - name: Allow web traffic through firewall
     ansible.posix.firewalld:
       ## FIX: Use the correct firewalld service name
       service: http
       permanent: true
       state: enabled
   

   Enregistrez et quittez. Exécutez maintenant à nouveau le playbook. Il devrait se terminer avec succès.

   ansible-playbook firewall.yml
   

Partie 2 : Dépannage de l'inaccessibilité des hôtes

Une erreur "unreachable" (inaccessible) signifie qu'Ansible ne peut pas se connecter à un hôte répertorié dans votre inventaire. Ceci est souvent causé par une simple faute de frappe dans le nom d'hôte.

1. Simulation d'un hôte inaccessible

   Introduisez intentionnellement une faute de frappe dans votre fichier inventory et supprimez le paramètre de connexion locale. Cela forcera Ansible à tenter une connexion réseau réelle au nom d'hôte mal orthographié.

   nano inventory
   

   Changez localhost en localhossst et supprimez ansible_connection=local.

   ## ERROR: Intentional typo in hostname, no local connection
   localhossst
   

   Enregistrez et quittez l'éditeur.

2. Modification du Playbook pour utiliser les hôtes de l'inventaire

   Tout d'abord, vous devez modifier le playbook webserver.yml pour utiliser les hôtes de l'inventaire au lieu du localhost codé en dur. Lorsqu'un playbook utilise hosts: localhost, Ansible le traite comme un cas spécial et ignore complètement le fichier d'inventaire.

   nano webserver.yml
   

   Changez la ligne hosts de localhost à all :

   ---
   - name: Configure Web Server
     hosts: all ## Changed from 'localhost' to use inventory hosts
     become: true
     ## ... rest of the playbook remains the same
   

   Enregistrez et quittez l'éditeur.

3. Exécution du Playbook pour déclencher l'erreur

   Essayez maintenant d'exécuter le playbook modifié. Il échouera car l'inventaire contient la faute de frappe localhossst.

   ansible-playbook webserver.yml
   

   Sortie attendue (Erreur) : Ansible échouera et signalera l'hôte comme UNREACHABLE. Le message d'erreur indique que le nom d'hôte n'a pas pu être résolu.

   PLAY [Configure Web Server] ****************************************************
   
   TASK [Gathering Facts] **********************************************************
   fatal: [localhossst]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: ssh: Could not resolve hostname localhossst: Name or service not known", "unreachable": true}
   
   PLAY RECAP *********************************************************************
   localhossst                : ok=0    changed=0    unreachable=1    failed=0    skipped=0    rescued=0    ignored=0
   

4. Correction du fichier d'inventaire

   Le statut UNREACHABLE est votre signal pour vérifier les noms d'hôtes et la connectivité réseau. Dans ce cas, la correction consiste à corriger la faute de frappe dans le fichier inventory.

   nano inventory
   

   Changez localhossst en localhost.

   ## FIX: Corrected hostname
   localhost ansible_connection=local
   

   Enregistrez et quittez. La ré-exécution de ansible-playbook webserver.yml réussira maintenant.

5. Optionnel : Restauration du Playbook d'origine

   Si vous souhaitez restaurer le playbook pour utiliser hosts: localhost pour les exercices futurs, vous pouvez le modifier à nouveau :

   nano webserver.yml
   

   Remettez la ligne hosts à localhost :

   ---
   - name: Configure Web Server
     hosts: localhost ## Restored to original
     become: true
     ## ... rest of the playbook
   

   Enregistrez et quittez. Cette étape démontre la différence entre l'utilisation de localhost codé en dur (qui ignore l'inventaire) et l'utilisation d'hôtes définis dans l'inventaire.

Résumé

Dans ce laboratoire, vous avez préparé un environnement Red Hat Enterprise Linux pour Ansible en installant ansible-core et en configurant la journalisation, puis vous avez procédé au dépannage d'une variété de problèmes courants. Vous avez appris à diagnostiquer et à résoudre les erreurs dans les playbooks, telles que la correction de la syntaxe YAML incorrecte, de l'indentation, des guillemets Jinja2 et des chemins de modèles invalides. Ces compétences sont fondamentales pour écrire du code d'automatisation valide et fiable.

De plus, vous avez traité des problèmes liés à l'environnement de l'hôte géré. Vous avez utilisé le mode de vérification d'Ansible pour effectuer en toute sécurité une simulation et identifier les défaillances potentielles de services sur un nœud cible sans apporter de modifications réelles. Le laboratoire s'est terminé par la résolution de problèmes de connectivité, où vous avez corrigé les configurations du pare-feu pour résoudre l'inaccessibilité des hôtes, offrant ainsi une approche complète du débogage, du nœud de contrôle à l'hôte géré.