1.3 : Installation et prérequis (SSH + Python sur les cibles)

Avant de piloter la moindre instruction depuis notre tour de contrôle, il faut d’abord l’équiper. Contrairement à Docker ou PowerShell, il n’y a qu’un seul endroit où installer quelque chose : le nœud de contrôle. Les avions (serveurs gérés), eux, ont juste besoin d’avoir leur radio (SSH) allumée et leur équipement de base (Python) à bord.

Sur le nœud de contrôle

Debian / Ubuntu :

sudo apt update
sudo apt install ansible

Fedora / RHEL / AlmaLinux :

sudo dnf install ansible

macOS (via Homebrew) :

brew install ansible

Via pip (fonctionne partout, y compris dans un environnement virtuel Python) :

pip install ansible

💡 Le paquet ansible livré par votre distribution peut être une version un peu ancienne. Pour rester à jour, pip install ansible dans un environnement virtuel est souvent préférable une fois que vous serez plus à l’aise.

Vérifiez que tout est bien installé :

ansible --version

Vous devriez voir la version d’Ansible, l’emplacement du fichier de configuration, et la version de Python utilisée.

Sur les nœuds gérés (les avions)

C’est là que beaucoup de débutants butent. Il n’y a rien à installer manuellement dans la majorité des cas, mais deux prérequis doivent être en place :

1. Un accès SSH fonctionnel

Le compte utilisé doit pouvoir se connecter en SSH, idéalement par clé plutôt que par mot de passe (on configurera ça proprement dans le TP de cette section).

2. Python installé

Ansible dépose et exécute ses modules en Python sur la machine cible. Bonne nouvelle : la quasi-totalité des distributions Linux serveur (Debian, Ubuntu, RHEL, AlmaLinux…) ont Python préinstallé par défaut. Vous n’avez donc, la plupart du temps, strictement rien à faire ici.

Le cas où ça coince : une image minimaliste (certains conteneurs, certaines images cloud allégées, ou de vieux systèmes) sans Python du tout. On traite ce cas précis dans la leçon 1.5 avec les commandes RAW, qui permettent justement de contacter un avion qui n’a pas encore son équipement de bord.

Vérifier que tout communique

Une fois Ansible installé sur le nœud de contrôle et l’accès SSH en place sur au moins une machine, on peut faire un premier test de contact radio :

ansible all -i <ip_ou_nom_serveur>, -m ping -u <utilisateur>

Notez la virgule après l’adresse : c’est ce qui indique à Ansible qu’il s’agit d’une liste d’hôtes tapée directement, et non un fichier d’inventaire. On verra la bonne façon de faire ça, avec un vrai fichier d’inventaire, dès la leçon suivante.

Si tout est en place, vous devriez voir une réponse SUCCESS avec "ping": "pong". Premier contact radio établi.

Le fichier ansible.cfg (aperçu)

Ansible lit sa configuration dans un fichier ansible.cfg (dans le dossier courant, dans votre dossier utilisateur, ou globalement dans /etc/ansible/). On n’y touche pas encore à ce stade — on y reviendra plus tard pour ajuster des réglages comme le nombre de connexions parallèles ou l’emplacement par défaut de l’inventaire.

Dans la prochaine leçon, premier vrai contact avec les commandes ad-hoc : ansible -m et -a, pour donner des ordres ponctuels à la flotte sans encore écrire de playbook.