3.2 : Tasks et modules : la logique verbe-nom

En 3.1, on a écrit notre première tâche avec le module ping. Mais Ansible propose des centaines de modules différents. Comment s’y retrouver, et surtout, comment choisir le bon plutôt que de tout faire à coups de command ou shell ?

Un module, c’est une action déjà pensée pour vous

Repensez à la commande apt qu’on a utilisée en 1.4 :

- name: Installer curl
  ansible.builtin.apt:
    name: curl
    state: present

Comparez avec ce qu’on aurait pu écrire « à la main » :

- name: Installer curl (mauvaise pratique)
  ansible.builtin.shell: apt install -y curl

Les deux installent curl. Mais seule la première version sait dire si curl était déjà installé, et ne fait donc rien s’il l’est déjà. La seconde relance apt install à chaque exécution, que ce soit utile ou non — on retombe dans les travers d’un simple script shell qu’on a évoqués dans l’intro de cette formation.

C’est toute la différence entre utiliser un module dédié et utiliser une commande brute : le module connaît l’état voulu, la commande brute ne connaît que l’action à exécuter.

La logique « state » : décrire un résultat, pas une action

La plupart des modules Ansible suivent une logique commune, portée par un paramètre state : vous décrivez l’état final voulu, pas la suite d’étapes pour y arriver.

- name: Le paquet doit être présent
  ansible.builtin.apt:
    name: curl
    state: present

- name: Le service doit tourner
  ansible.builtin.service:
    name: apache2
    state: started

- name: Ce fichier ne doit plus exister
  ansible.builtin.file:
    path: /tmp/vieux_fichier.txt
    state: absent

Peu importe l’état actuel de la machine : Ansible compare, et n’agit que si nécessaire. C’est exactement la logique déclarative posée en 1.1, appliquée concrètement à chaque module.

Les modules à connaître en priorité

Pour débuter, une poignée de modules couvre déjà l’essentiel du quotidien :

On les retrouvera concrètement tout au long des prochaines sections.

Enchaîner plusieurs tâches

Un play contient généralement plusieurs tâches, exécutées les unes après les autres :

---
- name: Installer et démarrer Apache
  hosts: webservers
  become: yes
  tasks:
    - name: Installer Apache
      ansible.builtin.apt:
        name: apache2
        state: present
        update_cache: yes

    - name: Démarrer et activer Apache
      ansible.builtin.service:
        name: apache2
        state: started
        enabled: yes

Remarquez become: yes au niveau du play : ça revient à ajouter --become en ligne de commande, mais directement dans le fichier, pour que toutes les tâches du play en profitent sans avoir à le répéter à chaque fois. On reverra become plus en détail en section 8.

Et update_cache: yes dans la tâche apt : l’équivalent de apt update avant l’installation, pour être sûr que la liste des paquets disponibles est à jour avant de chercher apache2.

Trouver le bon module

Deux réflexes à prendre dès maintenant :

# Chercher un module par mot-clé
ansible-doc -l | grep user

# Afficher la documentation complète d'un module, avec des exemples
ansible-doc ansible.builtin.apt

ansible-doc fonctionne hors ligne, directement depuis votre terminal — pas besoin d’aller chercher sur le web à chaque fois que vous hésitez sur un paramètre.

Ce qu’il faut retenir

• Un module bien choisi connaît l’état de la machine et n’agit que sur l’écart — une commande brute (shell, command) ne le sait jamais.
• La logique state: present/absent/started/stopped revient dans la majorité des modules.
• ansible-doc est votre meilleur réflexe pour trouver et comprendre un module, directement en local.

Dans la prochaine leçon, on prend le temps de vraiment détailler l’idempotence — le concept qu’on a effleuré plusieurs fois déjà, et qui mérite qu’on s’y arrête sérieusement.