Automatiser le déploiement d’une flotte de sites WordPress avec Ansible

Quarante sites clients, quarante configurations serveur légèrement différentes, et jusqu’à présent, une checklist en texte suivie manuellement à chaque nouveau projet. Le nombre de sites gérés par une agence grandit toujours plus vite que le temps disponible pour les déployer soigneusement à la main, et chaque déploiement manuel est une occasion supplémentaire d’oublier une étape.

Ansible répond précisément à ce type de situation : décrire une fois, sous forme de tâches déclaratives, tout ce qu’un déploiement WordPress doit accomplir, puis appliquer ce même jeu de tâches à des dizaines de serveurs différents, chacun avec ses propres variables.

Structurer le rôle plutôt qu’empiler des scripts

Un rôle Ansible dédié à WordPress regroupe les tâches par responsabilité : installation des paquets système, configuration de PHP-FPM, mise en place de la base de données, déploiement du code applicatif. Cette structure se retrouve dans l’arborescence classique d’un rôle :

roles/wordpress/
├── tasks/
│   ├── main.yml
│   ├── php.yml
│   ├── mysql.yml
│   └── deploy.yml
├── templates/
│   └── wp-config.php.j2
└── defaults/
    └── main.yml

Paramétrer par projet via les variables

Le fichier defaults/main.yml définit des valeurs par défaut raisonnables, que chaque projet peut ensuite surcharger dans son propre inventaire :

php_version: "8.3"
wp_memory_limit: "256M"
db_name: "{{ inventory_hostname }}_wp"

Le fichier wp-config.php lui-même se génère à partir d’un modèle Jinja2, ce qui évite d’écrire la moindre configuration à la main sur le serveur cible :

define( 'DB_NAME', '{{ db_name }}' );
define( 'WP_MEMORY_LIMIT', '{{ wp_memory_limit }}' );

L’idempotence : rejouer sans casser

La force d’Ansible par rapport à un script bash classique tient à l’idempotence de ses modules : exécuter le même playbook une seconde fois sur un serveur déjà déployé ne doit rien casser, ni dupliquer une configuration existante. Le module template, utilisé pour générer wp-config.php, ne réécrit le fichier que si son contenu a réellement changé :

- name: Déployer wp-config.php
  template:
    src: wp-config.php.j2
    dest: /var/www/{{ inventory_hostname }}/wp-config.php
    mode: '0640'

Déployer le code applicatif lui-même

Le déploiement du thème et des extensions se fait généralement via un module Git, pointant vers une balise ou une branche spécifique par projet, ce qui garantit qu’un déploiement peut toujours être reproduit à l’identique :

- name: Déployer le code du site
  git:
    repo: "{{ site_repo }}"
    dest: "/var/www/{{ inventory_hostname }}"
    version: "{{ site_version }}"

Exécuter sur toute la flotte, ou un site à la fois

L’inventaire Ansible regroupe les serveurs par catégorie, ce qui permet de cibler un sous-ensemble précis lors d’un déploiement plutôt que d’appliquer une mise à jour à l’ensemble de la flotte d’un coup :

ansible-playbook -i inventaire.ini deploy.yml --limit clients_php83

Une discipline qui a évité plusieurs incidents sur cette flotte : toujours exécuter le playbook en mode --check avant l’exécution réelle sur un site en production, pour visualiser les changements prévus sans les appliquer.

Gérer les secrets sans les versionner en clair

Chaque site client possède ses propres identifiants de base de données et ses propres clés de sécurité, qui ne doivent jamais apparaître en clair dans l’inventaire versionné avec le reste du projet. Ansible Vault chiffre ces variables sensibles directement dans le dépôt, sans nécessiter de service de secrets externe supplémentaire :

ansible-vault encrypt group_vars/client_a/secrets.yml
ansible-playbook -i inventaire.ini deploy.yml --ask-vault-pass

Étendre le rôle à mesure que la flotte grandit

Un rôle Ansible bien conçu dès le départ absorbe naturellement de nouveaux besoins sans réécriture complète : ajout d’un module de sauvegarde automatisée, bascule vers une nouvelle version de PHP pour un sous-ensemble de clients, ou intégration d’un certificat TLS renouvelé automatiquement via une tâche supplémentaire dans le même rôle. La structure initiale, pensée pour être paramétrable plutôt que figée, est ce qui permet à l’agence d’absorber la croissance de sa flotte sans multiplier les scripts isolés au fil des projets.

En résumé

Un playbook Ansible bien structuré transforme le déploiement d’une flotte de sites WordPress en une opération reproductible et documentée par le code lui-même, plutôt qu’en une checklist suivie de mémoire. Le temps investi dans la structuration initiale du rôle se rembourse dès le cinquième ou sixième site déployé avec le même jeu de tâches.