IaC (6/6) — Ansible : rôles & la chaîne complète

L’idée reçue

« Un gros playbook avec toutes mes tâches, c’est suffisant. »

Au début, oui. Mais quand tu configures Docker, K3s, le monitoring, les utilisateurs… un playbook géant devient illisible et non réutilisable. Les rôles découpent la configuration en briques autonomes et partageables. Et surtout : on va enfin relier Terraform et Ansible en une seule chaîne.

À la fin de ce module, tu sauras…

Structurer une configuration en rôles réutilisables
Appeler des rôles depuis un playbook lisible
Relier Terraform et Ansible (provisioning → configuration)
Voir la chaîne IaC complète, de la VM vide au logiciel installé

01Pourquoi des rôles

Un playbook unique mélange tout. Un rôle regroupe, dans une structure standard, tout ce qui concerne une responsabilité (installer Docker, configurer K3s…) : ses tasks, ses fichiers, ses variables, ses templates.

Comprends la structure d’un rôle

Un rôle a des dossiers conventionnels : tasks/ (les étapes), templates/ (fichiers de config paramétrés), handlers/ (actions déclenchées, ex. redémarrer un service), defaults/ (variables par défaut). Cette convention rend un rôle autonome et réutilisable : on peut le partager, le versionner, le réemployer sur un autre projet — voire en télécharger depuis Ansible Galaxy. C’est l’équivalent, côté configuration, d’un module réutilisable.

02Créer un rôle

Expérience 1

Extraire Docker dans un rôle

Manipule

cd ~/ansible-soria
ansible-galaxy init roles/docker
ls roles/docker

Observe

defaults  files  handlers  meta  tasks  templates  vars

Place la logique d’installation dans roles/docker/tasks/main.yml (les mêmes tasks qu’au module précédent). Le playbook, lui, devient minimal :

Manipule

cat &gt; site.yml &lt;&lt;'EOF'
- name: Configurer les workers
hosts: workers
become: true
roles:
  - docker
EOF
ansible-playbook -i inventory.ini site.yml

Le playbook site.yml ne dit plus comment installer Docker, seulement qu’il faut le rôle docker. Lisible, et prêt à accueillir d’autres rôles (k3s, monitoring…).

Comprends playbook = intention, rôle = implémentation

Le playbook exprime l’intention (« ces machines ont besoin de docker et k3s ») ; les rôles contiennent l’implémentation. Cette séparation — comme un sommaire qui renvoie à des chapitres — rend la configuration compréhensible d’un coup d’œil et réutilisable brique par brique. Ajouter une capacité = ajouter un rôle à la liste.

03Le chaînon manquant : Terraform → Ansible

Jusqu’ici, tu as écrit l’inventaire Ansible à la main, avec les IP que Terraform a créées. C’est le point de jonction des deux outils — et on peut l’automatiser.

Comprends la frontière et le passage de relais

Rappel des rôles : Terraform provisionne (crée les VMs, connaît leurs IP), Ansible configure (a besoin de ces IP dans son inventaire). Le passage de relais = transmettre les IP de Terraform vers l’inventaire Ansible. On peut le faire à la main (simple, explicite) ou l’automatiser en générant l’inventaire depuis les outputs Terraform (module 7.4). L’idée universelle : la sortie du provisioning alimente l’entrée de la configuration.

04Générer l’inventaire depuis Terraform

Expérience 2

Un output structuré qui devient l’inventaire

Côté Terraform, expose les IP de la flotte en output (à partir du for_each du module 7.4) :

Manipule

output "workers_inventory" {
value = { for name, vm in proxmox_virtual_environment_vm.fleet : name =&gt; vm.ipv4_addresses }
}

Puis génère un inventaire Ansible à partir des données Terraform :

Manipule

cd ~/iac-soria
terraform output -json workers_inventory &gt; /tmp/tf_workers.json
# transformer en inventaire (script simple, ou inventaire dynamique)

Terraform, source de vérité des IP, alimente l’inventaire Ansible. Plus de recopie manuelle : quand Terraform ajoute une VM, elle apparaît dans l’inventaire, et Ansible la configure.

Comprends inventaire statique vs dynamique

Un inventaire statique (le .ini écrit à la main) est simple et suffisant pour un parc stable. Un inventaire dynamique se génère automatiquement depuis une source (ici Terraform, ou directement l’API du cloud). Pour un projet qui évolue, le dynamique évite les oublis. Le principe — la vérité de l’infra vient d’une source unique — vaut sur tout provider : sur AWS, un plugin d’inventaire dynamique interroge l’API pour lister les instances.

05La chaîne complète, en action

Expérience 3

De zéro à une machine opérationnelle, en deux temps

Manipule

# 1. PROVISIONING — Terraform crée les VMs
cd ~/iac-soria
terraform apply

# 2. CONFIGURATION — Ansible les équipe
cd ~/ansible-soria
ansible-playbook -i inventory.ini site.yml

Observe

Deux commandes, deux étapes, deux outils : les VMs naissent (Terraform) puis sont équipées (Ansible). Tu peux détruire tout (terraform destroy) et tout reconstruire à l’identique quand tu veux. Ton infrastructure est désormais entièrement décrite en code.

Comprends ce que tu viens d’accomplir

Tu as bouclé l’IaC : Terraform (la coquille : VMs, réseau, via un provider interchangeable) → Ansible (le contenu : Docker, K3s, config, idempotent). Toute l’infrastructure des phases 0-2, montée à la main au début du parcours, peut maintenant être recréée par du code versionné. C’est l’aboutissement : une infrastructure reproductible, documentée par sa propre définition, et portable dans son principe vers n’importe quel cloud.

✓Ce que tu retiens

Les rôles structurent la configuration en briques réutilisables ; le playbook exprime l’intention, les rôles l’implémentation. La chaîne IaC relie les deux outils : Terraform provisionne (et expose les IP en outputs) → Ansible configure (via un inventaire, statique ou généré). Ton infrastructure entière — de la VM vide au logiciel installé — est désormais du code reproductible.

Mini-projet — clôture de la Phase 7

Ton infrastructure, entièrement en code

À faire

Transforme ton playbook Docker en rôle docker, appelé depuis site.yml.
Ajoute un second rôle (ex. un rôle base : utilisateurs, mises à jour, paquets communs).
Expose les IP des VMs en output Terraform.
Enchaîne la chaîne complète : terraform apply puis ansible-playbook site.yml.
Détruis tout, puis reconstruis à l’identique — prouve la reproductibilité.
Documente dans BookStack : rôles, chaîne Terraform→Ansible, inventaire statique vs dynamique.

Fil rouge — Ton infrastructure est reproductible, ton application livrée en continu. Une dernière question demeure : quand quelque chose ralentit ou tombe à 3 h du matin, comment le sais-tu, et pourquoi ? À la Phase 8, on met en place la supervision : métriques, logs, tableaux de bord et alertes.

?Auto-évaluation

1. Qu’apporte un rôle par rapport à un gros playbook ?

Il regroupe tout ce qui concerne une responsabilité (tasks, templates, variables) en une brique autonome et réutilisable. Le playbook n’exprime plus que l’intention.

2. Comment Terraform et Ansible se relient-ils ?

Terraform provisionne les VMs et connaît leurs IP (outputs) ; ces IP alimentent l’inventaire d’Ansible, qui configure ensuite les machines. Provisioning → configuration.

3. Différence entre inventaire statique et dynamique ?

Statique : écrit à la main, simple pour un parc stable. Dynamique : généré automatiquement depuis une source (Terraform, API cloud), il évite les oublis quand l’infra évolue.