Le déploiement de WordPress a longtemps rimé avec transferts FTP laborieux et configurations manuelles hésitantes, surtout dès qu’on devait jongler entre plusieurs projets ou jongler avec des environnements test/prod. Docker Compose redistribue sérieusement les cartes : désormais, tout passe par un seul fichier décrivant l’orchestration de vos conteneurs, autorisant une automatisation solide, reproductible et sans prise de tête. Cette organisation permet d’aligner développement et production, de régler définitivement la question des conflits de versions et d’offrir à chaque projet un environnement isolé propre, du serveur web à la base de données MySQL, jusqu’à l’administration via PhpMyAdmin.
La configuration en conteneurs n’est plus réservée aux puristes ou aux devops aguerris. Même pour des petits studios ou freelances ayant passé des années à bricoler WordPress sur mutualisé classique, la bascule vers Docker Compose représente un bond en efficacité. En expliquant pas à pas la création d’un environnement local WordPress sous Docker Compose, de la structure des fichiers à l’automatisation du déploiement complet serveur web + PHP-FPM + base MySQL + PhpMyAdmin, ce guide vise un public de développeurs pragmatiques souhaitant fiabiliser leur workflow et assurer une migration progressive de leurs habitudes. L’occasion aussi de partager quelques astuces acquises à force de voir des installations WordPress vieillissantes mal migrées ou des environnement locaux mal isolés qui finissent par polluer tous les projets du développeur.
- Déploiement automatisé et reproductible grâce à Docker Compose
- Environnement isolé pour WordPress (Nginx, PHP-FPM, MySQL, PhpMyAdmin)
- Suppression des conflits de versions lors du développement multi-projets
- Commandes Docker Compose pour build, mise à jour et maintenance
- Gestion centralisée de la configuration (volumes, variables d’environnement, accès sécurité)
Environnement WordPress sous Docker Compose : prérequis et structure à ne pas négliger
La première erreur classique consiste à improviser la structure de son environnement : on se retrouve vite à mélanger des fichiers WordPress, des bouts de scripts shell et des configurations dans tous les coins. Pour éviter une pagaille difficile à maintenir, le déploiement propre démarre dès la création du dossier principal — ici, nommé wordpress — qui englobe la totalité des éléments nécessaires.
Un projet Docker Compose solide se construit autour d’un fichier docker-compose.yml, à la racine, qui orchestre tous les services (serveur web, PHP, base MySQL, éventuellement PhpMyAdmin). Ce fichier fait office de centre névralgique et définit la topologie du projet.
Côté fichiers, le minimum pour rester propre inclut :
- un dossier docker/nginx pour customiser la config de Nginx (images, config serveur, logs),
- un dossier docker/php pour le Dockerfile PHP personnalisable (notamment pour installer des extensions comme mysqli),
- un dossier project regroupant le code WordPress,
- un dossier database pour la persistance MySQL (volume mappé),
- éventuellement un fichier .env dédié aux credentials et paramètres sensibles du projet,
- des sous-dossiers themes et plugins pour séparer les développements maison.
Se contenter du strict minimum ne pardonne plus en 2026 : une structure floue handicape la maintenance future, freine la rotation des projets et multiplie les boucles de corrections en cas d’incident (permissions de fichiers, changement de version PHP, house-keeping MySQL, etc.).
| Système | Prérequis spécifiques | Outil recommandé |
|---|---|---|
| Windows | WSL 2 ou Git Bash | Docker Desktop |
| macOS | Homebrew (optionnel) | Docker Desktop |
| Linux | Docker Engine + Docker Compose | Installation native |
Installer Docker Desktop sur sa machine (Windows/macOS) ou Docker Engine sur Linux reste obligatoire. Sur Windows, se souvenir que WSL 2 garantit un environnement Linux complet. Détail qui sauve des heures de prise de tête : toujours privilégier le terminal pour tout ce qui touche au build, au redémarrage de conteneurs ou à la surveillance des logs (docker-compose logs, docker-compose up -d, docker-compose down). Rien ne remplace une vue complète sur ce qui se passe pendant le déploiement.
Déploiement step-by-step : création du docker-compose.yml et premiers tests
L’étape charnière, c’est la rédaction du docker-compose.yml. C’est ici que tout se joue : un service nommé « web » pour Nginx, un autre pour PHP-FPM, un troisième pour la base “bdd” et enfin PhpMyAdmin en option. La logique est limpide : chaque composant dans son conteneur, chacun isolé des autres, mais reliés par une petite architecture réseau interne gérée par Docker. Finies les bidouilles hasardeuses qui polluent le système hôte.
Exemple de démarrage : Nginx exposé sur le port 8002 (pour ne pas se disputer le port 80 du système), image officielle téléchargée depuis Docker Hub. Une ligne de commande simple — docker-compose build && docker-compose up -d — suffit à construire et lancer le stack en arrière-plan. L’adresse http://localhost:8002 offre une première validation de la config réseau.
Configuration personnalisée du serveur web (Nginx)
Un serveur générique Nginx n’a que peu d’intérêt pour WordPress. Dès lors, le premier réflexe : créer un docker/nginx/Dockerfile pour intégrer un fichier de config avancé (default.conf). Plusieurs erreurs récurrentes croisées récemment chez des agences : oublier de définir le root (/var/www/html/), négliger la liste des index (toujours placer index.php avant index.html sinon les pages restent blanches sur WordPress), négliger la gestion fine des locations PHP (provoquant des erreurs 502 sur le back-office WordPress).
En attachant le dossier project comme volume à Nginx et PHP-FPM, on fluidifie l’intégration des fichiers projet. Le montage de volumes permet aussi d’éditer tranquillement en local, avec rafraîchissement immédiat dans le conteneur. Le web devient ainsi un miroir fidèle de vos sources.
Premiers retours terrain
Sur un site client en 2025, cette approche a évité un désastre lors d’un changement de thème. L’équipe avait tout hasardé à la main sur un environnement mutualisé, résultat : conflit de versions PHP, index.php ignoré par Nginx, perte d’une journée juste pour la phase d’intégration. Avec Compose, le switch du conteneur PHP ou la reprise des volumes n’a pris que 3 minutes montre en main. C’est le genre de détail qui fait préférer ce workflow à n’importe quelle stack bricolée.
Ajout de PHP-FPM et configuration fine pour WordPress
Installer PHP-FPM comme service séparé demeure une étape obligatoire pour WordPress. Pas de raccourci possible : il faut que Nginx passe la main à PHP via le fastcgi_pass. Ici, le mapping des volumes permet au code WordPress d’être accessible de part et d’autre, garantissant que chaque modification (fichier de thème, plugin) soit aussitôt prise en compte côté front, sans manipulation de droits hasardeuse.
Pensez à ajouter ou modifier le default.conf pour prendre en charge l’exécution des scripts PHP. L’omission du fastcgi_param SCRIPT_FILENAME reste une source d’erreur vue et revue, provoquant des “No input file specified” dans le navigateur. Pour vérifier que tout roule, un petit index.php hébergeant un phpinfo() donne immédiatement la version de PHP exposée par le conteneur. Inversement, si rien ne s’affiche ou si le navigateur renvoie à la racine du site, c’est souvent que le serveur web ne pointe pas au bon niveau ou ne reconnaît pas encore correctement .php dans ses locations.
Problèmes classiques et astuces de contournement
Les permissions de fichiers s’avèrent souvent le talon d’Achille d’une stack locale. Sur un poste Linux, songer à synchroniser les UID/GID du conteneur PHP avec ceux du système hôte (user : “$(id -u):$(id -g)” dans docker-compose.yml). Cette précaution évite la génération de fichiers root ou l’impossibilité d’écrire dans wp-content lors d’une installation de plugin.
Autre astuce héritée d’un projet associatif : lors d’un passage à PHP 8.1, les extensions mysqli ne s’installaient pas proprement sans un Dockerfile adapté. Il vaut mieux documenter la customisation du service PHP avec un Dockerfile sur-mesure que de perdre du temps à bidouiller les images existantes à chaque micro-changement de version.
Commandes de base pour manœuvrer l’ensemble
- docker-compose up -d : démarre tout le stack
- docker-compose down : arrête et nettoie tous les conteneurs du projet
- docker-compose logs : affiche les logs de tous les services pour déboguer
Un bon réflexe à prendre pour prévenir les effets de “bouteille à la mer” en phase d’installation ou de changement de conteneur.
Intégrer base de données MySQL et PhpMyAdmin dans Docker Compose : fiabilité et simplicité
Impossible d’ignorer la question de la base de données pour un WordPress déployé correctement. Ici, l’approche Docker Compose apporte un atout clé : chaque instance MySQL est isolée, chaque donnée persistée dans des volumes Docker qui supportent les arrêts/redémarrages sans perte. Plus besoin de manipuler des dumps ou de craindre la corruption de la base lors d’un crash du système hôte.
L’ajout d’un service PhpMyAdmin dans la configuration complète instantanément l’environnement. L’accès se fait depuis http://localhost:8802, avec les identifiants renseignés dans docker-compose.yml. Ce GUI évite de passer par la ligne de commande pour chaque opération basique (création de base, import/export de tables, gestion rapide des utilisateurs).
Cas concret : une PME du B2B avait pour habitude de placer toutes les bases de leurs sites mutualisés sur la même instance MySQL partagée. Avec la recette Docker, chaque site WordPress repose sur sa base isolée, coupe court à tout risque d’effet domino lors d’une mise à jour hasardeuse ou d’une migration mal rodée.
Exemple de configuration pour les services MySQL et PhpMyAdmin
Dans le fichier docker-compose.yml :
- base “bdd” exposée sur le port 3302, root/password personnalisés pour chaque projet,
- volume nommé “db” pour préserver les données indépendamment du cycle de vie des conteneurs,
- PhpMyAdmin connecté à la base via le hostname défini dans Compose, évitant toute configuration manuelle côté réseau.
Ce découpage s’avère décisif lors des phases de backup : un simple export du volume “db” permet de migrer ou restaurer une base en cas d’incident, sans toucher au reste des sources WordPress.
Écueils courants et optimisations supplémentaires
Attention à la synchronisation des utilisateurs MySQL : il peut arriver qu’une restauration de dump écrase des droits ou déclenche un souci de charset. Prévoir une gestion des credentials centralisée via un fichier .env, à ignorer dans le versioning Git pour éviter toute fuite accidentelle.
L’expérience montre qu’un environnement local maintenable suppose aussi de bien documenter les ports utilisés, et de s’assurer qu’aucun autre service (ex, une vieille installation XAMPP ou MAMP) ne vient empiéter sur les mêmes ports système.
Installer et configurer WordPress sur un stack containerisé : astuces, retours d’expérience et automatisation
Une fois le socle Docker Compose en place, l’installation de WordPress se réduit à copier les sources dans le dossier “project”. Les bons réflexes consistent à renommer wp-config-sample.php en wp-config.php et à appliquer immédiatement la configuration de la base de données, selon les coordonnées fournies dans le Compose : DB_NAME, DB_USER, DB_PASSWORD, DB_HOST (penser à renseigner localhost:3302 si besoin).
La subtilité vient souvent de PHP : WordPress exige l’extension mysqli pour dialoguer avec MySQL. D’où l’intérêt du Dockerfile PHP distinct, incluant les commandes nécessaires. Dès qu’on commence à jouer sur plusieurs versions de PHP ou à basculer de la 7.4 à la 8.1, autant anticiper le problème et ajouter une étape RUN docker-php-ext-install mysqli. C’est le genre de détail qui passe inaperçu quand tout roule mais qui bloque une équipe de dev le matin où la version par défaut de l’image PHP change soudainement.
Synchroniser développement et production grâce à Compose
Un point souvent négligé par les agences travaillant avec plusieurs clients : la portabilité pure apportée par Compose permet de répliquer à l’identique, du local vers la prod, sans la moindre différence d’environnement (versions PHP, port MySQL, droits). Tout le contraire des déploiements rushés vus par le passé, où le dernier qui touche au FTP a carte blanche pour casser la prod en poussant une config PHP ou une extension WordPress non compatible.
- Centralisation des variables d’environnement : placez tout ce qui est sensible (mot de passe, clés WordPress) dans un .env bien ficelé
- Gestion des extensions et thèmes personnalisés : préférez un dossier monté depuis le système hôte pour éditer sans relancer Compose
- Mise à jour des images : docker-compose pull pour rester à jour, docker-compose build pour recompiler si besoin après ajout d’une extension PHP
Bonus : exploitation de WP-CLI et intégration avec Visual Studio Code
L’interface WP-CLI percole petit à petit même dans les équipes historiquement orientées GUI. Depuis le terminal, installer, activer un plugin ou créer un utilisateur WordPress devient quasi instantané (docker-compose exec wordpress wp plugin install XXX). Pour ceux qui travaillent sous VS Code, l’extension Docker connecte tout l’écosystème dans l’éditeur : logs, terminal, monitoring.
En résumé, la configuration de WordPress sous Docker Compose pose un socle fiable, reproductible, et supprime une bonne partie des risques attachés à la multiplicité des environnements ou des erreurs de configuration “manuelles”. Ce n’est pas une question de tendance ou d’effet de mode : sur le terrain, ce choix apporte de la sérénité, un vrai gain de temps et moins de sueur froide à chaque bascule prod.
Quels sont les principaux avantages de déployer WordPress avec Docker Compose ?
Avec Docker Compose, chaque composant du stack WordPress (serveur web, PHP, base de données) est isolé dans son propre conteneur. L’environnement de développement devient entièrement reproductible, sans conflits de version ni risque de polluer la machine hôte. L’automatisation via un seul fichier de configuration permet d’accélérer installations, mises à jour et maintenance, tout en facilitant la cohérence entre local et production.
Comment gérer les données persistantes de MySQL dans un environnement Dockerisé ?
La persistance des données passe par la déclaration d’un volume Docker dédié (ex : db : /var/lib/mysql), indépendant du cycle de vie des conteneurs. Ainsi, en cas de redémarrage, d’arrêt ou de suppression de la stack, la base reste intacte. Cela facilite aussi les sauvegardes et les migrations d’environnement.
Faut-il privilégier Nginx ou Apache comme serveur web dans un stack WordPress sous Docker Compose ?
Nginx est souvent privilégié pour ses performances en reverse-proxy et sa faible consommation, mais Apache reste tout à fait fiable, surtout si le projet repose sur des .htaccess personnalisés. Dans tous les cas, Compose permet d’alterner voire de tester les deux approches rapidement selon la typologie du site et des extensions utilisées.
Comment éviter les problèmes de permissions de fichiers entre conteneurs et système hôte ?
Sous Linux et macOS, il est conseillé de paramétrer l’utilisateur du conteneur PHP pour qu’il corresponde à celui du système hôte, à l’aide de la variable user dans le docker-compose.yml. Cela prévient les erreurs lors de l’installation de thèmes ou plugins WordPress, en maintenant une compatibilité totale au niveau des droits sur les fichiers.
PhpMyAdmin est-il recommandé ou faut-il privilégier WP-CLI pour gérer la base de données WordPress sous Docker Compose ?
PhpMyAdmin reste utile pour la visualisation et la gestion rapide des tables, notamment pour les utilisateurs moins familiers avec la ligne de commande. WP-CLI propose des possibilités avancées de gestion WordPress, mais il n’offre pas la même visibilité graphique côté base. Selon les cas, l’usage des deux outils en complément offre le meilleur compromis.
