Reprenons notre analogie de la tour de contrôle. On a vu qu’Ansible communique par radio (SSH), sans rien installer à bord des avions. Mais ce n’est pas la seule façon de faire de l’automatisation. D’autres outils existent, avec une philosophie différente.
Voici les principaux, et pourquoi le choix entre eux n’est pas juste une question de goût.
Puppet et Chef : un agent installé à bord
Avec Puppet et Chef, chaque avion (serveur) embarque son propre équipement de bord : un agent installé et actif en permanence.
Concrètement, ça veut dire :
- un démon qui tourne sur chaque serveur géré ;
- un serveur central à qui l’agent va régulièrement demander « qu’est-ce que je dois faire ? » (modèle pull) ;
- souvent, un système de certificats à gérer entre l’agent et le serveur central.
L’avantage : une fois en place, les agents vérifient et corrigent l’état des machines automatiquement, à intervalle régulier, sans qu’on ait besoin de déclencher quoi que ce soit.
L’inconvénient, et c’est celui qui a fait le plus mal à Nordika par le passé : il faut installer, maintenir, et mettre à jour un agent sur chaque serveur. Un agent qui n’a pas la bonne version, un certificat expiré, et c’est toute une machine qui sort du radar sans que personne ne le remarque tout de suite.
Salt : un entre-deux
Salt (ou SaltStack) peut fonctionner avec un agent (le minion) qui communique avec un serveur central (le master) via un bus de messages, ce qui le rend très rapide à grande échelle. Il propose aussi un mode sans agent (Salt SSH), plus proche d’Ansible, mais c’est rarement le mode utilisé en pratique.
Ansible : agentless, en mode push
Ansible fait l’inverse de Puppet/Chef sur un point essentiel : c’est vous qui déclenchez l’exécution, depuis le nœud de contrôle, quand vous le décidez (modèle push). Rien ne tourne en tâche de fond sur les serveurs gérés entre deux exécutions.
| Ansible | Puppet / Chef | Salt | |
|---|---|---|---|
| Agent sur les serveurs | ❌ Non | ✅ Oui | Selon le mode |
| Modèle | Push (vous déclenchez) | Pull (l’agent interroge) | Push ou pull |
| Langage | YAML | DSL propre (Puppet), Ruby (Chef) | YAML + Jinja |
| Vérification continue | ❌ Non (à la demande) | ✅ Oui (automatique) | ✅ Oui (si agent) |
| Courbe d’apprentissage | Plutôt douce | Plus raide | Moyenne |
Alors, lequel choisir ?
Pour Nordika, la réponse a été simple : une PME avec un parc de serveurs qui grandit, mais pas encore une armée d’admins dédiés à la maintenance d’infrastructure. Pas besoin d’un agent qui tourne en permanence et qu’il faut surveiller — juste besoin de pouvoir dire « fais ça sur ces 15 serveurs » et que ce soit fait, correctement, à chaque fois.
C’est le profil typique où Ansible gagne : YAML plus simple à lire que du Ruby ou un DSL propriétaire, rien à installer sur les cibles, et une syntaxe qu’un admin système comprend en quelques heures sans être développeur.
Ceci dit, il n’y a pas de mauvais choix universel. Si vous gérez des milliers de serveurs avec vérification de conformité en continu, Puppet ou Salt en mode agent ont de vrais arguments. Retenez surtout ceci : le modèle push/pull et agent/agentless sont les deux questions à vous poser avant de choisir un outil, pas juste « lequel est à la mode ».
Dans la prochaine leçon, on installe Ansible pour de vrai, et on vérifie que tout fonctionne avant d’attaquer les premières commandes.