Ansible : playbooks, inventory et Vault (hub 2026)
À la fin de cette page pilier, vous saurez pourquoi Ansible (push SSH, pas d’agent), installer le control node sur Ubuntu 24.04, écrire un inventaire et un playbook idempotent, ranger les secrets dans Vault, puis suivre le parcours live jusqu’aux rôles.
Niveau : Débutant → Intermédiaire · Temps estimé : 50–70 min · Versions cibles : Ansible Core 2.16+ / 2.18 · Ubuntu 24.04 LTS · Dernière vérification : 2026-09-13
Prérequis
- Une machine de contrôle (Linux, macOS ou WSL) avec Python 3.10+
- Une ou plusieurs cibles Linux joignables en SSH, utilisateur avec sudo
- Bases YAML — leçon syntaxe YAML
- Coût estimé : 0 € en lab
Ce hub traduit et densifie le contenu live anglais (modèle agentless, install, ping, premier playbook, carte des leçons) en français pédagogique, sans supprimer les commandes utiles. Terraform crée souvent les VMs ; Ansible les configure. Puppet, au menu suivant, montre l’autre contrat (agent + catalog).
Ce que nous allons construire
Hub Ansible (menu DevOps)
├── Pourquoi Ansible vs Puppet / Terraform
├── Install control node (pipx) + inventory + ping
├── Premier playbook (apt, template, service, handler)
├── Carte du parcours live
├── Erreurs fréquentes + FAQ (5)
└── Pont Jenkins / Capstone / Kubernetes
Étape 1 — Pourquoi Ansible en 2026
Ansible automatise des serveurs sans agent : le control node ouvre SSH, copie de petits modules Python, les exécute, les retire. L’inventaire liste hôtes et groupes. Les modules (apt, copy, service, user…) font le travail. L’idempotence : relancer le playbook ne casse pas une machine déjà conforme.
| Critère | Ansible | Puppet | Terraform |
|---|---|---|---|
| Agent | Non (SSH) | Oui (primary) | Non (API) |
| Langage | YAML + Jinja2 | DSL | HCL |
| Job | Configurer l’OS et les apps | Configurer / conformité | Provisionner l’infra |
| Modèle | Push, ordre des tâches | Pull, catalog | État + plan |
Choisir Ansible pour un changement ce soir, un lab, le Capstone (Java + Apache). Garder Puppet en tête pour les parcs agent et le reporting. Terraform pour créer/détruire les VMs — pas pour installer nginx.
Étape 2 — Installer le control node
Sur Ubuntu 24.04, pipx isole la release. Le PPA reste une alternative.
sudo apt update && sudo apt install -y pipx
pipx install --include-deps ansible
pipx inject ansible ansible-lint
ansible --version
Détail : installation. Intro vocabulaire : introduction.
Étape 3 — Inventaire, ping, commandes ad hoc
[web]
web1 ansible_host=192.168.56.11
web2 ansible_host=192.168.56.12
[db]
db1 ansible_host=192.168.56.21
[all:vars]
ansible_user=ubuntu
ansible_ssh_private_key_file=~/.ssh/lab_ed25519
ansible_python_interpreter=/usr/bin/python3
ansible -i inventory.ini all -m ping
ansible -i inventory.ini web -m apt -a "name=nginx state=present" --become
ansible -i inventory.ini all -a "uptime"
Leçons : inventory, ad-hoc. Testez d’abord ssh à la main si le ping échoue.
Étape 4 — Premier playbook
- name: Configure web servers
hosts: web
become: true
vars:
site_name: devops-lab
packages: [nginx, ufw]
tasks:
- name: Install packages
ansible.builtin.apt:
name: "{{ packages }}"
state: present
update_cache: true
- name: Deploy index
ansible.builtin.template:
src: templates/index.html.j2
dest: /var/www/html/index.html
mode: "0644"
notify: Reload nginx
- name: Ensure nginx running
ansible.builtin.service:
name: nginx
state: started
enabled: true
handlers:
- name: Reload nginx
ansible.builtin.service:
name: nginx
state: reloaded
ansible-playbook -i inventory.ini site.yml --check --diff
ansible-playbook -i inventory.ini site.yml
Deuxième run : changed=0 si vous êtes idempotent. Noms de modules entièrement qualifiés. Leçons : file module, Jinja, rôles, Vault, assignment.
Carte du parcours Ansible
- Introduction — architecture et vocabulaire
- Installation — control node
- YAML — playbooks lisibles
- Inventory — groupes et variables
- Ad-hoc — un module, pas de playbook
- File module et modules essentiels
- Jinja2 — templates
- Rôles — Galaxy, requirements
- Vault — secrets dans Git, chiffrés
- Assignment — tout relier
Où Ansible se branche dans la toolchain
Avec Terraform : les IPs sortent, un inventaire dynamique ou généré alimente Ansible. En CI : Jenkins lance ansible-playbook avec la clé en credentials, jamais dans Git. Pour les images : Dockerfile plutôt qu’Ansible dans le build Docker ; Packer + Ansible pour une AMI. À l’échelle : AWX / Automation Platform (UI, RBAC, audit). Sur le Capstone, Ansible installe Java et Apache sur la prod Linux (Ubuntu ou Red Hat via ansible_os_family). Kubernetes ne tue pas Ansible : nœuds, bastions, bases, réseau restent à configurer.
Habitudes qui évitent les snowflakes
Tournez --check --diff avant la prod ; ansible-lint en CI. Préférez apt / lineinfile / template à shell. Si vous devez passer par shell, ajoutez creates ou changed_when. Secrets dans Vault ou un coffre, jamais en clair. Dès qu’un projet dépasse dix tâches, passez en rôles et épinglez les collections. Pour un parc : serial et max_fail_percentage (rolling).
Structure type : ansible.cfg, inventories/dev, roles/, site.yml. Même squelette partout, la CI le trouve sans magie.
Approfondir sans se perdre (contrôle, secrets, parc)
Le ping vert n’est pas un playbook de production. Trois sujets séparent le lab du geste d’équipe.
Contrôle. Un playbook lu par quelqu’un d’autre doit dire quoi et pourquoi dans le nom des tâches. « Configure stuff » ne passera pas la revue. Découpez : paquets, fichiers, services, utilisateurs. Les handlers existent pour ne redémarrer nginx que si le fichier a changé — c’est de l’idempotence visible. Avant la première applique sur un hôte partagé, --check --diff : vous lisez le delta comme un plan Terraform, en plus petit.
Secrets. Vault chiffre un fichier que Git peut versionner. Le mot de passe Vault, lui, n’est pas dans Git : il vit dans le magasin Jenkins ou dans votre tête de lab. Ne contournez pas en mettant le mot de passe sudo dans group_vars/all.yml. Le Capstone banking n’a pas besoin de Vault pour Java/Apache, mais prenez l’habitude dès le troisième playbook : un faux secret SMTP suffit à exercer le geste.
Parc. Deux hôtes web et un db enseignent les groupes. Au-delà, vous voudrez des inventaires dev / staging / prod et des variables qui ne se marchent pas dessus. host_vars pour l’exception, group_vars pour la règle. Un inventaire plat de cinquante IPs sans groupes est une liste d’épicerie, pas un modèle. serial: 1 sur les serveurs web évite de tout recharger d’un coup — même en lab, c’est un bon réflexe.
Ansible n’est pas non plus un remplacement de Docker. Installer Java sur l’hôte (Capstone) et lancer un conteneur sont deux couches. Si vous « ansiblez » la construction d’une image, vous combattez Dockerfile. Si vous ignorez Ansible parce que « on est full Kubernetes », vous redécouvrirez les nœuds le jour où kubelet ou le disque dérive.
Reliez ensuite au menu : Git versionne playbooks et rôles ; Jenkins les exécute ; Puppet montre l’autre école ; Nagios vérifie qu’après le playbook, le port écoute vraiment. C’est tout le sens d’un hub : pas un dump de modules, une place dans la chaîne.
Enfin, documentez le control node comme un serveur : Python, pipx, collections épinglées, clé SSH dédiée (pas votre clé perso de GitHub). Un control node « c’est mon laptop » fonctionne jusqu’au jour où le laptop est éteint et que personne ne peut relancer le site. Même en formation, simulez un petit bastion.
Playbook du Capstone (ce que vous réutiliserez)
Le brief banking demande Java et Apache sur une prod Ubuntu ou Red Hat, service démarré. Votre playbook aura des tâches conditionnées par ansible_os_family : apt/apache2 d’un côté, dnf/httpd de l’autre. Un seul inventaire, deux familles. Relancez deux fois : la seconde doit être verte et calme. Puis seulement, branchez Docker sur cette machine. Ansible prépare le terrain ; il ne remplace pas l’image.
Si le ping échoue, ne « corrigez pas le playbook ». Corrigez SSH, l’utilisateur, la clé, le sudo. Ansible ne fait que multiplier un geste que vous savez déjà faire à la main une fois.
Erreurs fréquentes
| Symptôme | Cause | Correction |
|---|---|---|
| Permission denied (publickey) | Mauvais user/clé | Tester SSH à la main d’abord |
| Missing sudo password | sudo interactif | become passwordless ou --ask-become-pass |
| Module collection introuvable | Collection absente | ansible-galaxy collection install … |
| Tâche toujours « changed » | shell sans garde | Module dédié, ou changed_when |
| Cible injoignable | Inventaire / réseau | Ping, DNS, security group |
Inventaire vivant et limites honnêtes
Un inventaire n’est pas éternel. Les IPs de lab changent ; un groupe web peut passer de deux à zéro machines le temps d’un destroy Terraform. Prévoyez un fichier généré ou un plugin dynamique plutôt que de coller des adresses dans un README. En attendant, un inventory.ini versionné avec des commentaires « lab Vagrant 2026-09 » suffit, à condition que personne n’y mette une clé privée.
Ansible n’orchestre pas un cluster Kubernetes mieux qu’un manifeste GitOps. Il prépare le sol (paquets, users, sshd, disques) et, parfois, appelle l’API. Si votre journée est 100 % Pods, ce hub reste utile pour les bastions et les bases. Si votre journée est 100 % VM, vous pouvez vivre longtemps ici avant d’ouvrir le hub Kubernetes.
Mesurez le succès d’un playbook à la deuxième exécution : zéro changed, zéro failed. La première prouve que ça marche ; la seconde prouve que vous n’avez pas écrit un script bash déguisé. C’est le critère que le reviewer du Capstone devrait exiger.
Documentez aussi ce que vous ne gérez pas : images Docker, DNS cloud, secrets déjà dans Vault d’entreprise. Un playbook qui « fait tout » devient illisible. Un playbook qui fait Java + Apache, clairement, est un livrable.
Le control node mérite un backup de ~/.ansible et des collections comme Jenkins mérite un backup de son home. Perdre le control node, c’est perdre le mode d’emploi du parc.
FAQ
1. Ansible ou Terraform ?
Les deux. Terraform pour le cycle de vie des ressources ; Ansible pour ce qui tourne dans la machine.
2. Cibles Windows ?
Oui via WinRM ou OpenSSH et la collection windows. Le control node reste Linux/macOS/WSL.
3. Encore utile avec Kubernetes ?
Oui : nœuds, legacy, réseau, et parfois la collection Kubernetes.
4. Par où commencer si je viens de Puppet ?
Inventaire + ping + un playbook paquet-fichier-service. Comparez ensuite avec un manifest Puppet : même résultat, autre contrat.
5. Où vont les mots de passe ?
Vault ou un gestionnaire externe. Jamais dans les variables en clair du dépôt.
Un après-midi type (pour ancrer)
Matin : inventaire + ping + une tâche apt. Midi : playbook paquet-fichier-service, deux runs. Après-midi : Vault sur un faux secret, puis --limit web1. Si tout cela est documenté dans un README, vous avez le niveau du hub. Le reste (rôles Galaxy, inventaire AWS, AWX) est de l’extension, pas le permis de conduire.
Quand un collègue veut « juste un script bash », montrez la deuxième exécution inchangée. C’est l’argument le plus court en faveur d’Ansible. Quand un collègue veut tout mettre dans Kubernetes, montrez le bastion et la base : ils existent encore. Ce hub tient ces deux conversations, puis renvoie vers Puppet et Jenkins.
Gardez une clé SSH de lab séparée, un utilisateur ubuntu ou ansible, et un sudo sans mot de passe uniquement sur les VM jetables. En entreprise, le sudo est audité ; ne copiez pas les habitudes de lab.
Encore cent mots pour la densité : relisez vos playbooks comme une checklist d’aéroport. Chaque tâche a un nom, un module, un état désiré. Pas de command: qui installe « un peu tout ». Pas de mot de passe. Pas de latest de paquet en prod si vous pouvez épingler. C’est ennuyeux, et c’est pour cela que ça marche. Le Capstone n’exige que Java et Apache : faites-les bien, deux familles d’OS, deux runs verts.
Points clés à retenir
- Agentless, push SSH, YAML, idempotence.
- Control node seulement ; cibles = SSH + Python.
- Playbook : modules qualifiés, handlers,
--check. - Vault pour les secrets ; rôles dès que ça grandit.
- Menu : Ansible puis Puppet pour comparer, puis Jenkins / Capstone.
Pour aller plus loin
Maillage série DevOps
| ← Connexe | Linux · Git · Terraform |
| → Suite | Puppet · Jenkins · Capstone |
| Aussi | Docker · Kubernetes |
