Objectifs
- Comprendre l’approche agentless et le rôle de SSH.
- Distinguer control node, managed nodes, inventory, module, task, play et playbook.
- Expliquer l’idempotence et le workflow général d’Ansible.
- Lire deux commandes de vérification sans les exécuter depuis cette application.
Introduction à Ansible
Ansible automatise la configuration et l’administration de machines depuis un control node. Dans le cas Linux courant, il est agentless : aucun agent Ansible permanent n’est installé sur les managed nodes, et les connexions utilisent généralement SSH.
Le control node charge un inventory, sélectionne des hôtes, transfère ou appelle des modules, puis retourne un résultat. Les commandes présentées ici sont uniquement des exemples à exécuter dans votre propre environnement maîtrisé.
Le vocabulaire essentiel
Un inventory décrit les machines et les groupes ciblables. Un module réalise une action précise. Une task appelle un module ; plusieurs tasks forment un play qui vise un ensemble d’hôtes ; un ou plusieurs plays enregistrés en YAML forment un playbook.
- control node : machine depuis laquelle Ansible est lancé.
- managed node : machine administrée à distance.
- inventory : liste structurée des hôtes, groupes et variables de connexion.
- module : unité d’action, par exemple package, service, copy ou file.
- task : appel nommé d’un module ; play : ensemble de tâches associé à des hôtes.
- playbook : document YAML regroupant un ou plusieurs plays.
Workflow et idempotence
Le workflow habituel est : préparer l’inventory, vérifier la connectivité, décrire l’état souhaité dans des tâches, tester en mode check lorsque les modules le permettent, relire puis exécuter sur une cible limitée.
Une tâche idempotente converge vers un état : si le paquet demandé est déjà présent ou si le fichier possède déjà le bon contenu, une nouvelle exécution ne devrait pas produire de changement supplémentaire.
ansible --versionansible all -i inventory.ini -m ansible.builtin.pingLe module ansible.builtin.ping n’envoie pas un ping ICMP : il vérifie notamment que la connexion Ansible fonctionne et qu’un Python utilisable est disponible sur la cible Linux.
Avant la première automatisation
Utilisez des hôtes de laboratoire, un compte dédié et des clés SSH protégées. Vérifiez l’identité des cibles et commencez par un groupe restreint avant d’élargir le périmètre.
- Ne placez jamais de clé privée, mot de passe ou secret réel dans un playbook.
- Appliquez le moindre privilège au compte distant et à become.
- Versionnez le code d’automatisation, mais pas les fichiers de mots de passe.
Erreur fréquente : confondre ping Ansible et ping réseau
Mini résumé
- Ansible pilote généralement des nœuds Linux via SSH sans agent permanent.
- Inventory, modules, tasks, plays et playbooks structurent l’automatisation.
- L’idempotence évite des changements inutiles lors des exécutions répétées.
- La connectivité et le périmètre se vérifient avant toute modification.
Outils associés
Construire une commande Ansible
Utilisez Ansible Command Builder pour composer une commande ad-hoc ou de diagnostic et comprendre ses options sans l’exécuter.
Ouvrir l’outilMini quiz
Trois questions pour vérifier les notions essentielles de la leçon.