{"id":189,"date":"2026-08-30T23:41:54","date_gmt":"2026-08-30T21:41:54","guid":{"rendered":"https:\/\/asfy.fr\/index.php\/tutoriels\/ansible-installation-et-prise-en-main\/"},"modified":"2026-08-30T23:42:12","modified_gmt":"2026-08-30T21:42:12","slug":"ansible-installation-et-prise-en-main","status":"publish","type":"sv_tutoriel","link":"https:\/\/asfy.fr\/index.php\/tutoriels\/ansible-installation-et-prise-en-main\/","title":{"rendered":"Ansible : installation et prise en main"},"content":{"rendered":"

Configurer un serveur \u00e0 la main, puis le suivant, puis le suivant, en esp\u00e9rant avoir fait exactement les m\u00eames commandes \u00e0 chaque fois \u2014 c’est la d\u00e9finition m\u00eame du travail qui finit par vous exploser au visage un vendredi soir. Ansible<\/strong> automatise ce travail de fa\u00e7on reproductible, sans rien installer sur les machines g\u00e9r\u00e9es. Ce tutoriel couvre l’installation, l’inventaire, les commandes ad-hoc, l’\u00e9criture de playbooks et les roles.<\/p>\n

Le principe : agentless, en SSH, idempotent<\/h2>\n

Contrairement \u00e0 des outils comme Puppet ou Chef qui n\u00e9cessitent d’installer un agent sur chaque machine g\u00e9r\u00e9e, Ansible fonctionne en mode agentless<\/strong> : il se connecte simplement en SSH<\/strong> (ou WinRM pour Windows) depuis un \u00ab n\u0153ud de contr\u00f4le \u00bb vers les machines cibles, ex\u00e9cute des modules Python temporaires, puis nettoie derri\u00e8re lui. Rien \u00e0 installer ni \u00e0 maintenir sur les serveurs g\u00e9r\u00e9s, \u00e0 part un client SSH et Python \u2014 d\u00e9j\u00e0 pr\u00e9sents sur l’immense majorit\u00e9 des syst\u00e8mes Linux.<\/p>\n

Deuxi\u00e8me principe fondamental : l’idempotence<\/strong>. Un playbook Ansible bien \u00e9crit peut \u00eatre ex\u00e9cut\u00e9 cent fois de suite sans effet de bord : s’il constate qu’un paquet est d\u00e9j\u00e0 install\u00e9 ou qu’un fichier a d\u00e9j\u00e0 le bon contenu, il ne fait rien et le signale comme tel (\u00ab ok \u00bb, pas \u00ab changed \u00bb). C’est ce qui permet de rejouer sereinement une configuration sans craindre de casser quelque chose qui fonctionne d\u00e9j\u00e0.<\/p>\n

\n\nArchitecture agentless d’Ansible : un n\u0153ud de contr\u00f4le se connecte en SSH vers les machines g\u00e9r\u00e9es<\/title>\n\n\nN\u0153ud de contr\u00f4le<\/text>\nansible + playbooks<\/text>\n+ inventaire<\/text>\n\n\n\nSSH<\/text>\n\nweb01<\/text>\n\nweb02<\/text>\n\ndb01<\/text>\nAucun agent<\/text>\n\u00e0 installer<\/text>\nPython + SSH<\/text>\nsuffisent<\/text>\n<\/svg>
Le n\u0153ud de contr\u00f4le pousse la configuration en SSH ; les machines g\u00e9r\u00e9es n’ont besoin d’aucun agent permanent.<\/figcaption><\/figure>\n

Installation<\/h2>\n

Plusieurs m\u00e9thodes officielles existent ; pipx<\/strong> est aujourd’hui la m\u00e9thode recommand\u00e9e par la documentation Ansible pour installer l’outil dans un environnement isol\u00e9, sans polluer le Python syst\u00e8me :<\/p>\n

# Avec pipx (recommand\u00e9)\nsudo apt install pipx        # ou : python3 -m pip install --user pipx\npipx ensurepath\npipx install --include-deps ansible\n\n# Alternative : gestionnaire de paquets de la distribution\nsudo apt install ansible     # Debian\/Ubuntu\nsudo dnf install ansible     # Fedora\/RHEL\n\n# V\u00e9rification\nansible --version<\/code><\/pre>\n
Notez la distinction entre ansible-core<\/strong> (le moteur minimal) et le paquet ansible<\/strong> complet, qui embarque en plus une large collection de modules communautaires \u2014 le paquet complet est le plus simple pour d\u00e9marrer.<\/p>\n
Pr\u00e9parer l’acc\u00e8s SSH<\/h2>\n
    \n
  1. G\u00e9n\u00e9rez une paire de cl\u00e9s SSH d\u00e9di\u00e9e si vous n’en avez pas d\u00e9j\u00e0 une : ssh-keygen -t ed25519<\/code>.<\/li>\n
  2. Copiez la cl\u00e9 publique sur chaque machine \u00e0 g\u00e9rer : ssh-copy-id utilisateur@serveur<\/code>.<\/li>\n
  3. V\u00e9rifiez que vous pouvez vous connecter sans mot de passe avant d’aller plus loin \u2014 Ansible d\u00e9pend enti\u00e8rement de cet acc\u00e8s SSH fonctionnel.<\/li>\n<\/ol>\n
    L’inventaire : d\u00e9clarer vos machines<\/h2>\n
    L’inventaire liste les machines g\u00e9r\u00e9es, organis\u00e9es en groupes. Format INI simple (inventory.ini<\/code>) :<\/p>\n
    [web]\nweb01.example.local\nweb02.example.local\n\n[db]\ndb01.example.local\n\n[production:children]\nweb\ndb<\/code><\/pre>\n
    Un format YAML \u00e9quivalent est \u00e9galement possible et souvent pr\u00e9f\u00e9r\u00e9 dans les projets plus structur\u00e9s. Pour des infrastructures dynamiques (cloud, conteneurs), Ansible propose des inventaires dynamiques<\/strong> qui interrogent une API (AWS, Proxmox, etc.) au lieu d’un fichier statique.<\/p>\n
    Commandes ad-hoc : tester avant d’automatiser<\/h2>\n
    Avant d’\u00e9crire un playbook complet, une commande ad-hoc permet de v\u00e9rifier rapidement une action ponctuelle :<\/p>\n
    # Tester la connectivit\u00e9\nansible all -i inventory.ini -m ping\n\n# Ex\u00e9cuter une commande shell sur un groupe\nansible web -i inventory.ini -m command -a \"uptime\"\n\n# Installer un paquet (n\u00e9cessite les droits \u00e9lev\u00e9s)\nansible web -i inventory.ini -m apt -a \"name=curl state=present\" --become<\/code><\/pre>\n
    Le module ping<\/code> ne fait pas un ping r\u00e9seau classique : il v\u00e9rifie que Python est disponible sur la cible et que la connexion SSH + les identifiants fonctionnent \u2014 un premier test indispensable apr\u00e8s toute nouvelle installation.<\/p>\n
    \u00c9crire un premier playbook<\/h2>\n
    Un playbook est un fichier YAML qui d\u00e9crit un \u00e9tat d\u00e9sir\u00e9, ex\u00e9cut\u00e9 dans l’ordre, t\u00e2che par t\u00e2che :<\/p>\n
    ---\n- name: Installer et d\u00e9marrer Nginx\n  hosts: web\n  become: true\n  tasks:\n    - name: Installer le paquet nginx\n      ansible.builtin.apt:\n        name: nginx\n        state: present\n        update_cache: true\n\n    - name: D\u00e9marrer et activer le service\n      ansible.builtin.service:\n        name: nginx\n        state: started\n        enabled: true\n\n    - name: D\u00e9ployer la page d'accueil\n      ansible.builtin.template:\n        src: templates\/index.html.j2\n        dest: \/var\/www\/html\/index.html\n      notify: Recharger Nginx\n\n  handlers:\n    - name: Recharger Nginx\n      ansible.builtin.service:\n        name: nginx\n        state: reloaded<\/code><\/pre>\n
    Ex\u00e9cution : ansible-playbook -i inventory.ini site.yml<\/code>. Relancez-le une seconde fois : les t\u00e2ches d\u00e9j\u00e0 satisfaites remontent en ok<\/strong> plut\u00f4t qu’en changed<\/strong> \u2014 c’est l’idempotence en action, la preuve que le playbook ne casse rien \u00e0 la relance.<\/p>\n
    Le handler<\/strong> illustre un autre concept cl\u00e9 : une action d\u00e9clench\u00e9e uniquement si une t\u00e2che pr\u00e9c\u00e9dente a r\u00e9ellement chang\u00e9 quelque chose (ici, recharger Nginx seulement si la page a \u00e9t\u00e9 modifi\u00e9e), plut\u00f4t que de la relancer syst\u00e9matiquement \u00e0 chaque ex\u00e9cution.<\/p>\n
    Organiser en roles<\/h2>\n
    D\u00e8s qu’un playbook grossit, les roles<\/strong> permettent de d\u00e9couper la configuration en blocs r\u00e9utilisables (un role \u00ab\u00a0nginx\u00a0\u00bb, un role \u00ab\u00a0postgresql\u00a0\u00bb, un role \u00ab\u00a0durcissement-securite\u00a0\u00bb\u2026) :<\/p>\n
    ansible-galaxy init roles\/nginx<\/code><\/pre>\n
    Cette commande g\u00e9n\u00e8re l’arborescence standard (tasks\/<\/code>, handlers\/<\/code>, templates\/<\/code>, defaults\/<\/code>, vars\/<\/code>\u2026) que vous remplissez ensuite, puis r\u00e9f\u00e9rencez depuis un playbook :<\/p>\n
    ---\n- name: Configurer les serveurs web\n  hosts: web\n  become: true\n  roles:\n    - nginx<\/code><\/pre>\n
    Prot\u00e9ger les secrets avec ansible-vault<\/h2>\n
    Un mot de passe de base de donn\u00e9es ou une cl\u00e9 API n’a rien \u00e0 faire en clair dans un playbook versionn\u00e9 sur Git. ansible-vault<\/strong> chiffre le contenu sensible :<\/p>\n
    # Cr\u00e9er un fichier chiffr\u00e9\nansible-vault create group_vars\/db\/vault.yml\n\n# \u00c9diter un fichier existant\nansible-vault edit group_vars\/db\/vault.yml\n\n# Ex\u00e9cuter un playbook qui r\u00e9f\u00e9rence des variables chiffr\u00e9es\nansible-playbook site.yml --ask-vault-pass<\/code><\/pre>\n
    Bonnes pratiques<\/h2>\n
      \n
    • Versionnez vos playbooks dans Git<\/strong>, mais jamais le mot de passe vault en clair \u2014 utilisez un fichier de mot de passe hors d\u00e9p\u00f4t ou un gestionnaire de secrets externe.<\/li>\n
    • Testez d’abord en mode --check<\/code><\/strong> (simulation \u00e0 blanc) sur un environnement non critique avant d’ex\u00e9cuter un nouveau playbook en production.<\/li>\n
    • Utilisez des tags<\/strong> (--tags<\/code>) pour n’ex\u00e9cuter qu’une partie cibl\u00e9e d’un long playbook pendant le d\u00e9veloppement, sans tout rejouer.<\/li>\n
    • Documentez vos roles<\/strong> (README, valeurs par d\u00e9faut comment\u00e9es dans defaults\/main.yml<\/code>) \u2014 un role sans documentation redevient une bo\u00eete noire d\u00e8s que quelqu’un d’autre (ou vous, six mois plus tard) doit le r\u00e9utiliser.<\/li>\n<\/ul>\n
      Une fois cette base ma\u00eetris\u00e9e en ligne de commande, l’\u00e9tape naturelle suivante pour une \u00e9quipe est de piloter ces m\u00eames playbooks depuis une interface web centralis\u00e9e avec RBAC, planification et journalisation \u2014 c’est exactement le r\u00f4le d’AWX<\/strong>, couvert dans le tutoriel suivant.<\/p>\n","protected":false},"excerpt":{"rendered":"
      Configurer un serveur \u00e0 la main, puis le suivant, puis le suivant, en esp\u00e9rant avoir fait exactement les m\u00eames commandes \u00e0 chaque fois \u2014 c’est la d\u00e9finition m\u00eame du travail qui finit par vous exploser au visage un vendredi soir. Ansible automatise ce travail de fa\u00e7on reproductible, sans rien installer sur les machines g\u00e9r\u00e9es. Ce […]<\/p>\n","protected":false},"featured_media":0,"template":"","sv_tuto_categorie":[22],"class_list":["post-189","sv_tutoriel","type-sv_tutoriel","status-publish","hentry","sv_tuto_categorie-infrastructure"],"_links":{"self":[{"href":"https:\/\/asfy.fr\/index.php\/wp-json\/wp\/v2\/sv_tutoriel\/189","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/asfy.fr\/index.php\/wp-json\/wp\/v2\/sv_tutoriel"}],"about":[{"href":"https:\/\/asfy.fr\/index.php\/wp-json\/wp\/v2\/types\/sv_tutoriel"}],"version-history":[{"count":1,"href":"https:\/\/asfy.fr\/index.php\/wp-json\/wp\/v2\/sv_tutoriel\/189\/revisions"}],"predecessor-version":[{"id":191,"href":"https:\/\/asfy.fr\/index.php\/wp-json\/wp\/v2\/sv_tutoriel\/189\/revisions\/191"}],"wp:attachment":[{"href":"https:\/\/asfy.fr\/index.php\/wp-json\/wp\/v2\/media?parent=189"}],"wp:term":[{"taxonomy":"sv_tuto_categorie","embeddable":true,"href":"https:\/\/asfy.fr\/index.php\/wp-json\/wp\/v2\/sv_tuto_categorie?post=189"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}