Ansible
| Fiche express | |
|---|---|
| Type | Outil d'automatisation IT agentless (gestion de configuration, déploiement, orchestration) |
| Techno | Python, playbooks au format YAML |
| Connexion | SSH (WinRM pour Windows) — aucun agent à installer |
| Orchestration | Ansible Tower / AWX (interface web, RBAC, planification) |
| Alternatives | Puppet, Chef, SaltStack |
| Voir aussi | Ansible cmd · Ansible easystart · Ansible tower |
Ansible est un outil d'automatisation IT open source (Red Hat) orienté déploiement d'applications, gestion de configuration et orchestration. Contrairement à Puppet et Chef, qui reposent sur un agent installé sur chaque nœud géré, Ansible est agentless : il se connecte aux hôtes cibles par SSH (WinRM pour Windows) et n'exige qu'un interpréteur Python côté client. Cette simplicité de déploiement se paie en performance à grande échelle : l'exécution via SSH est plus lente que les architectures à agent de Puppet/Chef ou que le bus de messages de SaltStack.
Philosophiquement, Ansible est plus proche de SaltStack que de Puppet : configuration déclarative simple, pas de serveur central obligatoire, écosystème orienté praticien plutôt que reporting web avancé. Sa syntaxe YAML, jugée plus lisible que les DSL Ruby de Puppet/Chef, en a fait l'outil de gestion de configuration le plus adopté depuis le milieu des années 2010. L'interface web d'orchestration officielle est Ansible Tower (AWX en version communautaire).
Puppet, Chef, SaltStack : comparatif rapide
| Outil | Agent | Langage | Format | Particularité |
|---|---|---|---|---|
| Ansible | Non (SSH) | Python | YAML (playbooks) | Aucune infrastructure serveur obligatoire |
| Puppet | Oui (agent + serveur) | Ruby (DSL) | Manifests déclaratifs | Modèle pull, reporting web mature |
| Chef | Oui (agent + serveur) | Ruby (DSL) | Recipes/cookbooks | Proche de Puppet, moins de visibilité web |
| SaltStack | Oui par défaut (bus ZeroMQ), SSH possible | Python | YAML (states) | Le plus scalable, communication temps réel |
Inventaire
L'inventaire décrit les hôtes gérés et leur regroupement logique. Par défaut :
/etc/ansible/hosts (redéfinissable avec -i).
Hôtes et groupes
mail.example.com [webservers] foo.example.com bar.example.com [dbservers] one.example.com two.example.com three.example.com www[01:50].example.com db-[a:f].example.com
Les intervalles [01:50] et [a:f] permettent de déclarer une plage
d'hôtes en une seule ligne.
Paramètres de connexion par hôte
[targets] localhost ansible_connection=local other1.example.com ansible_connection=ssh ansible_user=svc-ansible other2.example.com ansible_connection=ssh ansible_user=svc-ansible
Variables d'hôte
[atlanta] host1 http_port=80 maxRequestsPerChild=808 host2 http_port=303 maxRequestsPerChild=909
Variables de groupe
[atlanta] host1 host2 [atlanta:vars] ntp_server=ntp.atlanta.example.com proxy=proxy.atlanta.example.com
Groupes de groupes
[atlanta] host1 host2 [raleigh] host2 host3 [southeast:children] atlanta raleigh [southeast:vars] some_server=foo.southeast.example.com halon_system_timeout=30 escape_pods=2 [usa:children] southeast northeast southwest northwest
Séparer les variables du fichier d'inventaire
Plutôt que de tout mettre dans le fichier hosts, les variables peuvent être
éclatées dans des répertoires dédiés, lus automatiquement par Ansible :
/etc/ansible/group_vars/raleigh /etc/ansible/group_vars/webservers /etc/ansible/host_vars/foosball
ou, pour organiser un groupe en plusieurs fichiers thématiques :
/etc/ansible/group_vars/raleigh/db_settings /etc/ansible/group_vars/raleigh/cluster_settings
Contenu au format YAML :
ntp_server: acme.example.org database_server: storage.example.org
Paramètres de connexion
ansible_connection définit le type de connexion : local,
smart (défaut), ssh ou paramiko.
ansible_host Nom/IP réel de l'hôte, si différent de l'alias d'inventaire ansible_port Port SSH, si différent de 22 ansible_user Utilisateur SSH par défaut (ancien nom : ansible_ssh_user) ansible_ssh_pass Mot de passe SSH (déconseillé — préférer --ask-pass ou une clé) ansible_ssh_private_key_file Clé privée à utiliser (utile avec plusieurs clés, sans agent SSH) ansible_ssh_common_args Arguments SSH additionnels (ex. ProxyCommand), en plus de ssh_args d'ansible.cfg
Depuis Ansible 2.0, les variables historiques ansible_ssh_user,
ansible_ssh_host et ansible_ssh_port ont été renommées
respectivement ansible_user, ansible_host et ansible_port
(les anciens noms restent acceptés en alias).
Débogage
# Collecter les facts d'un groupe/hôte
ansible webservers -m setup
# Afficher une variable dans un playbook
- name: debug user
debug:
msg: "{{ user }}"
Voir aussi
- Ansible cmd — commandes ad-hoc (exécution ponctuelle, hors playbook)
- Ansible easystart — prise en main pas à pas (échange de clé, premier playbook)
- Ansible tower — interface web d'orchestration (AWX / Ansible Automation Platform)
- Puppet · Chef · SaltStack — alternatives à agent ou hybrides
- GuardRail — supervision de la gestion de configuration
- Frontière IaC — Terraform, Ansible, GitOps — répartition des rôles avec Terraform