LabEx
EntrerRejoindre

Déployer et gérer des fichiers sur RHEL avec Ansible

AnsibleBeginner
Pratiquer maintenant

Introduction

Dans ce laboratoire, vous apprendrez les compétences fondamentales pour déployer et gérer des fichiers sur un système Red Hat Enterprise Linux (RHEL) à l'aide d'Ansible. Vous acquerrez une expérience pratique avec certains des modules Ansible les plus courants et les plus puissants conçus pour les opérations sur les fichiers, en passant du déploiement de fichiers de base à la manipulation de contenu et à la gestion d'état plus avancées.

Vous commencerez par utiliser le module ansible.builtin.copy pour transférer un fichier statique et définir ses attributs. Ensuite, vous modifierez le contenu des fichiers avec lineinfile et blockinfile, et générerez un MOTD personnalisé à l'aide du module ansible.builtin.template. Le laboratoire couvre également la création de liens symboliques, la vérification des états de fichiers avec stat, la récupération de journaux avec fetch, et le nettoyage des fichiers gérés, offrant ainsi un aperçu complet des capacités de gestion de fichiers d'Ansible.

Copier un fichier statique et définir ses attributs avec le module ansible.builtin.copy

Dans cette étape, vous apprendrez à utiliser l'un des modules Ansible les plus fondamentaux : ansible.builtin.copy. Ce module est utilisé pour transférer des fichiers de votre nœud de contrôle (la VM LabEx) vers un emplacement spécifié sur vos hôtes gérés. Dans notre cas, l'hôte géré sera localhost lui-même. Au-delà de la simple copie, le module copy vous permet de contrôler précisément les attributs du fichier, tels que son propriétaire, son groupe et son mode de permission, ce qui est essentiel pour une configuration système correcte.

Tout d'abord, mettons en place notre environnement de projet. Tout notre travail sera effectué dans le répertoire ~/project.

  1. Naviguez vers le répertoire du projet et créez un sous-répertoire pour nos fichiers sources. C'est une pratique courante pour garder votre projet organisé.

    Installez le paquet ansible-core.

    sudo dnf install -y ansible-core

    Ensuite, naviguez vers le répertoire du projet et créez un sous-répertoire pour nos fichiers sources.

    cd ~/project
mkdir files

  2. Ensuite, créez un fichier texte simple que nous allons copier. Nous utiliserons une commande cat avec un "here document" pour créer le fichier info.txt dans le répertoire files.

    cat << EOF > ~/project/files/info.txt
This file was deployed by Ansible.
It contains important system information.
EOF

  3. Maintenant, créez un fichier d'inventaire Ansible. L'inventaire indique à Ansible quels hôtes gérer. Pour ce laboratoire, nous allons gérer la machine locale. Créez un fichier nommé inventory.ini.

    cat << EOF > ~/project/inventory.ini
localhost ansible_connection=local
EOF

    Dans cet inventaire, localhost est l'hôte que nous ciblons. La variable ansible_connection=local indique à Ansible d'exécuter les tâches directement sur le nœud de contrôle, sans utiliser SSH.

  4. Créez votre premier playbook Ansible. Ce playbook contiendra les instructions pour copier le fichier. Utilisez nano ou cat pour créer un fichier nommé copy_file.yml.

    nano ~/project/copy_file.yml

    Ajoutez le contenu suivant au fichier. Ce playbook définit une tâche : copier info.txt dans le répertoire /tmp/ et définir ses attributs.

    ---
- name: Deploy a static file to localhost
  hosts: localhost
  tasks:
    - name: Copy info.txt and set attributes
      ansible.builtin.copy:
        src: files/info.txt
        dest: /tmp/info.txt
        owner: labex
        group: labex
        mode: "0640"

    Décomposons les paramètres de la tâche copy :

    • src: files/info.txt: Le chemin du fichier source sur le nœud de contrôle, relatif à l'emplacement du playbook.
    • dest: /tmp/info.txt: Le chemin absolu où le fichier sera placé sur l'hôte géré.
    • owner: labex: Définit le propriétaire du fichier sur l'utilisateur labex.
    • group: labex: Définit le groupe du fichier sur le groupe labex.
    • mode: '0640': Définit les permissions du fichier. 0640 signifie que le propriétaire peut lire/écrire, le groupe peut lire, et les autres n'ont aucune permission.

  5. Exécutez le playbook en utilisant la commande ansible-playbook. L'indicateur -i spécifie notre fichier d'inventaire.

    ansible-playbook -i inventory.ini copy_file.yml

    Vous devriez voir une sortie indiquant l'exécution réussie du playbook, similaire à ceci :

    PLAY [Deploy a static file to localhost] ***************************************

TASK [Gathering Facts] *********************************************************
ok: [localhost]

TASK [Copy info.txt and set attributes] ****************************************
changed: [localhost]

PLAY RECAP *********************************************************************
localhost                  : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

  6. Enfin, vérifiez que le fichier a été copié correctement et qu'il possède les bons attributs. Utilisez la commande ls -l pour vérifier les permissions, le propriétaire et le groupe.

    ls -l /tmp/info.txt

    La sortie devrait indiquer que labex est le propriétaire et le groupe, et que les permissions sont -rw-r-----.

    -rw-r----- 1 labex labex 72 Jul 10 14:30 /tmp/info.txt

    Vous pouvez également afficher le contenu du fichier pour vous assurer qu'il a été copié entièrement.

    cat /tmp/info.txt

    This file was deployed by Ansible.
It contains important system information.

Vous avez utilisé avec succès le module ansible.builtin.copy pour déployer un fichier et configurer ses attributs sur votre système local.

Modifier le contenu des fichiers avec lineinfile et blockinfile

Dans cette étape, vous apprendrez à modifier des fichiers existants sur un hôte géré sans remplacer le fichier entier. Ansible fournit des modules puissants à cet effet : ansible.builtin.lineinfile pour gérer des lignes uniques et ansible.builtin.blockinfile pour gérer des blocs de texte de plusieurs lignes. Ces modules sont extrêmement utiles pour des tâches telles que la modification de paramètres de configuration ou l'ajout d'entrées dans des fichiers journaux.

Nous continuerons à travailler avec le fichier info.txt que vous avez créé à l'étape précédente, situé à /tmp/info.txt.

  1. Tout d'abord, assurez-vous d'être dans le répertoire du projet.

    cd ~/project

  2. Créez un nouveau playbook nommé modify_file.yml. Ce playbook contiendra deux tâches : une pour ajouter une ligne unique et une autre pour ajouter un bloc de texte à notre fichier existant.

    nano ~/project/modify_file.yml

  3. Ajoutez le contenu suivant à votre playbook modify_file.yml. Ce playbook cible localhost et utilise à la fois lineinfile et blockinfile pour ajouter du contenu à /tmp/info.txt.

    ---
- name: Modify an existing file
  hosts: localhost
  tasks:
    - name: Add a single line of text to a file
      ansible.builtin.lineinfile:
        path: /tmp/info.txt
        line: This line was added by the lineinfile module.
        state: present

    - name: Add a block of text to an existing file
      ansible.builtin.blockinfile:
        path: /tmp/info.txt
        block: |
          ## BEGIN ANSIBLE MANAGED BLOCK
          This block of text consists of two lines.
          They have been added by the blockinfile module.
          ## END ANSIBLE MANAGED BLOCK
        state: present

    Examinons les modules utilisés :

    • ansible.builtin.lineinfile: Ce module garantit qu'une ligne spécifique est présente dans un fichier. Si la ligne existe déjà, Ansible ne fait rien, rendant la tâche idempotente.
      • path: Le fichier à modifier.
      • line: La ligne de texte à s'assurer qu'elle se trouve dans le fichier.
      • state: present: Ceci garantit que la ligne existe. Vous pourriez utiliser state: absent pour la supprimer.
    • ansible.builtin.blockinfile: Ce module gère un bloc de texte, entouré de lignes marqueurs (par exemple, ## BEGIN ANSIBLE MANAGED BLOCK). Ceci est idéal pour gérer des sections de configuration.
      • path: Le fichier à modifier.
      • block: La chaîne de caractères multiligne à insérer. Le | est une syntaxe YAML pour un bloc littéral, préservant les sauts de ligne.
      • state: present: Garantit que le bloc existe.

  4. Exécutez le playbook en utilisant la commande ansible-playbook et votre fichier inventory.ini.

    ansible-playbook -i inventory.ini modify_file.yml

    La sortie montrera que les deux tâches ont apporté des modifications au fichier.

    PLAY [Modify an existing file] *************************************************

TASK [Gathering Facts] *********************************************************
ok: [localhost]

TASK [Add a single line of text to a file] *************************************
changed: [localhost]

TASK [Add a block of text to an existing file] *********************************
changed: [localhost]

PLAY RECAP *********************************************************************
localhost                  : ok=3    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

  5. Enfin, vérifiez les modifications en consultant le contenu de /tmp/info.txt.

    cat /tmp/info.txt

    Vous devriez voir le contenu original, suivi de la nouvelle ligne et du nouveau bloc de texte.

    This file was deployed by Ansible.
It contains important system information.
This line was added by the lineinfile module.
## BEGIN ANSIBLE MANAGED BLOCK
This block of text consists of two lines.
They have been added by the blockinfile module.
## END ANSIBLE MANAGED BLOCK

    Si vous exécutez à nouveau le playbook, Ansible indiquera ok=3 et changed=0 car le contenu est déjà présent, démontrant ainsi la nature idempotente de ces modules.

Générer un MOTD personnalisé avec le module ansible.builtin.template

Dans cette étape, vous passerez de la copie de fichiers statiques à la génération de fichiers dynamiques à l'aide du module ansible.builtin.template. Ce module s'appuie sur le moteur de templating Jinja2 pour créer des fichiers personnalisés avec des variables et des informations système, appelées "facts", que Ansible collecte sur vos hôtes gérés. Nous allons créer un Message du Jour (MOTD) dynamique qui affichera des informations spécifiques au système.

  1. Tout d'abord, assurez-vous d'être dans le répertoire ~/project et créez un sous-répertoire dédié à vos templates. Il est de bonne pratique Ansible de stocker les templates Jinja2 dans un répertoire templates.

    cd ~/project
mkdir templates

  2. Ensuite, créez le fichier de template Jinja2. Ce fichier, motd.j2, contiendra la structure de notre MOTD, avec des espaces réservés pour les données dynamiques. L'extension .j2 est une convention courante pour les templates Jinja2.

    nano ~/project/templates/motd.j2

    Ajoutez le contenu suivant au fichier. Remarquez la syntaxe {{ ... }}, qui indique un espace réservé pour une variable ou un fact.

    #################################################################
##          Welcome to {{ ansible_facts['fqdn'] }}
#
## This is a {{ ansible_facts['distribution'] }} system.
## System managed by Ansible.
#
## For support, contact: {{ admin_email }}
#################################################################

    Dans ce template :

    • {{ ansible_facts['fqdn'] }} sera remplacé par le nom de domaine pleinement qualifié (Fully Qualified Domain Name) de l'hôte.
    • {{ ansible_facts['distribution'] }} sera remplacé par le nom de la distribution Linux (par exemple, RedHat).
    • {{ admin_email }} est une variable personnalisée que nous définirons dans notre playbook.

  3. Maintenant, créez un nouveau playbook nommé template_motd.yml. Ce playbook utilisera le template pour générer /etc/motd.

    nano ~/project/template_motd.yml

    Ajoutez le contenu suivant. Ce playbook nécessite des privilèges élevés (become: true) pour écrire dans le répertoire /etc. Il définit également la variable personnalisée admin_email.

    ---
- name: Deploy a custom MOTD from a template
  hosts: localhost
  become: true
  vars:
    admin_email: admin@labex.io
  tasks:
    - name: Generate /etc/motd from template
      ansible.builtin.template:
        src: templates/motd.j2
        dest: /etc/motd
        owner: root
        group: root
        mode: "0644"

    Paramètres clés de ce playbook :

    • become: true: Ceci indique à Ansible d'utiliser sudo pour exécuter la tâche, ce qui est nécessaire pour écrire dans /etc/motd.
    • vars: Cette section est l'endroit où nous définissons des variables personnalisées, comme admin_email.
    • ansible.builtin.template: Le module qui traite le template Jinja2. src pointe vers notre fichier .j2, et dest est le fichier cible sur l'hôte géré.

  4. Exécutez le playbook.

    ansible-playbook -i inventory.ini template_motd.yml

    La sortie devrait confirmer que la tâche a réussi.

    PLAY [Deploy a custom MOTD from a template] ************************************

TASK [Gathering Facts] *********************************************************
ok: [localhost]

TASK [Generate /etc/motd from template] ****************************************
changed: [localhost]

PLAY RECAP *********************************************************************
localhost                  : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

  5. Vérifiez le résultat. Consultez le contenu du fichier /etc/motd nouvellement généré.

    cat /etc/motd

    Vous verrez la sortie rendue, avec les espaces réservés Jinja2 remplacés par les faits système réels et la variable personnalisée que vous avez définie. Le fqdn correspondra au nom d'hôte de votre environnement de laboratoire.

    #################################################################
##          Welcome to host.labex.io
#
## This is a RedHat system.
## System managed by Ansible.
#
## For support, contact: admin@labex.io
#################################################################

Vous avez maintenant utilisé avec succès un template pour créer un fichier personnalisé, une compétence essentielle en automatisation d'infrastructure.

Déployer des fichiers de support et créer un lien symbolique avec copy et file

Dans cette étape, vous combinerez vos connaissances du module copy avec un nouveau module polyvalent : ansible.builtin.file. Alors que copy sert à transférer du contenu, file est utilisé pour gérer l'état des fichiers, des répertoires et des liens symboliques sur l'hôte géré. Vous l'utiliserez pour créer des répertoires, définir des permissions et, surtout pour cet exercice, créer des liens symboliques.

Notre scénario consiste à configurer les messages de pré-connexion affichés par le système. Dans de nombreux systèmes Linux, /etc/issue est affiché aux utilisateurs du terminal local, et /etc/issue.net est affiché aux utilisateurs distants (par exemple, via SSH). Nous allons déployer un seul fichier issue puis créer un lien symbolique afin que /etc/issue.net pointe vers /etc/issue, garantissant qu'ils affichent toujours le même message.

  1. Tout d'abord, assurez-vous d'être dans le répertoire ~/project et créez le fichier source pour notre message d'issue. Nous placerons ce fichier dans le sous-répertoire files que vous avez créé précédemment.

    cd ~/project
cat << EOF > ~/project/files/issue
Authorized access only.
All connections are logged and monitored.
EOF

  2. Créez un nouveau playbook nommé deploy_issue.yml. Ce playbook contiendra deux tâches : une pour copier le fichier issue et une autre pour créer le lien symbolique.

    nano ~/project/deploy_issue.yml

  3. Ajoutez le contenu suivant à votre playbook deploy_issue.yml. Ce playbook nécessite des privilèges élevés (become: true) pour gérer les fichiers dans le répertoire /etc/.

    ---
- name: Configure system issue files
  hosts: localhost
  become: true
  tasks:
    - name: Copy custom /etc/issue file
      ansible.builtin.copy:
        src: files/issue
        dest: /etc/issue
        owner: root
        group: root
        mode: "0644"

    - name: Ensure /etc/issue.net is a symlink to /etc/issue
      ansible.builtin.file:
        src: /etc/issue
        dest: /etc/issue.net
        state: link
        force: yes

    Analysons la nouvelle tâche ansible.builtin.file :

    • src: /etc/issue: Lorsque state est link, src spécifie le fichier vers lequel le lien symbolique doit pointer.
    • dest: /etc/issue.net: C'est le chemin où le lien symbolique lui-même sera créé.
    • state: link: Ce paramètre crucial indique au module file de créer un lien symbolique, et non un fichier ou un répertoire ordinaire.
    • force: yes: C'est une option utile qui garantit l'idempotence. Si /etc/issue.net existe déjà en tant que fichier ordinaire, Ansible le supprimera et créera le lien. Sans force: yes, le playbook échouerait dans cette situation.

  4. Exécutez le playbook.

    ansible-playbook -i inventory.ini deploy_issue.yml

    La sortie montrera que les deux tâches ont apporté des modifications avec succès.

    PLAY [Configure system issue files] ********************************************

TASK [Gathering Facts] *********************************************************
ok: [localhost]

TASK [Copy custom /etc/issue file] *********************************************
changed: [localhost]

TASK [Ensure /etc/issue.net is a symlink to /etc/issue] ************************
changed: [localhost]

PLAY RECAP *********************************************************************
localhost                  : ok=3    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

  5. Vérifiez le résultat à l'aide de la commande ls -l. Cette commande fournit une liste détaillée qui montre clairement les liens symboliques.

    ls -l /etc/issue /etc/issue.net

    La sortie devrait montrer que /etc/issue est un fichier ordinaire et que /etc/issue.net est un lien symbolique pointant vers celui-ci. Le l au début des permissions pour /etc/issue.net indique qu'il s'agit d'un lien.

    -rw-r--r--. 1 root root 65 Jul 10 15:00 /etc/issue
lrwxrwxrwx. 1 root root 10 Jul 10 15:00 /etc/issue.net -> /etc/issue

Vous avez maintenant déployé avec succès un fichier de configuration et utilisé le module ansible.builtin.file pour créer un lien symbolique, un modèle courant et puissant pour gérer les configurations système.

Vérifier l'état du fichier avec stat et récupérer les journaux avec fetch

Dans cette étape, vous découvrirez deux modules importants de collecte de données : ansible.builtin.stat et ansible.builtin.fetch. Le module stat est utilisé pour vérifier le statut d'un fichier ou d'un répertoire sur un hôte géré – par exemple, pour voir s'il existe, quelles sont ses permissions, ou quand il a été modifié pour la dernière fois. Il ne modifie rien, ce qui le rend parfait pour les vérifications et la logique conditionnelle. Le module fetch fait l'inverse de copy : il récupère des fichiers depuis l'hôte géré et les enregistre sur votre nœud de contrôle, ce qui est idéal pour sauvegarder des configurations ou collecter des fichiers journaux pour analyse.

Nous allons créer un playbook qui vérifie d'abord l'existence du fichier /etc/motd que vous avez créé précédemment, puis récupère le fichier journal du gestionnaire de paquets DNF (/var/log/dnf.log) vers un répertoire local sur votre VM LabEx.

  1. Tout d'abord, assurez-vous d'être dans le répertoire ~/project et créez un nouveau sous-répertoire pour stocker les fichiers que vous allez récupérer.

    cd ~/project
mkdir fetched_logs

  2. Créez un nouveau playbook nommé check_and_fetch.yml. Ce playbook contiendra les tâches pour vérifier le fichier et récupérer le journal.

    nano ~/project/check_and_fetch.yml

  3. Ajoutez le contenu suivant à votre playbook check_and_fetch.yml. Ce playbook utilise stat pour obtenir les détails du fichier, register pour stocker ces détails dans une variable, debug pour afficher la variable, et fetch pour récupérer le fichier journal.

    ---
- name: Check file status and fetch logs
  hosts: localhost
  become: true
  tasks:
    - name: Check if /etc/motd exists
      ansible.builtin.stat:
        path: /etc/motd
      register: motd_status

    - name: Display stat results
      ansible.builtin.debug:
        var: motd_status.stat

    - name: Fetch the dnf log file from managed host
      ansible.builtin.fetch:
        src: /var/log/dnf.log
        dest: fetched_logs/
        flat: yes

    Décomposons les concepts clés :

    • register: motd_status: C'est une fonctionnalité Ansible cruciale. Elle prend la sortie complète d'une tâche et l'enregistre dans une nouvelle variable nommée motd_status.
    • ansible.builtin.debug: Ce module est utilisé pour afficher des valeurs pendant l'exécution d'un playbook. Ici, nous affichons l'objet stat dans notre variable enregistrée (motd_status.stat) pour voir les propriétés du fichier.
    • ansible.builtin.fetch: Ce module récupère un fichier de l'hôte géré.
      • src: Le chemin du fichier à récupérer depuis l'hôte géré.
      • dest: Le répertoire sur le nœud de contrôle (votre VM LabEx) où le fichier sera sauvegardé.
      • flat: yes: Par défaut, fetch crée une structure de sous-répertoires correspondant à l'hôte et au chemin source. flat: yes simplifie cela en copiant le fichier directement dans le répertoire dest sans sous-répertoires supplémentaires.

  4. Exécutez le playbook. Étant donné que nous lisons un fichier journal système, become: true est utilisé pour obtenir les permissions nécessaires.

    ansible-playbook -i inventory.ini check_and_fetch.yml

    La sortie affichera les résultats de la vérification stat dans la tâche de débogage, suivis de la tâche fetch.

    PLAY [Check file status and fetch logs] ****************************************

TASK [Gathering Facts] *********************************************************
ok: [localhost]

TASK [Check if /etc/motd exists] ***********************************************
ok: [localhost]

TASK [Display stat results] ****************************************************
ok: [localhost] => {
    "motd_status.stat": {
        "exists": true,
        "gid": 0,
        "isreg": true,
        "mode": "0644",
        "path": "/etc/motd",
        ...
    }
}

TASK [Fetch the dnf log file from managed host] ********************************
changed: [localhost]

PLAY RECAP *********************************************************************
localhost                  : ok=4    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

  5. Vérifiez que le fichier journal a été récupéré avec succès. Listez le contenu du répertoire fetched_logs.

    ls -l ~/project/fetched_logs/

    Vous devriez voir le fichier dnf.log, maintenant stocké localement sur votre nœud de contrôle.

    total 4
-rw-r--r--. 1 labex labex 1234 Jul 10 15:30 dnf.log

Vous avez maintenant appris à inspecter les propriétés des fichiers sans apporter de modifications et à récupérer des fichiers importants de vos systèmes gérés vers votre nœud de contrôle.

Nettoyer les fichiers de l'hôte géré avec le module file

Dans cette dernière étape, vous apprendrez à utiliser le module ansible.builtin.file pour vous assurer que les fichiers et répertoires ne sont pas présents sur un système. Une partie essentielle de la gestion de configuration n'est pas seulement de créer et modifier des ressources, mais aussi de les nettoyer. En définissant le paramètre state sur absent, vous pouvez indiquer à Ansible de supprimer des fichiers, des liens symboliques, ou même des répertoires entiers.

Pour conclure ce laboratoire, nous allons écrire un seul playbook de "nettoyage" qui supprime tous les artefacts que nous avons créés dans les étapes précédentes : /tmp/info.txt, /etc/motd, /etc/issue, et le lien symbolique /etc/issue.net.

  1. Tout d'abord, assurez-vous d'être dans le répertoire ~/project.

    cd ~/project

  2. Créez un nouveau playbook nommé cleanup.yml. Ce playbook contiendra toutes les tâches nécessaires pour annuler nos modifications.

    nano ~/project/cleanup.yml

  3. Ajoutez le contenu suivant à votre playbook cleanup.yml. Ce playbook utilise une liste de tâches, chacune ciblant l'un des fichiers que nous avons créés. Notez que become: true est défini au niveau du play, donc toutes les tâches s'exécuteront avec des privilèges élevés.

    ---
- name: Clean up managed files from the system
  hosts: localhost
  become: true
  tasks:
    - name: Remove the temporary info file
      ansible.builtin.file:
        path: /tmp/info.txt
        state: absent

    - name: Remove the custom MOTD file
      ansible.builtin.file:
        path: /etc/motd
        state: absent

    - name: Remove the custom issue file
      ansible.builtin.file:
        path: /etc/issue
        state: absent

    - name: Remove the issue.net symbolic link
      ansible.builtin.file:
        path: /etc/issue.net
        state: absent

    La clé de ce playbook est le paramètre state: absent dans chaque tâche. Cela indique au module file de s'assurer que l'élément au path spécifié n'existe pas. S'il trouve le fichier, il le supprimera. Si le fichier est déjà absent, il ne fera rien, maintenant ainsi l'idempotence.

  4. Exécutez le playbook de nettoyage.

    ansible-playbook -i inventory.ini cleanup.yml

    La sortie montrera que chaque tâche a réussi à apporter une modification en supprimant un fichier.

    PLAY [Clean up managed files from the system] **********************************

TASK [Gathering Facts] *********************************************************
ok: [localhost]

TASK [Remove the temporary info file] ******************************************
changed: [localhost]

TASK [Remove the custom MOTD file] *********************************************
changed: [localhost]

TASK [Remove the custom issue file] ********************************************
changed: [localhost]

TASK [Remove the issue.net symbolic link] **************************************
changed: [localhost]

PLAY RECAP *********************************************************************
localhost                  : ok=5    changed=4    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

  5. Vérifiez que les fichiers ont été supprimés. Vous pouvez utiliser la commande ls pour vérifier leur existence. La commande signalera qu'elle ne peut pas y accéder car ils ont disparu.

    ls /tmp/info.txt /etc/motd /etc/issue /etc/issue.net

    La sortie attendue est une série d'erreurs, confirmant que le nettoyage a réussi.

    ls: cannot access '/tmp/info.txt': No such file or directory
ls: cannot access '/etc/motd': No such file or directory
ls: cannot access '/etc/issue': No such file or directory
ls: cannot access '/etc/issue.net': No such file or directory

Vous avez maintenant utilisé avec succès Ansible pour supprimer des fichiers et nettoyer un système, complétant ainsi le cycle de vie complet de la gestion des fichiers, de la création à la suppression.

Résumé

Dans ce laboratoire, vous avez appris les bases de la gestion de fichiers sur les systèmes RHEL à l'aide d'Ansible. Vous avez commencé par utiliser le module ansible.builtin.copy pour transférer un fichier statique vers un hôte géré tout en définissant des propriétaires et des permissions spécifiques. Vous avez ensuite exploré comment modifier des fichiers existants en vous assurant qu'une ligne spécifique est présente avec lineinfile et en gérant des blocs de texte multilignes avec blockinfile. Une compétence clé abordée a été la génération de contenu de fichier dynamique à l'aide du module ansible.builtin.template et de la syntaxe Jinja2 pour créer un Message du Jour (MOTD) personnalisé rempli de faits système.

De plus, vous vous êtes exercé à déployer des fichiers de support et à créer des liens symboliques à l'aide du module ansible.builtin.file. Pour garantir le succès de vos déploiements, vous avez utilisé le module stat pour vérifier l'état et les attributs des fichiers, et le module fetch pour récupérer des fichiers, tels que des journaux, de l'hôte géré vers le nœud de contrôle. Enfin, vous avez appris à effectuer des opérations de nettoyage en utilisant le module file avec state: absent pour supprimer les fichiers et répertoires créés tout au long du laboratoire, garantissant ainsi un état propre sur l'hôte géré.

Connexe Ansible Cours
Laboratoires de Certification Red Hat Enterprise Linux Automation avec Ansible (RH294)

Laboratoires de Certification Red Hat Enterprise Linux Automation avec Ansible (RH294)

rhelansiblelinux
Ansible pour les Débutants

Ansible pour les Débutants

ansibledevopslinux