Déployer WordPress avec Docker et Nginx représente en 2026 la méthode de référence pour les équipes de développement souhaitant des environnements reproductibles, isolés et faciles à migrer. L’approche conteneurisée élimine les traditionnels problèmes de divergence entre environnements de développement et de production, réduit les délais de provisionnement de nouveaux serveurs à quelques minutes, et facilite la mise en place de stratégies de mise à l’échelle horizontale. Ce tutoriel complet vous guide pas à pas, depuis la configuration initiale de Docker Compose jusqu’au déploiement d’un site WordPress pleinement fonctionnel servi par Nginx avec HTTPS et gestion des performances optimisée.
Architecture de la stack Docker WordPress + Nginx
La stack Docker pour WordPress est composée de trois services principaux orchestrés par Docker Compose : un conteneur Nginx servant de reverse proxy et de serveur web statique, un conteneur PHP-FPM exécutant WordPress, et un conteneur MySQL ou MariaDB pour la base de données. Cette architecture en couches sépare clairement les responsabilités : Nginx gère les connexions HTTP/HTTPS, la mise en cache des fichiers statiques et la terminaison SSL, tandis que PHP-FPM traite uniquement les requêtes PHP dynamiques. Cette séparation améliore les performances et la sécurité en réduisant la surface d’attaque de chaque composant.
L’ajout d’un conteneur phpMyAdmin optionnel facilite la gestion de la base de données lors du développement, mais ce conteneur ne doit jamais être exposé publiquement en production. Un volume Docker partagé entre les conteneurs Nginx et PHP-FPM contient les fichiers WordPress, permettant à Nginx de servir directement les fichiers statiques (CSS, JS, images) sans passer par PHP-FPM, ce qui améliore significativement les performances. Les volumes nommés Docker assurent la persistance des données de la base de données et des uploads WordPress entre les redémarrages ou mises à jour des conteneurs.
Le choix entre l’image Docker officielle WordPress et une image PHP-FPM de base avec WordPress installé manuellement impacte la maintenabilité. L’image officielle wordpress:php8.3-fpm intègre toutes les extensions PHP requises par WordPress (GD, imagick, intl, zip) et facilite les mises à jour de WordPress via le tableau de bord intégré. Une image personnalisée permet un contrôle plus fin des extensions et de la configuration PHP, mais nécessite une maintenance plus active. Pour la majorité des projets, l’image officielle avec des ajustements de configuration via des variables d’environnement ou un fichier php.ini monté en volume représente le meilleur compromis.
Configuration Docker Compose : le fichier de base
Le fichier docker-compose.yml définit l’intégralité de la stack en déclarant les services, les volumes et le réseau interne. Les variables sensibles comme les mots de passe de base de données sont externalisées dans un fichier .env non versionné, référencé depuis docker-compose.yml via la syntaxe ${VARIABLE}. Cette pratique évite de committer des credentials en clair dans Git, une exigence de sécurité fondamentale. Le fichier .env.example avec des valeurs factices est versionné à la place, servant de documentation des variables d’environnement requises pour les nouveaux développeurs rejoignant le projet.
La configuration des dépendances entre services via depends_on assure que le conteneur WordPress ne démarre qu’après le conteneur MySQL. Cependant, depends_on vérifie uniquement que le conteneur est démarré, pas qu’il est prêt à accepter des connexions. Un script wait-for-it.sh ou l’utilisation de la condition de santé healthcheck dans Docker Compose assure que MySQL est réellement opérationnel avant que WordPress tente de se connecter. Cette précaution évite des erreurs de connexion intermittentes lors du premier démarrage de la stack, particulièrement visible sur des machines lentes ou lors du pull initial des images Docker.
Les ressources allouées aux conteneurs doivent être configurées explicitement en production pour éviter qu’un conteneur consomme l’ensemble des ressources du serveur hôte. Les directives deploy.resources.limits dans Docker Compose permettent de définir des plafonds de CPU et de mémoire par conteneur. Un conteneur PHP-FPM WordPress bien configuré nécessite typiquement entre 256 MB et 512 MB de RAM selon le nombre de workers PHP-FPM actifs. Ces limites, combinées à des alertes de monitoring sur la consommation des ressources, permettent de détecter des fuites mémoire ou des pics d’activité anormaux avant qu’ils n’impactent la disponibilité du site.
Configuration Nginx pour WordPress
La configuration Nginx pour WordPress doit inclure plusieurs éléments spécifiques au CMS pour un fonctionnement correct. La directive try_files $uri $uri/ /index.php?$args est essentielle pour le routage des permaliens WordPress, permettant à Nginx de passer les requêtes vers URL non résolues à WordPress via PHP-FPM. La configuration du bloc location ~ .php$ avec fastcgi_pass vers le socket ou le port TCP de PHP-FPM assure le traitement des fichiers PHP. Les headers de sécurité (X-Frame-Options, X-Content-Type-Options, Content-Security-Policy) doivent être ajoutés au niveau de la configuration Nginx pour une protection en profondeur.
L’optimisation des performances Nginx pour WordPress passe par la mise en cache des fichiers statiques via les directives expires et cache-control. Les fichiers CSS, JavaScript, images et fonts peuvent être mis en cache côté navigateur pour de longues durées (30 jours à 1 an) en utilisant les directives expires max et add_header Cache-Control. La compression Gzip ou Brotli activée dans Nginx réduit la taille des transferts de 60 à 80% pour les ressources textuelles. Ces optimisations, combinées avec un CDN comme Cloudflare ou BunnyCDN en façade de Nginx, permettent d’atteindre des scores Lighthouse de 90+ pour des sites WordPress conteneurisés.
La configuration SSL/TLS dans Nginx peut utiliser Let’s Encrypt via Certbot ou des certificats gérés par Traefik si un reverse proxy supplémentaire est utilisé. Dans une stack Docker, Certbot peut être intégré comme conteneur séparé effectuant le renouvellement automatique des certificats et les montant dans un volume partagé avec Nginx. La configuration TLS 1.3 obligatoire, la désactivation des protocoles obsolètes (TLS 1.0, 1.1), et la configuration d’une suite de chiffrement forte suivant les recommandations de l’ANSSI complètent la sécurisation HTTPS. Le header HSTS avec une longue durée de validité renforce la protection contre les attaques de downgrade.
# docker-compose.yml - Stack WordPress + Nginx + MySQL
version: "3.9"
services:
nginx:
image: nginx:1.27-alpine
ports:
- "80:80"
- "443:443"
volumes:
- wordpress_data:/var/www/html:ro
- ./nginx/wordpress.conf:/etc/nginx/conf.d/default.conf:ro
- ./certs:/etc/ssl/certs:ro
depends_on:
- wordpress
restart: unless-stopped
wordpress:
image: wordpress:php8.3-fpm-alpine
environment:
WORDPRESS_DB_HOST: mysql
WORDPRESS_DB_NAME: ${DB_NAME}
WORDPRESS_DB_USER: ${DB_USER}
WORDPRESS_DB_PASSWORD: ${DB_PASS}
volumes:
- wordpress_data:/var/www/html
- ./php/uploads.ini:/usr/local/etc/php/conf.d/uploads.ini
depends_on:
mysql:
condition: service_healthy
restart: unless-stopped
mysql:
image: mysql:8.4
environment:
MYSQL_DATABASE: ${DB_NAME}
MYSQL_USER: ${DB_USER}
MYSQL_PASSWORD: ${DB_PASS}
MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASS}
volumes:
- mysql_data:/var/lib/mysql
healthcheck:
test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
interval: 10s
timeout: 5s
retries: 5
restart: unless-stopped
volumes:
wordpress_data:
mysql_data:Gestion des données persistantes et des sauvegardes
La persistance des données WordPress dans une stack Docker repose sur des volumes nommés Docker pour la base de données et les uploads. Le volume de base de données doit être sauvegardé régulièrement via un conteneur de backup exécutant mysqldump ou via un outil dédié comme Borgbackup. Les uploads WordPress, stockés dans wp-content/uploads, doivent être sauvegardés indépendamment via rsync ou une synchronisation vers un stockage objet S3-compatible. Une stratégie de rétention des sauvegardes (7 jours quotidiens, 4 semaines hebdomadaires, 12 mois mensuels) assure une protection contre les corruptions de données non détectées immédiatement.
La migration d’un site WordPress conteneurisé vers un autre hôte est simplifiée par la nature portable des conteneurs. Le processus consiste à exporter la base de données avec docker exec, copier le volume des uploads via tar ou rsync, et déployer le même docker-compose.yml sur le serveur destination. La commande wp search-replace exécutée via docker exec sur le nouveau serveur met à jour les URLs après migration. Cette portabilité est l’un des arguments principaux pour la conteneurisation WordPress en production : les migrations qui prenaient autrefois une journée entière peuvent être réalisées en moins d’une heure avec Docker.
Le monitoring d’une stack WordPress Docker nécessite l’exposition des métriques de chaque conteneur vers un système de surveillance. L’intégration du stack Prometheus + Grafana, conteneurisé également dans la même configuration Docker Compose de monitoring, permet de visualiser les métriques CPU, mémoire, et réseau de chaque service. Des métriques applicatives WordPress spécifiques peuvent être exposées via le plugin WordPress Prometheus Exporter. Des alertes sur des seuils critiques (mémoire > 80%, temps de réponse PHP > 500ms, taux d’erreur 5xx > 1%) permettent d’intervenir proactivement avant que les problèmes de performance n’impactent les utilisateurs finaux.
PHP-FPM : tuning des performances pour WordPress
La configuration PHP-FPM est déterminante pour les performances d’un site WordPress sous charge. Le paramètre pm (process manager) peut être configuré en mode dynamic, ondemand ou static selon le profil de trafic du site. Pour des sites à trafic variable, le mode dynamic avec pm.max_children = 20, pm.start_servers = 5, pm.min_spare_servers = 3 et pm.max_spare_servers = 8 offre un bon équilibre entre réactivité et consommation mémoire. Ces valeurs doivent être ajustées en fonction de la mémoire disponible sur le serveur hôte et du nombre de conteneurs WordPress cohabitant sur la même machine.
La configuration du cache OPcache de PHP améliore significativement les performances WordPress en mettant en cache le bytecode compilé des fichiers PHP. Les paramètres clés incluent opcache.memory_consumption=256 pour allouer 256 MB au cache, opcache.max_accelerated_files=10000 pour couvrir l’ensemble des fichiers WordPress et des plugins, et opcache.validate_timestamps=0 en production pour désactiver la vérification des timestamps qui consomme des I/O disque. Cette désactivation implique de vider le cache OPcache (via wp-cli ou un appel à opcache_reset()) lors de chaque déploiement de code pour que les modifications soient prises en compte.
La gestion des sessions PHP dans un environnement multi-conteneurs WordPress nécessite une attention particulière. Si plusieurs instances PHP-FPM sont utilisées derrière un load balancer, le stockage des sessions par défaut dans des fichiers locaux crée des problèmes de sticky session ou de perte de session. La configuration de Redis comme backend de session PHP via session.save_handler = redis et session.save_path = tcp://redis:6379 centralise les sessions et permet une scalabilité horizontale transparente. Redis sert également de backend pour le cache objet WordPress via le plugin Redis Object Cache, offrant des performances nettement supérieures au cache sur fichiers.
Environnement de développement vs production
La distinction entre configurations de développement et de production dans une stack Docker WordPress se gère via des fichiers Docker Compose distincts : docker-compose.yml pour la base, docker-compose.override.yml pour le développement (automatiquement mergé par Docker Compose), et docker-compose.prod.yml pour la production (appliqué explicitement). Le fichier override de développement active Xdebug pour le débogage PHP, monte le code source local en volume pour le rechargement à chaud, expose des ports supplémentaires pour phpMyAdmin, et désactive certaines optimisations de cache pour faciliter le développement. La production désactive Xdebug, active OPcache au maximum, et configure les healthchecks.
Le workflow de développement local avec Docker WordPress peut être enrichi par des outils comme Lando, DDEV ou DevContainers (VS Code) qui abstraient la complexité de la configuration Docker tout en offrant les bénéfices de la conteneurisation. Ces outils préconfigurés pour WordPress gèrent automatiquement la configuration Nginx, PHP-FPM, MySQL, Mailhog (pour capturer les emails en développement) et WP-CLI. Pour les équipes, l’utilisation d’un de ces outils standardise l’environnement de développement sans que chaque développeur ait à maîtriser Docker en profondeur, réduisant le temps de mise en place d’un nouvel environnement de développement à moins de 10 minutes.
Les tests automatisés d’une application WordPress conteneurisée peuvent utiliser la stack Docker comme environnement d’exécution des tests, garantissant la cohérence entre l’environnement de test et de production. PHPUnit pour les tests unitaires de plugins, Playwright ou Cypress pour les tests end-to-end, et WP-CLI pour les tests d’intégration peuvent tous être exécutés dans des conteneurs Docker éphémères créés et détruits pour chaque cycle de test. Cette approche, intégrable dans des pipelines GitHub Actions ou GitLab CI utilisant des services Docker, garantit des tests reproductibles et indépendants de l’environnement d’exécution du CI.
Sécurité de la stack Docker WordPress
La sécurisation d’une stack Docker WordPress nécessite plusieurs couches de protection. Les conteneurs doivent s’exécuter avec un utilisateur non-root, configuré via la directive user dans Docker Compose. Les systèmes de fichiers des conteneurs peuvent être montés en lecture seule (read_only: true) à l’exception des volumes explicitement définis pour l’écriture, limitant l’impact d’une compromission applicative. Les capabilities Linux accordées aux conteneurs doivent être réduites au minimum nécessaire via cap_drop: all et cap_add uniquement pour les capabilities requises. Ces précautions réduisent la surface d’attaque en cas d’exploitation d’une vulnérabilité dans WordPress ou ses plugins.
La mise à jour régulière des images Docker est un aspect critique de la sécurité souvent négligé. Même avec WordPress mis à jour via son tableau de bord, les images de base PHP-FPM et Nginx peuvent contenir des vulnérabilités dans l’OS sous-jacent (Alpine Linux ou Debian) ou dans les bibliothèques système. Des outils comme Trivy, Snyk Container ou Docker Scout permettent de scanner les images Docker à la recherche de CVE connues, intégrables dans les pipelines CI/CD pour bloquer le déploiement d’images contenant des vulnérabilités critiques. Un cycle de rebuild des images au moins mensuel, même en l’absence de changements applicatifs, assure une base OS à jour.
Le réseau Docker doit être configuré pour limiter les communications entre conteneurs au strict nécessaire. Dans Docker Compose, la création de réseaux distincts (frontend pour Nginx-PHP, backend pour PHP-MySQL) isole les communications : Nginx ne peut pas accéder directement à MySQL, et MySQL n’est accessible que depuis PHP-FPM. L’exposition des ports de base de données sur l’interface publique du serveur hôte est une erreur de configuration courante et dangereuse à éviter absolument. Les scans réguliers avec nmap depuis l’extérieur permettent de vérifier qu’aucun port non intentionnel n’est accessible publiquement, constituant une vérification de sécurité simple mais efficace.
Déploiement en production et CI/CD
Le déploiement automatisé d’une stack WordPress Docker en production via un pipeline CI/CD représente la pratique professionnelle en 2026. Un workflow GitHub Actions ou GitLab CI typique construit la nouvelle image Docker lors d’un push sur la branche main, la pousse vers un registry privé (GitHub Container Registry, GitLab Registry, ou AWS ECR), puis déclenche un déploiement sur le serveur de production via SSH ou via un outil d’orchestration. Les stratégies de déploiement Blue/Green ou Canary, où une nouvelle version est déployée parallèlement à l’ancienne avec basculement progressif du trafic, minimisent les risques d’indisponibilité lors des mises en production.
La gestion des secrets en production pour une stack Docker WordPress utilise les Docker Secrets en mode Swarm, ou des solutions externes comme HashiCorp Vault ou AWS Secrets Manager, injectés comme variables d’environnement via le pipeline CI/CD. La rotation régulière des mots de passe de base de données et des clés secrètes WordPress (définies dans wp-config.php) peut être automatisée via des scripts qui mettent à jour les secrets dans le gestionnaire de secrets et redémarrent les conteneurs affectés. Cette automatisation élimine les risques liés aux credentials statiques non rotés et facilite la réponse aux incidents de sécurité.
Le monitoring en production d’une stack WordPress Docker doit couvrir plusieurs niveaux : infrastructure (CPU, RAM, disque, réseau), conteneurs (statut, redémarrages, utilisation ressources), et application (temps de réponse HTTP, taux d’erreur, métriques WordPress). Des outils comme Netdata, Prometheus avec node_exporter, ou les agents de monitoring des hébergeurs cloud (Datadog, New Relic) peuvent être déployés comme conteneurs additionnels dans la même stack. Les alertes PagerDuty ou OpsGenie pour les incidents critiques en dehors des heures de bureau complètent la stratégie de monitoring pour garantir la disponibilité 24/7 des sites WordPress en production.
Commentaires (0)
Laisser un commentaire
Les commentaires sont modérés. Questions WordPress, cybersécurité ou dev web bienvenues.