Cours Ansible — automatiser sans agent : inventaire, playbooks, rôles et secrets

Objectifs d'apprentissage

À la fin de ce cours, l'apprenant peut :

1. expliquer le modèle sans agent (nœud de contrôle, hôtes gérés, SSH) et distinguer ansible-core du paquet ansible ;
2. écrire un inventaire (INI ou YAML), le lire avec ansible-inventory et y poser des groupes et des variables ;
3. écrire un playbook YAML (plays, tâches, modules) et expliquer l'idempotence ;
4. utiliser les variables et les faits (ansible_facts), et choisir où poser une variable ;
5. déclencher une action seulement sur changement avec notify et un handler ;
6. produire un fichier depuis un modèle Jinja2 avec le module template ;
7. prévisualiser avec --syntax-check, --check et --diff avant toute exécution réelle, et en connaître les limites ;
8. organiser le code en rôle ;
9. protéger un secret avec Ansible Vault et ne pas le divulguer dans les journaux ;
10. reconnaître les modules d'administration Linux/RHEL et situer les collections VMware, sans les pratiquer.

Prérequis

• Savoir lire une commande avant de la valider (cours « Terminal macOS »), manipuler des fichiers texte et lire du YAML (indentation par espaces, listes -, dictionnaires clé: valeur).
• Notions de SSH (clé, utilisateur, known_hosts) ; savoir ce que fait sudo.
• Ansible installé sur le poste qui sert de nœud de contrôle. Ce cours n'enseigne pas l'installation ; la page officielle recommande pip (python3 -m pip install --user ansible, ou ansible-core pour une installation minimale), mais la méthode retenue pour le Mac de Stéphane est non vérifiée et le choix du paquet lui appartient. Vérification : ansible --version.
• Pour les exercices : un dossier de test jetable, localhost comme seul hôte, et éventuellement une VM jetable (chapitre 11). Aucun droit administrateur n'est nécessaire pour les exercices sur localhost.

Parcours et chapitres

1. Le modèle : nœud de contrôle, hôtes gérés, sans agent

Selon la page « Getting started », le nœud de contrôle est le système où Ansible est installé et d'où l'on lance ansible ou ansible-inventory ; l'inventaire est une liste d'hôtes gérés organisée logiquement ; un hôte géré est le système distant que pilote Ansible. D'après le guide d'installation, les hôtes gérés n'ont pas besoin d'Ansible : ils demandent Python (pour exécuter le code que génère Ansible) et un compte joignable en SSH avec un shell POSIX interactif. Le nœud de contrôle est « presque toute machine de type UNIX avec Python » (macOS compris) ; Windows n'est pas pris en charge nativement comme nœud de contrôle (WSL requis).

ansible-core ou ansible ? D'après la page d'installation, ansible-core est le paquet minimal (le moteur, les modules et plugins intégrés) ; ansible est le paquet « piles incluses », qui ajoute des collections maintenues par la communauté. La commande ansible-community --version renseigne sur le paquet complet. Les noms complets des modules intégrés commencent par ansible.builtin. ; les autres viennent de collections (community.vmware…). Sur une installation minimale, une collection absente doit être installée à part (procédure : non vérifiée).

2. L'inventaire : hôtes, groupes, variables

La page « Inventory » présente deux formats intégrés, INI et YAML. Chaque hôte appartient à au moins deux groupes : all (tous les hôtes) et ungrouped (ceux sans autre groupe).

[serveurs_web]
lab-web01.example.test

[serveurs_web:vars]
ntp_serveur=ntp.example.test

L'équivalent YAML :

serveurs_web:
  hosts:
    lab-web01.example.test:
  vars:
    ntp_serveur: ntp.example.test

Paramètres de connexion cités par la documentation : ansible_connection (ssh, local…), ansible_host, ansible_user, ansible_python_interpreter. Les variables peuvent aussi vivre dans des répertoires group_vars/ et host_vars/ à côté de l'inventaire. Plusieurs inventaires se combinent (-i staging -i production) ; les valeurs se fusionnent dans l'ordre donné, la dernière définition l'emporte.

Pour les exercices, un inventaire qui ne sort jamais du Mac :

[local]
localhost ansible_connection=local

À enregistrer sous inventaire.ini dans un dossier de test. Lecture seule :

ansible-inventory -i inventaire.ini --listansible-inventory -i inventaire.ini --graph

• Contexte : Terminal, dossier de test contenant inventaire.ini ; version d'Ansible de Stéphane inconnue (--help fait foi).
• Droits : utilisateur normal ; aucun accès réseau.
• Effet : affiche l'inventaire en JSON (--list) ou en arbre (--graph) ; lecture seule.
• Vérification : le groupe local contient localhost ; les groupes all et ungrouped apparaissent.
• Retour arrière : sans objet.

3. Premier contact : commande ad hoc et module ping

Une commande ad hoc lance un seul module, sans playbook. ansible.builtin.ping ne fait pas un ping réseau : il vérifie qu'Ansible peut se connecter et exécuter du Python sur l'hôte.

ansible local -i inventaire.ini -m ansible.builtin.ping

• Contexte : inventaire du chapitre 2 ; connexion locale, pas de SSH.
• Droits : utilisateur normal.
• Effet : exécute le module ping sur localhost ; ne modifie rien.
• Vérification : la sortie contient SUCCESS et "ping": "pong" (forme exacte : non vérifiée).
• Retour arrière : sans objet.

Pour un hôte distant, la même commande devient une vérification de la connexion SSH (utilisateur, clé, empreinte d'hôte) ; elle ne se lance que sur un hôte de laboratoire.

4. Premier playbook et idempotence

D'après la page « Playbooks », un playbook est un fichier YAML contenant un ou plusieurs plays ; chaque play vise des hôtes (hosts) et exécute des tâches dans l'ordre, chacune appelant un module. Le tout s'exécute de haut en bas.

- name: Préparer un dossier de test
  hosts: local
  gather_facts: false
  tasks:
    - name: Créer le dossier de sortie
      ansible.builtin.file:
        path: ./sortie
        state: directory
        mode: "0755"

La notion centrale est l'idempotence : « la plupart des modules vérifient si l'état final voulu est déjà atteint et sortent sans rien faire » (page « Playbooks »). Relancer le playbook donne donc le même résultat. Dans le bilan, changed signale un changement effectué, ok un état déjà conforme. À l'inverse, les modules command et shell exécutent leur ligne à chaque fois ; ils ne sont idempotents que si l'on ajoute soi-même des garde-fous (par exemple creates:).

Les quatre vérifications que la documentation propose avant exécution : --syntax-check, --list-hosts, --list-tasks, --check (avec --diff). Elles ne modifient pas la cible (sauf les limites du chapitre 8).

ansible-playbook -i inventaire.ini preparer.yml --syntax-checkansible-playbook -i inventaire.ini preparer.yml --list-tasksansible-playbook -i inventaire.ini preparer.yml --check --diff

• Contexte : fichier preparer.yml (ci-dessus) et inventaire.ini dans le même dossier de test.
• Droits : utilisateur normal.
• Effet : contrôle la syntaxe, liste les tâches, puis simule l'exécution avec comparaison avant/après ; aucun dossier n'est créé.
• Vérification : la dernière commande annonce changed=1 (simulé) ; ls sortie échoue encore.
• Retour arrière : sans objet.

Puis l'exécution réelle, qui crée un dossier :

Attention, effet notable. Cette commande a un effet notable. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

ansible-playbook -i inventaire.ini preparer.ymlansible-playbook -i inventaire.ini preparer.yml

• Contexte : après la simulation du bloc précédent, sur localhost uniquement.
• Droits : utilisateur normal, droit d'écriture dans le dossier de test.
• Effet : la première exécution crée ./sortie (changed=1) ; la seconde ne change rien (changed=0) : c'est l'idempotence.
• Vérification : ls -d sortie existe ; le second bilan affiche ok=1 changed=0.
• Retour arrière : supprimer le dossier sortie de test en relisant son nom.

5. Variables et faits

Les variables se posent dans l'inventaire (hôte, groupe), dans le playbook (vars:), dans des fichiers group_vars/ et host_vars/, dans un rôle (defaults/, vars/), ou en ligne de commande (-e nom=valeur, la plus prioritaire). La table de précédence complète est dans la documentation : ne pas la mémoriser, la consulter. Règle pratique : mettre les valeurs par défaut dans defaults/ d'un rôle (priorité très basse) et ne remplacer que ce qui diffère.

Les faits sont des informations découvertes sur l'hôte (système, adresses, disques). Par défaut, Ansible les collecte au début de chaque play (gather_facts) ; on y accède par ansible_facts, par exemple {{ ansible_facts['hostname'] }} ; gather_facts: false accélère un play qui n'en a pas besoin. Pour les voir : ansible local -i inventaire.ini -m ansible.builtin.setup. Variables « magiques » utiles : inventory_hostname, groups, group_names, hostvars, playbook_dir.

- name: Afficher quelques faits
  hosts: local
  gather_facts: true
  vars:
    message: "Bonjour depuis {{ inventory_hostname }}"
  tasks:
    - name: Montrer le message et la famille de système
      ansible.builtin.debug:
        msg: "{{ message }} ({{ ansible_facts['os_family'] }})"

Nom exact de certains faits (os_family, distribution) : usage courant, non relu page par page ; vérifier avec le module setup.

6. Handlers : agir seulement sur changement

Un handler est une tâche spéciale qui s'exécute seulement si une autre tâche l'a notifiée par notify et a changé quelque chose (page « Handlers »). Points établis par la page :

• les handlers s'exécutent après toutes les tâches du play, sauf si meta: flush_handlers les déclenche plus tôt ;
• ils s'exécutent dans l'ordre où ils sont définis, pas dans l'ordre des notifications ;
• plusieurs notifications du même handler n'entraînent qu'une exécution ;
• si une tâche échoue, les handlers ne s'exécutent pas (sauf réglage particulier : non vérifié) ;
• listen regroupe plusieurs handlers sous un thème ; les noms de handlers doivent être uniques.

- name: Configuration avec handler
  hosts: local
  gather_facts: false
  tasks:
    - name: Écrire un fichier de réglages de test
      ansible.builtin.copy:
        content: "mode=demo\n"
        dest: ./sortie/reglages.conf
        mode: "0644"
      notify: Signaler le changement

  handlers:
    - name: Signaler le changement
      ansible.builtin.debug:
        msg: "Le fichier a changé : en production, on rechargerait le service ici."

Sur un vrai serveur, le handler classique est un rechargement de service (ansible.builtin.service avec state: reloaded) ; le cours ne le lance pas en dehors d'un hôte jetable.

7. Modèles Jinja2 : le module template

D'après la page « Templating », Ansible utilise Jinja2 pour des expressions et un accès aux variables et aux faits ; tout le rendu a lieu sur le nœud de contrôle, avant l'envoi vers la cible. Le module ansible.builtin.template prend un fichier .j2 (src, côté contrôleur, en UTF-8) et dépose le résultat sur l'hôte (dest) avec owner, group, mode (octal entre guillemets) ; validate permet de contrôler le fichier avant de le mettre en place ; backup conserve l'ancienne version. Le module gère le mode --check et --diff.

Fichier templates/reglages.conf.j2 :

# Fichier généré par Ansible : ne pas modifier à la main
hote = {{ inventory_hostname }}
mode = {{ mode_reglage | default('demo') }}

Tâche correspondante :

- name: Générer les réglages depuis le modèle
  hosts: local
  gather_facts: false
  vars:
    mode_reglage: essai
  tasks:
    - name: Déposer le fichier de réglages
      ansible.builtin.template:
        src: templates/reglages.conf.j2
        dest: ./sortie/reglages-modele.conf
        mode: "0644"

8. Simuler avant d'agir : --check et --diff

D'après la page « Check mode and diff mode » :

• --check simule : les modules qui le prennent en charge annoncent ce qu'ils changeraient ; les autres ne rapportent rien. Les modules command et shell ne le gèrent pas.
• --diff affiche l'avant/après des fichiers modifiés ; il se combine avec --check ; la documentation le recommande pour un petit nombre d'hôtes (sortie volumineuse), par exemple avec --limit.
• au niveau d'une tâche : check_mode: true force la simulation, check_mode: false force l'exécution réelle même sous --check ; diff: false supprime l'affichage des différences (utile quand le fichier contient des données sensibles) ;
• ansible_check_mode est une variable pour ignorer une tâche en simulation (when: not ansible_check_mode).

ansible-playbook -i inventaire.ini modele.yml --check --diff --limit local

• Contexte : playbook du chapitre 7 enregistré sous modele.yml, sortie/ existante.
• Droits : utilisateur normal.
• Effet : montre le fichier qui serait créé, sans l'écrire.
• Vérification : l'affichage contient le texte rendu du modèle ; ls sortie ne contient pas encore reglages-modele.conf.
• Retour arrière : sans objet.

9. Ansible Vault : protéger les secrets

D'après la page « Vault », Ansible Vault « offre un moyen de chiffrer et de gérer des données sensibles comme des mots de passe ». On peut chiffrer un fichier entier ou une variable seule (encrypt_string), utiliser un mot de passe unique ou plusieurs avec des vault ID. Commandes de la page « Encrypting content » : create, encrypt, encrypt_string, edit, view, rekey, decrypt.

Avertissements de la documentation, à retenir :

• taper un secret directement dans la ligne de commande le laisse dans l'historique du shell ;
• avec un prompt, ne pas valider par Entrée en trop : cela ajoute un saut de ligne aux données chiffrées ;
• configurer l'éditeur pour ne pas laisser de fichiers temporaires, d'échange ou de sauvegarde.

Avec un fichier de test jetable et un mot de passe de démonstration saisi au prompt :

Attention, effet notable. Cette commande peut créer ou modifier une configuration. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

ansible-vault create --ask-vault-pass secrets-demo.ymlansible-vault view --ask-vault-pass secrets-demo.yml

• Contexte : dossier de test jetable ; éditeur par défaut configuré ; mot de passe fictif, valeur de test, jamais un vrai secret.
• Droits : utilisateur normal.
• Effet : create ouvre l'éditeur et écrit secrets-demo.yml chiffré ; view affiche le contenu après saisie du mot de passe (lecture seule).
• Vérification : head -1 secrets-demo.yml commence par $ANSIBLE_VAULT; ; sans mot de passe, le contenu est illisible.
• Retour arrière : supprimer secrets-demo.yml de test ; ne rien conserver du mot de passe de démonstration.

Utilisation : vars_files: [secrets-demo.yml] dans un play, puis ansible-playbook … --ask-vault-pass (ou --vault-password-file vers un fichier hors dépôt, droits 600). Sur toute tâche qui manipule une valeur secrète, ajouter no_log: true pour que ni le secret ni ses paramètres n'apparaissent dans la sortie (comportement détaillé de no_log : non vérifié ici). Et diff: false si le fichier modifié contient des secrets.

10. Rôles : structurer et réutiliser

Un rôle est un répertoire standard (page « Roles ») dont les sous-dossiers sont tous facultatifs : tasks/ (avec main.yml), handlers/, defaults/ (variables à priorité très basse), vars/ (priorité haute), templates/ (fichiers .j2), files/ (fichiers statiques), meta/ (dépendances, métadonnées). Trois façons de l'utiliser : roles: au niveau du play, include_role (dynamique) et import_role (statique), qui diffèrent par le moment d'exécution et la gestion des étiquettes (tags). Depuis la version 2.11 de la documentation, meta/argument_specs.yml permet de valider les paramètres d'un rôle.

roles/
  motd/
    defaults/main.yml
    tasks/main.yml
    templates/motd.j2
playbook.yml

- name: Appliquer le rôle motd
  hosts: local
  gather_facts: false
  roles:
    - role: motd
      vars:
        motd_texte: "Machine de laboratoire"

Un rôle de départ se crée avec ansible-galaxy role init <NOM> (commande à confirmer dans la documentation de votre version : non vérifié ici). Le dossier est créé dans le répertoire courant.

11. Linux/RHEL, élévation de droits et connexions SSH

Connexions SSH. Ansible s'appuie sur SSH : définir ansible_user et, si besoin, ansible_host dans l'inventaire ; utiliser une clé SSH dédiée et protégée par phrase secrète ; ne pas désactiver la vérification de l'empreinte de l'hôte sans raison documentée. Les options précises de ansible.cfg et de ssh_args n'ont pas été lues : non vérifié.

Élévation de droits (become). D'après la page « Privilege escalation », become: true active l'élévation ; become_user désigne le compte cible (par défaut root, mais n'active rien à lui seul) ; become_method choisit l'outil (sudo, su…). Sur la ligne de commande : --become (-b) et --ask-become-pass (-K, saisie du mot de passe sans l'écrire dans un fichier). Mise en garde de la page : quand l'utilisateur de connexion et l'utilisateur cible sont tous deux non privilégiés, Ansible doit rendre le fichier du module lisible par l'utilisateur cible ; en dernier recours il peut le rendre lisible par tous, ce qui expose les paramètres s'ils sont sensibles. Garder become au niveau de la tâche qui en a besoin plutôt que sur tout le play.

Modules Linux/RHEL courants (les distributions et versions de Stéphane restent à fournir) :

La page du module dnf indique qu'il gère les paquets et groupes (préfixe @), les RPM locaux ou distants, et le mode --check/--diff ; il exige python3-dnf sur la cible. Pour les anciens RHEL (yum), le module à utiliser selon la version est non vérifié.

Exemple sur un hôte jetable uniquement :

- name: Installer et démarrer un serveur de test
  hosts: serveurs_web
  become: true
  tasks:
    - name: Installer le paquet
      ansible.builtin.dnf:
        name: httpd
        state: present
    - name: Démarrer et activer le service
      ansible.builtin.service:
        name: httpd
        state: started
        enabled: true

Attention, effet notable. Cette commande a un effet notable. Lire le contexte, les droits et l’effet attendu indiqués après le bloc ; ne jamais l’exécuter sur un système réel sans validation, d’abord dans un environnement de test.

ansible-playbook -i inventaire-lab.ini serveur.yml --check --diff --ask-become-passansible-playbook -i inventaire-lab.ini serveur.yml --ask-become-pass

• Contexte : VM RHEL-like jetable de laboratoire (version inconnue, à confirmer), joignable en SSH par clé ; inventaire-lab.ini contient un hôte fictif lab-web01.example.test à remplacer par le sien.
• Droits : utilisateur SSH avec sudo (mot de passe saisi au prompt, jamais écrit dans un fichier).
• Effet : la première commande simule ; la seconde installe un paquet et démarre un service sur l'hôte (modification du système, accès réseau aux dépôts de paquets).
• Vérification : ansible serveurs_web -i inventaire-lab.ini -m ansible.builtin.service_facts ou, sur l'hôte, systemctl status httpd ; relancer le playbook réel et constater changed=0.
• Retour arrière : détruire la VM jetable (instantané avant exécution) ; sinon state: absent pour le paquet et state: stopped pour le service, d'abord en --check.

12. VMware : en mention

Ansible peut piloter vSphere via des collections ; la page de community.vmware (version 6.5.0 lue dans la documentation, exigeant ansible-core 2.19.0 ou plus) annonce plus de 300 modules couvrant machines virtuelles, hôtes, stockage, réseau, et plusieurs modules marqués DEPRECATED (vcenter_folder, vmware_cluster_ha, vmware_guest_powerstate, vmware_tag). Ces modules s'appuient en général sur une bibliothèque Python (pyVmomi : non confirmé sur la page lue). L'état de la collection par rapport à une éventuelle collection de remplacement (vmware.vmware) n'a pas été vérifié.

Règle de ce cours : pas d'exemple exécutable VMware ici. Un playbook vers un vCenter exige un compte de service à droits minimaux, un secret dans Vault, l'accès à un vCenter de laboratoire et --check en premier ; il relève du cours vCenter.

13. Bonnes pratiques

• Versionner playbooks, inventaires et rôles dans Git ; jamais de secret en clair ni de mot de passe de coffre.
• Nommer chaque tâche ; préférer les modules aux command/shell ; ajouter changed_when/creates si on doit utiliser command.
• Utiliser les noms complets de modules (ansible.builtin.copy) : ils lèvent l'ambiguïté avec les collections.
• Toujours : --syntax-check, puis --check --diff sur peu d'hôtes (--limit), puis exécution réelle.
• Limiter become aux tâches qui en ont besoin ; utiliser un compte de service plutôt qu'un compte personnel.
• Séparer inventaire de laboratoire et inventaire de production, avec des fichiers distincts, jamais fusionnés par défaut.
• Passer un linter (ansible-lint, cité par la documentation) avant de commiter ; installation et règles : non vérifiées.
• Exécuter depuis une intégration continue sur un dépôt privé (voir le cours « CI/CD avec GitHub Actions ») ; l'Orchestrator impose /publier-pages et gardien-confidentialite pour toute publication publique.

Exercices et vérifications de fin de cours

Tous sur localhost (connexion locale) ou sur un hôte jetable, dans un dossier de test hors de l'Orchestrator.

1. Inventaire. Écrire inventaire.ini, l'afficher avec ansible-inventory --graph et ajouter une variable de groupe.
2. Ad hoc. Lancer ansible.builtin.ping sur localhost, puis ansible.builtin.setup et repérer le fait os_family.
3. Idempotence. Exécuter deux fois preparer.yml et expliquer pourquoi le second bilan est changed=0.
4. Simulation. Modifier le contenu d'un copy, lancer --check --diff et lire la différence sans rien écrire.
5. Handler. Faire notifier un handler par une tâche, relancer deux fois et constater qu'il ne tourne qu'au premier changement.
6. Modèle. Générer reglages-modele.conf depuis le modèle Jinja2 en surchargeant la variable avec -e mode_reglage=autre.
7. Limite du mode check. Ajouter une tâche ansible.builtin.command et constater qu'elle n'est pas simulée.
8. Vault. Créer secrets-demo.yml avec un mot de passe fictif, le lire, puis vérifier qu'il n'a pas été ajouté à Git (git status).
9. Rôle. Transformer le playbook du chapitre 4 en rôle sortie appelé depuis un play de quelques lignes.
10. Classement. Classer les commandes du cours selon leur effet : lecture, simulation, création locale, modification d'un hôte distant.

Critères de réussite

• Expliquer pourquoi Ansible est « sans agent » et ce qu'il exige tout de même sur l'hôte géré.
• Distinguer ansible-core du paquet ansible, et un module intégré (ansible.builtin) d'un module de collection.
• Lire un bilan (ok, changed, failed) et justifier un résultat changed=0 au second passage.
• Dire ce que --check ne simule pas et pourquoi une simulation verte n'est pas une garantie.
• Citer trois endroits où ne jamais écrire un secret (dépôt, playbook en clair, journal) et la manière de le protéger (Vault, no_log).
• Citer le périmètre des sources (documentation en ligne du 2026-10-18) sans la confondre avec la version installée.