IaC (5/6) — Ansible : inventaire, playbook & idempotence

L’idée reçue

« Ansible, c’est juste des scripts bash mieux rangés. »

Non — et la différence est fondamentale. Un script bash exécute des commandes ; Ansible vise un état. Relancer un script peut casser ; relancer un playbook Ansible ne change rien si l’état est déjà bon. Ce comportement — l’idempotence — est ce qui rend la configuration fiable et répétable.

On travaille depuis mgmt. Point fort d’Ansible : il est agentless — rien à installer sur les machines cibles, il passe par SSH (celui-là même que cloud-init a configuré au module précédent).

À la fin de ce module, tu sauras…

Installer Ansible et comprendre son modèle agentless (push, via SSH)
Décrire tes machines dans un inventaire
Écrire un playbook qui installe et configure
Comprendre et prouver l’idempotence

01Installer Ansible

Expérience 1

Sur mgmt, le poste de pilotage

Manipule

sudo apt update &amp;&amp; sudo apt install -y ansible
ansible --version

Observe

ansible [core 2.x.x]
python version = 3.x.x

Ansible s’installe uniquement sur mgmt (la machine de contrôle). Les cibles, elles, n’ont besoin de rien de plus que SSH et Python — déjà présents sur une Debian standard.

Comprends agentless & push, un choix d’architecture

Beaucoup d’outils de config exigent un agent installé sur chaque machine. Ansible est agentless : la machine de contrôle pousse la configuration via SSH. Moins de composants à gérer, rien à maintenir sur les cibles. Le modèle est push (mgmt agit sur les cibles), là où d’autres outils sont pull (l’agent va chercher sa config). Concept indépendant : c’est un axe de comparaison universel entre outils de configuration.

02L’inventaire : décrire les cibles

Expérience 2

Qui Ansible doit-il configurer ?

Crée un dossier et un fichier inventory.ini décrivant tes VMs (celles créées par Terraform) :

Manipule

mkdir -p ~/ansible-soria &amp;&amp; cd ~/ansible-soria
cat &gt; inventory.ini &lt;&lt;'EOF'
[workers]
worker-1 ansible_host=192.168.10.61
worker-2 ansible_host=192.168.10.62

[all:vars]
ansible_user=soria
ansible_ssh_private_key_file=~/.ssh/id_ed25519
EOF

Teste la connectivité avec le module ping :

Manipule

ansible -i inventory.ini workers -m ping

Observe

worker-1 | SUCCESS =&gt; { "ping": "pong" }
worker-2 | SUCCESS =&gt; { "ping": "pong" }

Ansible a joint les deux VMs par SSH (clé injectée par cloud-init au module 7.4). L’inventaire regroupe et nomme tes cibles ; ici, un groupe workers.

Comprends groupes & le module ping

L’inventaire organise les machines en groupes ([workers]) : tu appliqueras une config à tout un groupe d’un coup. -m ping n’est pas un ping réseau : c’est un module qui vérifie qu’Ansible peut se connecter et exécuter du Python sur la cible. Un « pong » prouve que le canal de configuration est ouvert.

03Le premier playbook

Expérience 3

Installer Docker, en YAML déclaratif

Crée docker.yml — un playbook qui installe Docker sur les workers :

Manipule

- name: Installer Docker sur les workers
hosts: workers
become: true
tasks:
  - name: Paquets prerequis
    apt:
      name: [ca-certificates, curl, gnupg]
      state: present
      update_cache: true

  - name: Cle GPG Docker
    apt_key:
      url: https://download.docker.com/linux/debian/gpg
      keyring: /etc/apt/keyrings/docker.gpg
      state: present

  - name: Depot Docker
    apt_repository:
      repo: "deb [signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/debian trixie stable"
      state: present

  - name: Installer le moteur Docker
    apt:
      name: [docker-ce, docker-ce-cli, containerd.io]
      state: present

Manipule

ansible-playbook -i inventory.ini docker.yml

Observe

PLAY [Installer Docker sur les workers] ...
TASK [Installer le moteur Docker] ...
changed: [worker-1]
changed: [worker-2]

PLAY RECAP
worker-1 : ok=5  changed=4  unreachable=0  failed=0
worker-2 : ok=5  changed=4  unreachable=0  failed=0

Docker est installé sur les deux workers, en une commande. Reconnais-tu les étapes ? C’est ta chaîne de confiance de la Phase 3 (clé GPG, dépôt, moteur) — désormais déclarée, pas tapée.

Comprends tasks, modules, become, state

Un playbook est une liste de tasks, chacune utilisant un module (apt, apt_key…). become: true = exécuter en root (sudo). Le mot clé state: present est déclaratif : « je veux que ce paquet soit installé » — pas « lance apt install ». Ansible vérifie l’état actuel et n’agit que si nécessaire. C’est la porte vers l’idempotence.

04Le concept clé : l’idempotence

Expérience 4

Relance le même playbook — et observe

Manipule

ansible-playbook -i inventory.ini docker.yml

Observe

PLAY RECAP
worker-1 : ok=5  changed=0  unreachable=0  failed=0
worker-2 : ok=5  changed=0  unreachable=0  failed=0

Cette fois : changed=0. Ansible a tout vérifié, constaté que l’état voulu était déjà atteint, et n’a rien refait. Compare avec le premier passage (changed=4). C’est ça, l’idempotence.

Comprends idempotence, et pourquoi c’est décisif

Idempotent = appliquer plusieurs fois donne le même résultat qu’une fois. Un script bash apt install relancé refait le travail (ou échoue) ; un playbook vérifie d’abord, agit seulement si l’état diffère. Tu peux donc relancer un playbook en toute sécurité, à tout moment — pour corriger un drift, ajouter une machine, garantir la conformité. C’est le même esprit « viser un état » que Terraform et Kubernetes, appliqué à la configuration interne des machines.

✓Ce que tu retiens

Ansible configure l’intérieur des machines, sans agent (push via SSH). L’inventaire décrit et groupe les cibles ; le playbook (YAML) déclare des tasks qui visent un état (state: present). Grâce à l’idempotence, relancer un playbook ne change que ce qui doit l’être — la config devient fiable, répétable, et corrige le drift.

Mini-projet

Configure tes workers

À faire

Installe Ansible sur mgmt et écris l’inventaire de tes VMs.
Prouve la connectivité avec -m ping.
Écris et lance le playbook d’installation de Docker.
Relance-le et prouve changed=0 (idempotence).
Ajoute une task (ex. démarrer et activer le service docker avec le module service) et relance.
Documente dans BookStack : agentless/push, inventaire, task/module/state, idempotence.

Fil rouge — Un playbook unique devient vite long et mêlé. Pour organiser une vraie configuration (Docker, K3s, monitoring…) et la rendre réutilisable, on structure en rôles. Et surtout, on relie enfin les deux outils : au dernier module, Terraform crée les VMs, Ansible les configure, en une chaîne.

?Auto-évaluation

1. Que signifie « Ansible est agentless » ?

Rien à installer sur les cibles : la machine de contrôle pousse la configuration via SSH. Les cibles n’ont besoin que de SSH et Python.

2. Qu’est-ce que l’idempotence ?

Appliquer plusieurs fois donne le même résultat qu’une seule. Ansible vérifie l’état et n’agit que s’il diffère de l’état voulu (changed=0 si rien à faire).

3. En quoi state: present est-il déclaratif ?

On déclare que le paquet doit être présent, pas la commande à lancer. Ansible vérifie et n’installe que s’il manque.