1.5 : Commandes RAW : piloter une machine qui n’a pas encore Python (bootstrap)

On l’a vu en 1.3 : Ansible a besoin de Python sur la machine cible pour déposer et exécuter ses modules. Mais que se passe-t-il si l’avion en question n’a aucun équipement de bord du tout ?

C’est le cas de certaines images système très allégées : une image cloud minimaliste, un vieux routeur/switch réseau, ou certaines images de conteneurs construites pour être les plus légères possible, sans aucun interpréteur Python.

Le module raw : la radio brute

Le module raw est une exception dans tout Ansible : c’est le seul module qui n’a pas besoin de Python sur la cible. Il ne dépose rien, ne fait aucune vérification d’état, il se contente d’envoyer une commande brute via SSH, un peu comme si vous tapiez directement dans un terminal SSH classique.

ansible tous-les-minimalistes -i inventaire.yaml -m raw -a "apt update && apt install -y python3"

C’est exactement son rôle : installer Python, pour que tous les autres modules puissent ensuite fonctionner normalement.

Pourquoi ne pas tout faire en raw, alors ?

Bonne question, et la réponse est importante : parce que raw n’a aucune idempotence. Il ne sait pas comparer un état avant/après, il exécute la commande, point. Relancez le même playbook en raw dix fois, et la commande sera exécutée dix fois, que ce soit nécessaire ou non.

C’est l’opposé complet de la philosophie Ansible qu’on a posée en 1.1 : décrire un état voulu, et laisser Ansible agir uniquement sur l’écart. raw casse ce principe, volontairement, pour un seul usage : sortir d’une situation où rien d’autre ne peut fonctionner.

Un playbook typique de bootstrap

En pratique, on retrouve souvent ce schéma dans un playbook de mise en route :

---
- name: Bootstrap des machines sans Python
  hosts: nouvelles_machines
  gather_facts: no   # impossible de collecter les facts sans Python !

  tasks:
    - name: Installer Python via une commande brute
      ansible.builtin.raw: apt update && apt install -y python3
      changed_when: false

    - name: Vérifier que Python est bien présent
      ansible.builtin.raw: python3 --version
      register: python_check
      changed_when: false

    - name: Afficher la version détectée
      ansible.builtin.debug:
        var: python_check.stdout

Notez le gather_facts: no : sans Python, Ansible ne peut même pas collecter les informations système (les facts, qu’on verra en section 4). Et le changed_when: false : puisque raw ne sait pas déterminer si quelque chose a changé, on le précise nous-mêmes pour éviter un playbook qui affiche changed à chaque exécution, même quand tout est déjà en place.

Une fois ce playbook de bootstrap passé, toutes les tâches suivantes du même playbook (ou d’un autre) peuvent utiliser les modules normaux (apt, service, user…), puisque Python est maintenant disponible.

À retenir

• raw = la seule commande qui fonctionne sans Python sur la cible.
• Elle n’est pas idempotente : à réserver au strict nécessaire (bootstrap, dépannage d’urgence).
• Dès que Python est disponible, on revient immédiatement aux modules classiques.

Dans la prochaine leçon, on regarde du côté de Windows : peut-on aussi le piloter en SSH depuis notre tour de contrôle ?