Docker est devenu un standard pour déployer des applications web : portabilité, isolation, reproductibilité. WordPress n’y échappe pas : de nombreux développeurs et agences choisissent de dockeriser leurs sites WordPress pour simplifier les environnements de développement, les tests, voire la production.
Dans ce guide, nous allons voir comment concevoir une architecture Docker pour WordPress :
séparation des services (PHP, base de données, reverse proxy), utilisation de docker-compose,
gestion des volumes, backups et limites à connaître avant de basculer tout votre parc en conteneurs.
Résumé rapide : Pour dockeriser WordPress, partez sur une architecture
multi-services (PHP-FPM, Nginx/Apache, MariaDB, éventuellement Redis), orchestrée par
docker-compose, avec des volumes persistants pour les fichiers et la base. Docker simplifie les
environnements et les déploiements, mais ne remplace pas la réflexion sur la sécurité, les backups et la
performance.
Sommaire
1. Pourquoi dockeriser WordPress ?
Les motivations principales :
- Reproductibilité : le même stack sur tous les environnements (dev, préprod, prod).
- Isolation : chaque service isolé dans son conteneur, avec ses versions propres.
- Portabilité : déplacer un projet d’un serveur à un autre en gardant la même configuration.
- Automatisation : intégration plus naturelle dans des pipelines CI/CD.
Pour un développeur freelance ou une agence, Docker permet d’éviter les “ça marche sur ma machine mais pas chez le client”, de standardiser les environnements et de déployer des stacks complexes plus facilement.
2. Architecture de base pour WordPress sous Docker
Une architecture saine pour WordPress sous Docker repose en général sur plusieurs conteneurs :
- Un conteneur PHP-FPM + WordPress : le code WordPress et PHP.
- Un conteneur serveur web (Nginx ou Apache) : sert le contenu HTTP/HTTPS.
- Un conteneur base de données (MariaDB/MySQL).
- Optionnel : Redis pour le cache objet, phpMyAdmin pour l’administration SQL.
Chaque conteneur a une responsabilité claire. Les fichiers WordPress (thèmes, plugins, uploads) doivent être persistés via des volumes, sous peine de tout perdre à chaque recréation du conteneur.
3. Exemple de fichier docker-compose pour WordPress
Voici une architecture type (simplifiée) avec Nginx + PHP-FPM + MariaDB :
version: '3.9'
services:
db:
image: mariadb:10.11
environment:
- MYSQL_DATABASE=wordpress
- MYSQL_USER=wp_user
- MYSQL_PASSWORD=motdepasse
- MYSQL_ROOT_PASSWORD=rootpass
volumes:
- db_data:/var/lib/mysql
wordpress:
image: wordpress:php8.2-fpm
environment:
- WORDPRESS_DB_HOST=db:3306
- WORDPRESS_DB_USER=wp_user
- WORDPRESS_DB_PASSWORD=motdepasse
- WORDPRESS_DB_NAME=wordpress
volumes:
- wp_data:/var/www/html
nginx:
image: nginx:stable
ports:
- "80:80"
volumes:
- wp_data:/var/www/html:ro
- ./nginx.conf:/etc/nginx/nginx.conf:ro
depends_on:
- wordpress
volumes:
db_data:
wp_data:
Cet exemple n’inclut pas encore SSL, mais montre la séparation des rôles. Le conteneur Nginx sert les fichiers et passe le PHP au conteneur WordPress (PHP-FPM), tandis que la base est isolée dans son propre conteneur.
4. Volumes, sauvegardes et mises à jour
La clé d’un setup Docker fiable est la gestion des données persistantes :
4.1. Volumes pour WordPress
Le volume wp_data contient :
- le cœur WordPress,
- les thèmes, plugins,
- les uploads (images, fichiers),
- les fichiers de configuration.
C’est ce volume qu’il faudra sauvegarder régulièrement (tar + envoi externe). Vous pouvez aussi structurer le
volume pour ne persister que wp-content et certaines configs, en reconstruisant le cœur depuis
l’image officielle au besoin.
4.2. Sauvegardes de la base
Le volume db_data contient les données MariaDB. Pour les sauvegardes, il est souvent plus propre
d’utiliser mysqldump dans un conteneur dédié ou un cron côté host :
docker exec -t mon_stack_db mysqldump -u wp_user -pmotdepasse wordpress > backup.sql
Ensuite, vous archivez et externalisez ces dumps comme sur un serveur “classique”.
4.3. Mises à jour
Les mises à jour se font à deux niveaux :
- WordPress (plugins, thèmes, cœur) : via l’admin, comme d’habitude.
- Images Docker : en reconstruisant/pullant les nouvelles images (WordPress, PHP, base).
Il est important de tester les nouvelles versions d’images sur un environnement de préprod avant de les déployer en production, surtout pour les mises à jour majeures de PHP ou de la base.
5. Docker et multi-sites / plusieurs instances WordPress
Il existe plusieurs stratégies pour héberger plusieurs sites WordPress avec Docker :
- Un stack par site (docker-compose séparé) : isolation maximale, mais plus de conteneurs à gérer.
- Un stack mutualisé avec :
- un reverse proxy (Nginx ou Traefik) en frontal,
- plusieurs services WordPress derrière, chacun avec sa base,
- des réseaux Docker internes pour sécuriser la communication.
Pour un parc de sites, la seconde approche (reverse proxy + multiples services WordPress) est souvent plus pratique, surtout si vous utilisez Traefik pour gérer automatiquement les certificats SSL (Let’s Encrypt).
6. Avantages et limites de Docker pour WordPress
Avantages :
- Environnements de dev/prod alignés.
- Facilité de réplication d’un projet (sur un autre serveur, chez un autre client).
- Isolation des versions PHP/MySQL par projet.
- Intégration naturelle dans les workflows DevOps.
Limites / points de vigilance :
- Complexité initiale (surtout pour les débutants serveur).
- Nécessité de bien gérer les volumes et les sauvegardes.
- Monitoring et logs à adapter (plusieurs conteneurs à suivre).
- Sur de petits VPS, la surcharge Docker peut être non négligeable.
En résumé : Docker n’est pas “magique”, mais bien utilisé, il peut apporter beaucoup de confort et de sécurité opérationnelle.
FAQ – Docker & WordPress
Docker rend-il mon WordPress plus sécurisé ?
Docker apporte de l’isolation, mais ne remplace pas les bonnes pratiques de sécurité. Vous devez toujours sécuriser WordPress, PHP, la base, les accès SSH, les backups, etc. Disons que Docker facilite certaines choses (rebuild, isolation de versions), mais ne protège pas à lui seul contre un plugin vulnérable.
Docker est-il adapté à un gros site WordPress à fort trafic ?
Oui, mais dans ce cas, on s’oriente souvent vers des architectures plus avancées : plusieurs conteneurs WordPress derrière un load balancer, base de données gérée séparément (cluster), Redis partagé, stockage des médias externe (S3, etc.). Docker est une brique, pas toute l’architecture.
Puis-je migrer un WordPress “classique” vers Docker ?
Oui. Il faudra :
- copier les fichiers WordPress dans le volume Docker,
- importer la base (dump SQL),
- adapter
wp-config.phpaux nouvelles variables d’environnement, - vérifier les URL et chemins éventuels.
Un test préalable en préproduction est fortement recommandé.
Est-ce utile d’utiliser Docker uniquement en dev ?
Absolument. Vous pouvez très bien développer en Docker (environnement reproductible) et déployer ensuite sur un serveur “classique” non conteneurisé. C’est déjà un énorme gain pour éviter les différences entre postes de développement.
Faut-il mettre Cloudflare devant un WordPress Dockerisé ?
Si le site est exposé sur Internet, oui, Cloudflare reste un très bon complément (CDN, WAF, cache, SSL). Docker ne change rien à ce niveau-là, c’est juste la façon dont vous organisez l’infrastructure côté serveur.
Conclusion : quand Docker est un bon choix pour WordPress
Dockeriser WordPress permet de gagner en cohérence, en portabilité et en automatisation, surtout si vous gérez plusieurs projets ou si vous travaillez en équipe. En séparant proprement le serveur web, PHP, la base de données et les services annexes (Redis, phpMyAdmin), vous construisez une stack moderne et maîtrisée.
Pour autant, Docker ne supprime pas les notions classiques de performance et de sécurité : vous devez toujours tuner PHP-FPM, optimiser MySQL/MariaDB, mettre en place Redis, Cloudflare, un monitoring et une stratégie de sauvegarde. Docker est un outil d’infrastructure, au service de la qualité globale de vos sites WordPress.
