Imaginez un aéroport. Des dizaines d’avions au sol et en vol, chacun avec son propre équipage. Comment on gère tout ça sans qu’un contrôleur ne soit obligé de monter physiquement dans chaque cockpit pour donner ses instructions ?
Par radio. Le contrôleur aérien envoie ses instructions à distance, en utilisant l’équipement radio déjà présent dans chaque avion. Il n’a rien besoin d’installer à bord : la radio y est déjà.
Ansible fonctionne exactement comme ça.
Le problème que ça résout
Dans le service IT de Nordika, la situation est devenue intenable. Le parc de serveurs a grossi : plusieurs sites, des dizaines de machines. Se connecter une par une en SSH pour taper les mêmes commandes, c’est :
- lent (imaginez faire ça sur 30 serveurs) ;
- source d’erreurs (on oublie une machine, on tape une commande de travers sur une autre) ;
- impossible à tracer (qui a fait quoi, quand, sur quelle machine ?).
Ansible permet de décrire une seule fois ce qu’on veut faire, et de l’appliquer instantanément à toute la flotte de serveurs.
Agentless : pas de tour de contrôle installée à bord
C’est le point qui distingue vraiment Ansible d’autres outils comme Puppet ou Chef (qu’on comparera dans la prochaine leçon) : il n’y a rien à installer sur les serveurs gérés.
Pas de démon qui tourne en permanence. Pas de certificat à maintenir. Pas de port supplémentaire à ouvrir dans le pare-feu.
Ansible se connecte simplement en SSH — le canal radio que vous utilisez déjà pour administrer vos serveurs — dépose un petit module Python le temps d’exécuter une action, récupère le résultat, puis nettoie derrière lui. La machine gérée n’a besoin que de deux choses : un accès SSH, et Python installé (sauf exception, qu’on verra en 1.5 avec les commandes RAW).
Le nœud de contrôle : votre tour de contrôle
La machine depuis laquelle vous pilotez tout ça s’appelle le nœud de contrôle (control node). C’est là qu’Ansible est installé, c’est là que vous écrivez vos instructions, et c’est depuis là qu’elles partent vers toute la flotte.
Les machines pilotées s’appellent les nœuds gérés (managed nodes) — dans notre analogie, les avions.
┌─────────────────────┐
│ Nœud de contrôle │ ← Ansible installé ici
│ (la tour) │
└──────────┬───────────┘
│ SSH (la radio)
┌─────┼─────┬─────────┐
▼ ▼ ▼ ▼
Serveur Serveur Serveur Serveur
web1 web2 db1 dns1
(avion) (avion) (avion) (avion)
Ce qu’on ne fait pas encore
À ce stade, on ne parle que du modèle. Pas encore de playbook, pas encore de commande à taper. L’objectif de cette leçon, c’est simplement de comprendre pourquoi Ansible est construit comme ça — et surtout pourquoi cette absence d’agent a des conséquences très concrètes sur votre quotidien d’admin : pas de mise à jour d’agent à gérer, pas de compatibilité de version entre agent et serveur central à surveiller.
Dans la prochaine leçon, on compare concrètement Ansible à Puppet, Chef et Salt, pour bien cerner ce qui le rend différent — et pourquoi ce choix a un vrai impact sur le temps que vous allez passer en administration.