Modules Utilitaires Ansible

Ansible propose de nombreux modules utilitaires qui facilitent la gestion dynamique des inventaires, la collecte d’informations système, la synchronisation des tâches, le débogage et la gestion des connexions. Ces modules sont essentiels pour écrire des playbooks robustes, adaptatifs et faciles à maintenir.

Le module ansible pause

Le module pause permet de mettre en pause l’exécution d’un playbook, soit pour un temps donné, soit en attendant une intervention humaine.

Pause de quelques secondes

- name: Pause de 10 secondes
  ansible.builtin.pause:
    seconds: 10

Pause avec message et confirmation

- name: Pause avec confirmation utilisateur
  ansible.builtin.pause:
    prompt: "Appuyez sur Entrée pour continuer le déploiement"

Le module ansible debug

Le module debug affiche des messages de débogage ou la valeur de variables dans la sortie du playbook. Il est très utile pour comprendre le déroulement d’un playbook ou inspecter des variables.

Afficher un message simple

- name: Afficher un message de debug
  ansible.builtin.debug:
    msg: "Déploiement terminé avec succès"

Afficher la valeur d’une variable

- name: Afficher la valeur d’une variable
  ansible.builtin.debug:
    var: ansible_facts['hostname']

Afficher plusieurs variables

- name: Afficher plusieurs variables
  ansible.builtin.debug:
    msg:
      - "Utilisateur : {{ ansible_user }}"
      - "Adresse IP : {{ ansible_default_ipv4.address }}"

Le module ansible add_host

Le module add_host permet d’ajouter dynamiquement des hôtes à l’inventaire en cours d’exécution. Il est utile pour construire des workflows dynamiques, par exemple pour générer des listes d’hôtes cibles à partir de résultats d’une tâche précédente.

Ajout d’un hôte simple

- name: Ajouter dynamiquement un hôte à l’inventaire
  ansible.builtin.add_host:
    name: web01
    groups: webservers
    ansible_host: 192.168.1.10

Ici, l’hôte web01 est ajouté au groupe webservers avec une adresse IP spécifique.

Ajout de plusieurs hôtes avec variables

- name: Ajouter plusieurs hôtes à un groupe
  ansible.builtin.add_host:
    name: "{{ item }}"
    groups: dynamic_group
  loop:
    - host1
    - host2

Dans cet exemple, deux hôtes (host1 et host2) sont ajoutés au groupe dynamic_group.

Utilisation avancée : ajout d’hôtes avec variables personnalisées

Il est également possible d’ajouter des hôtes avec des variables spécifiques pour chaque hôte. Cela permet de personnaliser les configurations selon les besoins.

- name: Ajouter un hôte avec variables personnalisées
  ansible.builtin.add_host:
    name: db01
    groups: databases
    db_port: 5432
    db_user: admin

Le module ansible group_by

Le module group_by permet de créer dynamiquement des groupes d’hôtes en fonction de faits collectés (facts). Cela facilite l’exécution conditionnelle de tâches selon les caractéristiques des hôtes.

Création de groupes selon le système d’exploitation

- name: Grouper les hôtes par OS
  ansible.builtin.group_by:
    key: "os_{{ ansible_facts['os_family'] }}"

Les hôtes seront regroupés dans des groupes comme Debian, RedHat, etc.

Grouper selon une caractéristique personnalisée

- name: Grouper par nombre de CPU
  ansible.builtin.group_by:
    key: "cpu_{{ ansible_facts['processor_cores'] }}"

Ici, les hôtes seront regroupés selon le nombre de cœurs de processeur.

Le module ansible setup

Le module setup permet de collecter automatiquement des informations détaillées sur les hôtes distants (appelées “facts”), telles que le système d’exploitation, la mémoire, les interfaces réseau, etc. Grâce à ses options avancées, il est possible de limiter la collecte à certains types de faits, d’exclure des catégories ou de ne récupérer que des informations précises, ce qui optimise les performances et la confidentialité lors de l’exécution des playbooks.

Collecte de tous les faits

- name: Collecter tous les facts
  ansible.builtin.setup:

Collecte sélective de facts

Si le paramètre filter est fourni, il restreint les faits additionnels collectés au sous-ensemble spécifié. Valeurs possibles : all, all_ipv4_addresses, all_ipv6_addresses, apparmor, architecture, caps, chroot, cmdline, date_time, default_ipv4, default_ipv6, devices, distribution, distribution_major_version, distribution_release, distribution_version, dns, effective_group_ids, effective_user_id, env, facter, fips, hardware, interfaces, is_chroot, iscsi, kernel, local, lsb, machine, machine_id, mounts, network, ohai, os_family, pkg_mgr, platform, processor, processor_cores, processor_count, python, python_version, real_user_id, selinux, service_mgr, ssh_host_key_dsa_public, ssh_host_key_ecdsa_public, ssh_host_key_ed25519_public, ssh_host_key_rsa_public, ssh_host_pub_keys, ssh_pub_keys, system, system_capabilities, system_capabilities_enforced, systemd, user, user_dir, user_gecos, user_gid, user_id, user_shell, user_uid, virtual, virtualization_role, virtualization_type.

Il est possible de spécifier une liste de valeurs pour collecter un sous-ensemble plus large. Les valeurs peuvent aussi être précédées d’un point d’exclamation (!) pour indiquer que ce sous-ensemble ne doit pas être collecté. Par exemple : !hardware,!network,!virtual,!ohai,!facter. Si !all est spécifié, seul le sous-ensemble minimal est collecté. Pour éviter de collecter même ce sous-ensemble minimal, utilisez !all,!min. Pour ne collecter que certains faits spécifiques, combinez !all,!min et indiquez les sous-ensembles désirés. Utilisez le paramètre filter si vous souhaitez masquer certains faits collectés.

Exemples d’utilisation avancée :

• Collecter uniquement les faits sur le matériel et le système :

  - name: Collecter uniquement les faits matériels et système
    ansible.builtin.setup:
      gather_subset:
        - hardware
        - system

• Exclure la collecte des faits réseau et de virtualisation :

  - name: Exclure les faits réseau et virtualisation
    ansible.builtin.setup:
      gather_subset:
        - '!network'
        - '!virtual'

• Collecter uniquement un sous-ensemble minimal :

  - name: Collecter uniquement le minimum de facts
    ansible.builtin.setup:
      gather_subset:
        - '!all'
        - 'min'

Cela permet d’adapter la collecte d’informations à vos besoins et d’accélérer l’exécution de vos playbooks.

Le module ansible wait_for

Le module wait_for permet d’attendre qu’un port soit ouvert, qu’un fichier existe, ou qu’une condition soit remplie avant de poursuivre l’exécution du playbook. Il est très utile pour synchroniser des tâches, par exemple attendre qu’un service démarre, qu’un fichier soit créé ou supprimé, ou qu’un port réseau soit disponible.

La valeur par défaut de timeout est de 5 secondes, mais elle peut être ajustée selon les besoins. Si la condition n’est pas remplie dans le délai imparti, la tâche échoue.

Attendre qu’un port soit ouvert

- name: Attendre que le port 80 soit ouvert
  ansible.builtin.wait_for:
    port: 80
    host: 127.0.0.1
    timeout: 30

Dans cet exemple, la tâche attend que le port 80 soit ouvert sur l’hôte local pendant 30 secondes maximum.

Attendre la présence d’un fichier

- name: Attendre qu’un fichier soit créé
  ansible.builtin.wait_for:
    path: /tmp/ready.flag
    state: present
    timeout: 60

Ici, la tâche attend que le fichier /tmp/ready.flag existe avant de continuer.

Attendre la disparition d’un fichier

- name: Attendre qu’un fichier soit supprimé
  ansible.builtin.wait_for:
    path: /tmp/lockfile
    state: absent
    timeout: 120

Dans cet exemple, la tâche attend que le fichier /tmp/lockfile soit supprimé.

Attendre une chaîne de caractères dans un fichier

Il est possible d’attendre qu’un fichier contienne une chaîne spécifique grâce au paramètre search_regex :

- name: Attendre qu'un fichier contienne une chaîne précise
  ansible.builtin.wait_for:
    path: /var/log/app.log
    search_regex: "Service démarré"
    timeout: 60

Attendre un délai précis avant de continuer

Le paramètre delay permet de définir un temps d’attente avant de commencer les vérifications :

- name: Attendre 10 secondes avant de vérifier le port
  ansible.builtin.wait_for:
    port: 443
    delay: 10
    timeout: 60

Utilisation avancée

• Attendre qu’un port soit fermé : utilisez state: drained pour attendre que toutes les connexions soient fermées (utile lors de l’arrêt d’un service).
• Attendre sur une socket UNIX : utilisez le paramètre path pour surveiller la création d’un socket local.
• Répétition des vérifications : le paramètre sleep permet de définir l’intervalle entre chaque tentative (par défaut 1 seconde).

Résumé des principaux paramètres

• port : numéro de port à surveiller (TCP).
• host : adresse IP ou nom d’hôte (par défaut localhost).
• path : chemin du fichier ou du socket à surveiller.
• state : present (existe), absent (n’existe pas), started (port ouvert), stopped (port fermé), drained (toutes les connexions fermées).
• search_regex : chaîne ou expression régulière à rechercher dans un fichier.
• delay : délai avant la première vérification.
• sleep : intervalle entre chaque vérification.
• timeout : durée maximale d’attente.

Le module wait_for est donc un outil polyvalent pour orchestrer des scénarios d’attente dans vos playbooks Ansible, que ce soit pour la gestion de services, de fichiers ou de ports réseau.

Le module ansible wait_for_connection

Le module wait_for_connection attend que la connexion SSH (ou WinRM) soit disponible avant de poursuivre l’exécution du playbook. Il est particulièrement utile après un redémarrage, lors du provisionnement d’une machine virtuelle ou d’un cloud, ou pour s’assurer qu’un hôte est bien prêt avant d’exécuter des tâches.

Ce module tente de se connecter à l’hôte cible en utilisant la méthode de connexion définie (par défaut SSH). Il effectue des tentatives répétées jusqu’à ce que la connexion soit possible ou que le délai maximal soit atteint.

Attendre la connexion SSH

- name: Attendre que la connexion SSH soit disponible
  ansible.builtin.wait_for_connection:
    delay: 5
    timeout: 120
    sleep: 2

• delay : temps d’attente avant la première tentative (en secondes)
• timeout : durée maximale d’attente (en secondes)
• sleep : intervalle entre chaque tentative de connexion (par défaut 1 seconde)

Utilisations avancées

• Personnaliser le port ou l’utilisateur : vous pouvez utiliser les variables d’inventaire ansible_port ou ansible_user pour cibler un port ou un utilisateur spécifique lors de la connexion.
• Utiliser avec d’autres méthodes de connexion : fonctionne aussi avec WinRM, local, etc., selon la configuration de l’hôte.
• Gestion des erreurs : si la connexion n’est pas possible dans le délai imparti, la tâche échoue et le playbook s’arrête (sauf si ignoré).

Exemple d’attente après un redémarrage

- name: Redémarrer le serveur
  ansible.builtin.reboot:

- name: Attendre que la connexion SSH revienne
  ansible.builtin.wait_for_connection:
    delay: 10
    timeout: 300

Ce module est donc essentiel pour fiabiliser les déploiements automatisés, notamment dans les scénarios cloud, CI/CD ou lors de la gestion de clusters, en garantissant que les hôtes sont bien accessibles avant de poursuivre les opérations.

Contrôle de connaissances

Pourquoi ce contrôle ?

Cet contrôle va vous permettre de valider vos connaissances sur le sujet abordé dans le guide. Il comporte des QCM, des questions vrai/faux et des réponses ouvertes à un mot.

🕒 Le chronomètre commence dès que vous cliquez sur Démarrer le test. Vous devrez terminer l’examen avant la fin du temps imparti.

🎯 Pour réussir, vous devez obtenir au moins 80% de bonnes réponses.

💡 Je ne fournis pas directement les réponses aux questions. Cependant, si certaines sont complexes, des pistes d’explication pourront être proposées dans le guide ou après l’examen.

Bonne chance ! 🚀

Démarrer le test

Temps restant :

Conclusion

L’utilisation de ces modules utilitaires permet de rendre vos playbooks Ansible plus dynamiques, robustes et interactifs. Que ce soit pour gérer l’inventaire à la volée, adapter les tâches selon l’environnement, synchroniser les étapes ou faciliter le débogage, ils sont incontournables pour l’automatisation avancée.