Ansible

Ansible est devenu le standard de l'automatisation IT depuis plus de dix ans. Sa promesse est simple : décrire l'état désiré de vos serveurs (paquets installés, fichiers de config, services actifs) dans des fichiers YAML lisibles, et laisser l'outil les appliquer. Pas d'agent à installer sur les serveurs cibles : juste du SSH. Pour une équipe qui gère 5 serveurs ou plus, c'est l'outil qui transforme le bricolage manuel en processus reproductible.

• →TerraformPour le provisioning d'infrastructure plutôt que la configuration, souvent complémentaireVoir la page
• →PuppetSi vous gérez 10 000+ serveurs où le modèle pull-based avec agent devient pertinent
• →ChefSi votre équipe préfère un DSL Ruby plutôt que du YAML
• →SaltStackSi vous avez besoin de l'event-driven automation à grande échelle
• →Scripts bash versionnésPour 1-2 serveurs simples : Ansible serait du sur-engineering

1. 01

   Inventaire propre : tous les serveurs, groupes et variables documentés en YAML

2. 02

   Playbooks idempotents, la règle d'or : on peut relancer 10 fois sans dégât

3. 03

   Rôles réutilisables uniquement quand le pattern est confirmé sur 2-3 usages

4. 04

   Ansible Vault pour tous les secrets : jamais de mot de passe en clair dans les playbooks

5. 05

   Intégration CI pour les exécutions automatisées et les rapports de drift

• Ansible ou Terraform : il faut choisir ?

  Non, ce sont des outils complémentaires. Terraform provisionne (crée des serveurs, bases, réseaux), Ansible configure (installe des paquets, déploie du code, gère des services). Beaucoup d'équipes utilisent les deux : Terraform pour la couche IaaS, Ansible pour la couche OS et applicative. L'erreur classique est de tout faire avec un seul.
• Pourquoi Ansible plutôt que Puppet ou Chef ?

  Approche agentless. Puppet et Chef nécessitent un agent installé sur chaque serveur géré, ce qui ajoute une dépendance, un port ouvert, un service à maintenir. Ansible utilise juste SSH. Votre serveur n'a besoin de rien. Pour une PME, c'est nettement plus simple à mettre en place et à auditer. Puppet/Chef gardent un avantage sur les très gros parcs (10 000+ serveurs) où la pull-based approach pèse moins.
• Combien coûte la mise en place d'Ansible ?

  Pour une PME avec 5-15 serveurs, comptez 3 à 8 jours de mise en place initiale : inventaire propre, premiers playbooks (mise à jour OS, déploiement app, sauvegardes), intégration CI. Investissement amorti en 2-3 mois par la réduction du temps passé en maintenance manuelle.
• C'est vraiment sans agent ?

  Oui. Ansible se connecte en SSH (ou WinRM pour Windows) et exécute des modules Python qui ne laissent aucune trace persistante. Pas de daemon, pas de port à ouvrir vers Ansible. Le serveur cible n'a même pas besoin de savoir qu'il est managé par Ansible. Seuls prérequis : SSH actif et Python sur la cible (déjà présent sur 99 % des distributions Linux).
• Qu'est-ce qu'un playbook idempotent et pourquoi ça compte ?

  Idempotent veut dire qu'on peut relancer le playbook autant de fois qu'on veut sans dégât. La première exécution crée l'état désiré ; les suivantes vérifient et ne modifient rien si tout est déjà correct. C'est la propriété la plus importante d'Ansible : on peut auditer, vérifier, recréer sans peur. Un playbook non idempotent (qui plante en deuxième exécution) est un bug, pas une feature.