Prise en main de la CLI Ansible : 8 commandes du quotidien

Vous venez d’installer Ansible et vous voyez dix binaires dans ~/.local/bin/ansible*. Lesquels servent vraiment au quotidien, et dans quel ordre les utiliser ? Ce guide vous présente les 8 commandes que vous taperez 95 % du temps : ansible, ansible-playbook, ansible-doc, ansible-galaxy, ansible-vault, ansible-config, ansible-inventory, ansible-lint. Pour chacune : un objectif en une ligne, une commande type, et le moment où vous l’utilisez réellement.

Ce que vous allez apprendre

Identifier les 8 binaires Ansible utiles au quotidien.
Savoir quand lancer chacun (avant un playbook, pendant l’écriture, à l’examen RHCE).
Repérer les flags indispensables : -v/-vvv, --check, --diff, --limit, --tags.
Comprendre la place de ansible-navigator par rapport à ces outils.

Vue d’ensemble : qui fait quoi

Avant le détail de chaque commande, voici la carte mentale à mémoriser. Les huit outils se répartissent en trois familles fonctionnelles : exécution, introspection, gestion.

Famille	Commandes	Quand vous l’utilisez
Exécution	`ansible`, `ansible-playbook`	Lancer une tâche ou un playbook sur les managed nodes
Introspection	`ansible-doc`, `ansible-config`, `ansible-inventory`	Vérifier ce qu’Ansible voit (modules, config, hôtes)
Gestion	`ansible-galaxy`, `ansible-vault`, `ansible-lint`	Gérer les collections, chiffrer des secrets, lint le code

ansible-navigator n’est pas dans la liste car c’est un wrapper moderne qui invoque les autres en interne via un Execution Environment. Vous le rencontrerez plus tard dans la formation.

1. `ansible` — exécution ad-hoc

ansible lance une tâche unique sur un ou plusieurs hôtes, sans playbook. C’est la commande à taper quand vous voulez juste tester quelque chose, vérifier l’état d’un service, redémarrer un démon en urgence, ou avant d’écrire le playbook équivalent.

web1.lab | SUCCESS => {
    "changed": false,
    "ping": "pong"
}

La syntaxe est ansible <pattern> -m <module> -a "<arguments>". Le pattern cible un groupe (webservers), un hôte (web1.lab), un wildcard (web*), une combinaison (webservers:!web1.lab = tous les webservers sauf web1). Quelques modules typiques en ad-hoc : ansible.builtin.ping, ansible.builtin.command, ansible.builtin.dnf, ansible.builtin.service, ansible.builtin.copy.

Le moment où vous l’utilisez : juste après le provisioning d’un lab pour vérifier la connectivité, ou pendant une session de troubleshooting pour interroger l’état d’un système sans préparer de playbook.

2. `ansible-playbook` — exécution de playbook

ansible-playbook est la commande principale de votre quotidien Ansible. Elle exécute un playbook YAML sur les hôtes ciblés, dans l’ordre, en gérant facts, handlers, tags et conditions.

# Exécution réelle
ansible-playbook site.yml

# Dry-run (modules avec check_mode, rien d'écrit)
ansible-playbook site.yml --check --diff

# Limiter aux hôtes voulus
ansible-playbook site.yml --limit web1.lab

# Tags pour exécuter une partie du playbook
ansible-playbook site.yml --tags configure --skip-tags reboot

# Vérification syntaxe YAML uniquement
ansible-playbook --syntax-check site.yml

Les flags --check et --diff sont vos meilleurs amis. Le premier active le mode dry-run (les modules idempotents simulent sans écrire), le second affiche le diff avant/après pour les fichiers. Combiner les deux est le réflexe avant un déploiement en prod : vous voyez exactement ce qui va changer.

-v augmente la verbosité (-vvv montre la connexion SSH détaillée, -vvvv ajoute la trace SSH complète). C’est ce que vous lancez en cas d’échec inexplicable.

3. `ansible-doc` — documentation des modules

ansible-doc est l’outil de référence quand vous écrivez un playbook : il affiche tous les paramètres, valeurs par défaut, exemples d’un module — hors-ligne et autorisé à l’examen RHCE.

> MODULE ansible.builtin.copy
  The ansible.builtin.copy module copies a file or a directory
  structure from the local or remote machine to a location on the
  remote machine. File system meta-information (permissions,
  ownership, etc.) may be set, even when the file or directory already
  exists on the target system.
  ...

Trois variantes que vous utiliserez sans cesse :

ansible-doc ansible.builtin.copy           # documentation complète
ansible-doc -s ansible.builtin.copy        # snippet YAML d'un exemple typique
ansible-doc -l                              # liste tous les modules disponibles
ansible-doc -t connection -l                # plugins de connexion uniquement

Le flag -l liste les ~9 500 modules dispos avec le metapackage ansible. Filtrez avec grep (ansible-doc -l 2>/dev/null | grep firewalld) pour trouver le bon module sans le connaître par cœur.

4. `ansible-config` — configuration d’Ansible

ansible-config lit, dump, valide votre configuration Ansible (le ansible.cfg) et les variables d’environnement ANSIBLE_*. Indispensable pour debugger un comportement inattendu.

ANSIBLE_PIPELINING(/home/bob/Projets/lab-ansible/ansible.cfg) = True
CACHE_PLUGIN(/home/bob/Projets/lab-ansible/ansible.cfg) = jsonfile
CALLBACKS_ENABLED(/home/bob/Projets/lab-ansible/ansible.cfg) = ['ansible.posix.profile_tasks', 'ansible.posix.timer']
CONFIG_FILE() = /home/bob/Projets/lab-ansible/ansible.cfg
DEFAULT_BECOME(/home/bob/Projets/lab-ansible/ansible.cfg) = True
DEFAULT_BECOME_METHOD(/home/bob/Projets/lab-ansible/ansible.cfg) = sudo
DEFAULT_FORKS(/home/bob/Projets/lab-ansible/ansible.cfg) = 10

Le sous-commande dump --only-changed est la plus utile : elle affiche uniquement les paramètres que vous avez modifiés par rapport aux défauts, avec la source (fichier ansible.cfg ou variable d’environnement). Quand un comportement vous étonne, c’est la première commande à lancer pour comprendre quel paramètre vient de surclasser le défaut.

Autres usages : ansible-config init --disabled > ansible.cfg génère un template propre commenté avec tous les paramètres possibles. ansible-config view affiche le contenu courant. La page dédiée ansible.cfg approfondit le sujet.

5. `ansible-inventory` — vérifier qui Ansible voit

Avant de lancer un playbook sur des dizaines d’hôtes, vous voulez savoir lesquels exactement Ansible va contacter. ansible-inventory répond à cette question, qu’il s’agisse d’un inventaire statique YAML/INI ou d’un inventaire dynamique (plugin AWS, Proxmox, NetBox).

@all:
  |--@ungrouped:
  |--@control:
  |  |--control-node.lab
  |--@webservers:
  |  |--web1.lab
  |  |--web2.lab
  |--@dbservers:
  |  |--db1.lab
  |--@rhce_lab:
  |  |--@webservers:
  |  |  |--web1.lab
  |  |  |--web2.lab
  |  |--@dbservers:
  |  |  |--db1.lab

Trois options à connaître :

ansible-inventory --graph                    # arbre des groupes (visuel)
ansible-inventory --list                     # JSON complet (machine-readable)
ansible-inventory --host web1.lab            # détails d'un hôte (vars, parents)

Le moment où vous l’utilisez : avant tout --limit complexe (vérifier que webservers:!web1.lab cible bien ce que vous croyez), ou pour debugger un inventaire dynamique qui ne renvoie pas les hôtes attendus.

6. `ansible-galaxy` — collections et rôles

ansible-galaxy gère les collections et les rôles que vous installez depuis Galaxy ou Automation Hub. C’est le npm install d’Ansible.

# Installer une collection
ansible-galaxy collection install community.general

# Installer depuis un fichier requirements.yml
ansible-galaxy collection install -r requirements.yml

# Initialiser un nouveau rôle
ansible-galaxy init roles/nginx

# Lister ce qui est installé
ansible-galaxy collection list

La sortie de ansible-galaxy collection list montre les chemins de recherche et les versions :

Collection                Version
------------------------- -------
ansible.netcommon         8.5.0
ansible.utils             6.0.2
community.general         11.4.7
community.libvirt         2.2.0
containers.podman         1.19.2
fedora.linux_system_roles 1.121.0

Le moment où vous l’utilisez : lors du git clone d’un projet Ansible (vous tapez ansible-galaxy collection install -r requirements.yml), ou quand vous découvrez qu’un module n’existe pas dans ansible.builtin (vous installez la collection qui le contient).

7. `ansible-vault` — chiffrement des secrets

ansible-vault chiffre des fichiers ou des chaînes pour stocker des secrets (mots de passe, clés API) directement dans votre dépôt Git. Ansible les déchiffre à la volée au moment de l’exécution avec un mot de passe fourni séparément.

# Chiffrer un fichier entier
ansible-vault encrypt secrets.yml

# Chiffrer une seule chaîne (à coller dans un YAML)
ansible-vault encrypt_string 'mon-mot-de-passe' --name 'db_password'

# Éditer un fichier déjà chiffré
ansible-vault edit secrets.yml

# Afficher en clair (utile pour debug)
ansible-vault view secrets.yml

Sortie de encrypt_string (la valeur que vous collez ensuite dans un fichier vars) :

db_password: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          61366266646137373864663631376664613933393430303234663334343565316263653135386533
          3863366232306363653930316439366137653863653665390a663065323365356164663263386263
          ...

Le moment où vous l’utilisez : à chaque fois qu’un playbook a besoin d’un secret. La page dédiée Ansible Vault couvre les bonnes pratiques (vault-id multiples, intégration HashiCorp Vault, OpenBao).

8. `ansible-lint` — qualité du code

ansible-lint détecte les mauvaises pratiques dans vos playbooks et rôles : modules dépréciés, oubli du FQCN, syntaxe non standard, modules non idempotents. C’est l’équivalent d’eslint pour JavaScript.

# Linter un playbook
ansible-lint site.yml

# Linter un rôle entier
ansible-lint roles/nginx/

# Mode strict (échec sur warnings)
ansible-lint --strict site.yml

# Configuration via .ansible-lint à la racine du projet
ansible-lint

Sortie typique d’un projet correctement configuré :

INFO  Identified /home/bob/Projets/lab-ansible as project root due .git directory.
ansible-lint 26.1.1 using ansible-core:2.20.2
Passed: 0 failure(s), 0 warning(s) on 1 file.

Le moment où vous l’utilisez : avant chaque commit (idéalement via un pre-commit hook), et obligatoirement en CI/CD. Un projet RHCE bien préparé doit passer ansible-lint --strict sans warning.

Bonus : `ansible-navigator`

ansible-navigator est le wrapper moderne introduit avec Ansible Automation Platform 2.0. Il invoque tous les outils précédents (ansible-playbook, ansible-doc, ansible-config) dans un Execution Environment (image conteneur OCI). C’est le mode d’exécution attendu au RHCE EX294 2026.

# Lancer un playbook dans une EE
ansible-navigator run playbook.yml --eei mon-ee:1.0

# Mode TUI interactif (texte plein écran)
ansible-navigator

# Documentation d'un module via EE
ansible-navigator doc ansible.builtin.copy

La page Ansible Navigator couvre l’outil en profondeur. Pour l’instant, retenez que ansible-navigator ne remplace pas les 8 commandes ci-dessus — il les enrobe dans un conteneur reproductible.

Tableau récapitulatif

Pour ancrer le tour, voici la synthèse des 8 commandes du quotidien. Lisez la colonne « Quand » : c’est le déclencheur typique d’utilisation.

Commande	Objectif	Quand
`ansible`	Tâche ad-hoc sans playbook	Tester la connectivité, vérifier un service en urgence
`ansible-playbook`	Exécuter un playbook YAML	Le quotidien des déploiements
`ansible-doc`	Documentation hors-ligne des modules	Pendant l’écriture d’un playbook, autorisé au RHCE
`ansible-config`	Inspecter la config Ansible	Debugger un comportement inattendu
`ansible-inventory`	Voir qui Ansible cible	Avant un `--limit` complexe ou pour debug d’inventaire dynamique
`ansible-galaxy`	Installer collections et rôles	`git clone` d’un projet, manque d’un module
`ansible-vault`	Chiffrer/déchiffrer des secrets	Tout secret commité dans le repo
`ansible-lint`	Lint du code Ansible	Pre-commit hook, CI/CD, préparation RHCE

À retenir

Les 8 commandes du quotidien se répartissent en trois familles : exécution (ansible, ansible-playbook), introspection (ansible-doc, ansible-config, ansible-inventory), gestion (ansible-galaxy, ansible-vault, ansible-lint).
Vos deux réflexes pré-déploiement : ansible-playbook --check --diff (dry-run avec diff) et ansible-lint (qualité du code).
ansible-doc <module> est la doc hors-ligne autorisée au RHCE — apprenez à l’utiliser dès maintenant.
ansible-config dump --only-changed répond à la question « pourquoi Ansible se comporte comme ça ? » en montrant la source de chaque paramètre actif.
ansible-navigator n’est pas une commande de plus, c’est un wrapper moderne qui exécute tout dans un Execution Environment — vous y arriverez plus tard.

Pratiquer dans le lab

Cette page a un lab d’accompagnement : labs/decouvrir/prise-en-main-cli/ dans stephrobert/ansible-training. Il contient un README.md guidé qui reprend les 8 commandes, un Makefile (make run / make verify), et un challenge final auto-évalué : chiffrer un secret avec ansible-vault puis le déchiffrer.

Une fois le lab provisionné :

cd ~/Projets/ansible-training/labs/decouvrir/prise-en-main-cli/

cat README.md           # tuto pas à pas pour les 8 commandes
make run                # démontre les 8 commandes sur le lab vivant
make verify             # tests pytest + testinfra (challenge ansible-vault)

Si les tests passent, vous maîtrisez les commandes essentielles de la CLI. En cas de blocage, docs/troubleshooting.md à la racine du repo couvre les pièges fréquents (rate-limit SSH, clé absente, collection manquante).

Prochaines étapes

Le fichier ansible.cfg Priorité de chargement, sections clés, valeurs par défaut, équivalents en variable d'environnement

Préparer le lab KVM 4 VMs AlmaLinux 10 sur libvirt en 5 min — la base pratique pour utiliser ces commandes

Commandes ad-hoc en profondeur Patterns d'hôtes avancés et 12 modules ad-hoc à connaître par cœur (objectif RHCE)

Ansible Navigator Le wrapper moderne avec Execution Environment — mode RHCE 2026

Prise en main de la CLI Ansible : 8 commandes du quotidien

Ce que vous allez apprendre

Vue d’ensemble : qui fait quoi

1. ansible — exécution ad-hoc

2. ansible-playbook — exécution de playbook

3. ansible-doc — documentation des modules

4. ansible-config — configuration d’Ansible

5. ansible-inventory — vérifier qui Ansible voit

6. ansible-galaxy — collections et rôles

7. ansible-vault — chiffrement des secrets

8. ansible-lint — qualité du code

Bonus : ansible-navigator