Ansible et l'automatisation

Gérer dix serveurs à la main, c'est faisable. Gérer cent serveurs à la main, c'est une source permanente d'incidents. L'automatisation de l'infrastructure répond à un problème simple : garantir qu'un état cible est appliqué de façon identique, reproductible et traçable sur n'importe quel nombre de machines.

Le problème que résout Ansible

Avant l'automatisation, la configuration d'un serveur reposait sur des runbooks, des scripts shell éparpillés, et la mémoire des ingénieurs. Le résultat : des environnements qui dérivent progressivement, des serveurs "flocons de neige" impossibles à reproduire, et des nuits blanches lors des mises en production.

Ansible apporte trois choses fondamentales :

• Idempotence : appliquer un playbook dix fois produit le même résultat qu'une seule application. L'outil vérifie l'état actuel avant d'agir.
• Déclarativité : on décrit ce que le système doit être, pas les commandes à exécuter pour y arriver.
• Traçabilité : les playbooks sont du code versionnable. L'historique Git est l'historique de l'infrastructure.

Architecture : le modèle push agentless

Ansible adopte un modèle push : le nœud de contrôle (votre poste ou un serveur dédié) se connecte aux cibles via SSH et exécute les tâches. Il n'y a rien à installer sur les machines cibles au-delà de Python et d'un daemon SSH.

C'est une différence architecturale majeure avec des outils comme Puppet ou Chef, qui fonctionnent en mode pull : un agent tourne en permanence sur chaque machine, récupère sa configuration depuis un serveur central, et l'applique localement. Ce modèle offre une convergence automatique, mais nécessite de gérer un parc d'agents.

Comparaison avec les alternatives

• Puppet : DSL propriétaire (PuppetDSL), modèle pull avec agent, convergence automatique, courbe d'apprentissage élevée. Pertinent pour des flottes très grandes avec convergence garantie.
• Chef : Ruby, modèle pull, agent requis, très flexible mais verbeux. Peu utilisé sur les nouveaux projets.
• Salt (SaltStack) : modèle push et pull, très performant sur de très grandes flottes grâce au bus de messages ZeroMQ. Plus complexe à opérer qu'Ansible.
• Ansible : YAML, agentless, SSH, courbe d'apprentissage faible. Standard de fait pour le provisioning et la gestion de configuration sur des flottes de taille intermédiaire.

Cas d'usage couverts par Ansible

• Gestion de configuration : maintenir l'état d'un système (packages installés, fichiers de config, services actifs).
• Provisioning : créer et configurer des VMs, des conteneurs, des instances cloud dès leur création.
• Déploiement applicatif : orchestrer un déploiement rolling, vider un cache, redémarrer les services dans le bon ordre.
• Orchestration : coordonner des actions sur plusieurs groupes de serveurs en séquence (retirer du LB, mettre à jour, remettre en service).

Limites à connaître

Ansible n'est pas un outil de gestion d'état (pas de state file comme Terraform). Si une ressource est supprimée manuellement entre deux runs, Ansible ne la recréera que lors du prochain run. Sur des flottes de plusieurs milliers de machines, les performances sans AWX ou Mitogen peuvent devenir un goulot d'étranglement. Enfin, les playbooks YAML longs deviennent rapidement difficiles à maintenir sans une architecture en rôles.

Ces limites sont connues et adressées dans les sections avancées de cette formation.