Ansible : structurer ses rôles pour un parc qui scale

Un playbook Ansible écrit vite devient vite ingérable. Les rôles bien structurés sont la différence entre un parc de 10 serveurs et un parc de 500 serveurs gérable par la même équipe.

L’organisation qui scale

infrastructure/
├── inventories/
│   ├── production/
│   │   ├── hosts.yml          # inventaire statique ou script dynamique
│   │   └── group_vars/
│   │       ├── all.yml        # variables communes à tous les hosts
│   │       ├── webservers.yml # variables du groupe webservers
│   │       └── databases.yml
│   └── staging/
│       └── hosts.yml
├── roles/
│   ├── common/                # rôle appliqué à tous les serveurs
│   ├── nginx/
│   ├── postgresql/
│   └── myapp/
├── playbooks/
│   ├── site.yml               # playbook principal — tout le parc
│   ├── webservers.yml         # playbook ciblé
│   └── deploy.yml
└── ansible.cfg

L’idempotence : la propriété fondamentale

Un playbook Ansible doit être idempotent — le lancer une fois ou dix fois sur le même serveur doit produire le même résultat. C’est ce qui rend Ansible utilisable en production : on peut lancer le playbook pour corriger une dérive de configuration sans craindre de casser quelque chose.

# ❌ Pas idempotent — ajoute la ligne à chaque run
- name: Add cron job
  ansible.builtin.shell: echo "0 3 * * * /usr/local/bin/backup.sh" >> /etc/crontab

# ✅ Idempotent — ansible.builtin.cron gère l'idempotence
- name: Schedule backup cron
  ansible.builtin.cron:
    name: "Daily backup"
    minute: "0"
    hour: "3"
    job: "/usr/local/bin/backup.sh"
    user: root

Variables : priorité et sécurité

Ansible a 22 niveaux de priorité pour les variables. Les essentiels à connaître :

# group_vars/all.yml — variables par défaut pour tous les hosts
nginx_worker_processes: auto
nginx_listen_port: 80
app_environment: production

# group_vars/webservers.yml — surcharge pour le groupe webservers
nginx_worker_connections: 2048

# host_vars/srv-web-01.yml — surcharge pour un host spécifique
nginx_listen_port: 8080

Pour les secrets, utilisez Ansible Vault :

# Chiffrer un fichier de variables sensibles
ansible-vault encrypt group_vars/production/vault.yml

# Dans vault.yml
vault_db_password: "super-secret-password"
vault_api_key: "secret-api-key"

Tags : exécuter seulement ce dont on a besoin

- name: Install and configure nginx
  hosts: webservers
  roles:
    - role: nginx
      tags: [nginx, web]
    - role: ssl-certs
      tags: [nginx, ssl]
    - role: myapp
      tags: [app]

# Déployer uniquement l'application (pas nginx, déjà configuré)
ansible-playbook playbooks/site.yml --tags app

# Exécuter tout sauf les tâches SSL (déjà configurées)
ansible-playbook playbooks/site.yml --skip-tags ssl

# Mode check : voir ce qui changerait sans l'appliquer
ansible-playbook playbooks/site.yml --check --diff

Notre formation Ansible couvre la structuration et le scaling des playbooks avec des ateliers sur des environnements réels.