Ansible — Les fondamentaux : inventaire, playbooks, rôles

Objectifs de la fiche

• Comprendre l'architecture et le vocabulaire Ansible.
• Écrire un inventaire et un playbook idempotent.
• Utiliser variables, templates, handlers et rôles.
• Exécuter sans risque (--check --diff, --limit) et éviter les pièges classiques.

Le vocabulaire en 1 tableau

Architecture : comment ça s’exécute

À chaque tâche, Ansible copie un petit module sur la cible, l'exécute, récupère un résultat JSON puis nettoie. Le statut retourné est l'un de :

L’inventaire

Il décrit qui est géré. Format YAML (ou INI), statique ou dynamique (plugins Azure, vSphere, etc. qui interrogent l'API à chaque exécution).

inventory/hosts.yml

all:
  children:
    vda_linux:
      hosts:
        vda-ubuntu01:
        vda-ubuntu02:
      vars:
        ansible_user: ansible
    storefront:
      hosts:
        srv-sf01:
          ansible_host: 10.0.10.21
      vars:
        ansible_connection: winrm
        ansible_winrm_transport: kerberos
        ansible_port: 5986

Anatomie d’un playbook

playbooks/vda_linux.yml

---
- name: Configurer les VDA Linux
  hosts: vda_linux
  become: true                      # sudo
  vars:
    ad_domain: corp.local
  tasks:
    - name: Installer sssd, realmd et Kerberos
      ansible.builtin.apt:
        name: [sssd, realmd, krb5-user]
        state: present              # état voulu, pas une action
        update_cache: true

    - name: Déployer sssd.conf depuis un template Jinja2
      ansible.builtin.template:
        src: sssd.conf.j2
        dest: /etc/sssd/sssd.conf
        owner: root
        mode: "0600"
      notify: Redémarrer sssd       # seulement si le fichier change

  handlers:
    - name: Redémarrer sssd
      ansible.builtin.service:
        name: sssd
        state: restarted

Variables, templates et précédence

Les variables s'écrivent {{ ma_variable }} (moteur Jinja2), dans les tâches comme dans les templates .j2. Quand la même variable est définie à plusieurs endroits, la plus « proche » de l'exécution gagne :

Rôles et collections

Un rôle est une arborescence normalisée que l'on réutilise d'un projet à l'autre ; on le crée avec ansible-galaxy role init linux_vda.

structure d'un rôle

roles/linux_vda/
├── defaults/main.yml     # variables par défaut (priorité basse)
├── vars/main.yml         # constantes du rôle
├── tasks/main.yml        # point d'entrée des tâches
├── handlers/main.yml     # handlers
├── templates/sssd.conf.j2
├── files/                # fichiers copiés tels quels
└── meta/main.yml         # dépendances, plateformes

Les collections apportent les modules hors cœur. On les déclare dans collections/requirements.yml puis ansible-galaxy collection install -r collections/requirements.yml. Toujours appeler un module par son FQCN (ansible.windows.win_feature plutôt que win_feature).

Cibles Windows : les différences

Commandes essentielles

Pièges classiques

À retenir

• Agentless, push, SSH/WinRM : seul le nœud de contrôle a Ansible.
• On décrit un état ; un bon playbook rejoué donne changed=0.
• Inventaire = qui · Playbook = quoi · Rôle = comment le réutiliser.
• --check --diff et --limit avant toute exécution en production.
• Secrets dans ansible-vault, modules appelés par leur FQCN.

Auto-évaluation

Pour aller plus loin

• Documentation officielle Ansible
• Précédence des variables (référence complète)
• Ansible sur Windows
• Ansible Galaxy (rôles et collections)
• ansible-lint