WordPress, Docker et Docker Compose s’invitent désormais dans le quotidien des petites agences, freelances et TPE. Entre un site en local à monter vite fait pour un client pressé et un déploiement en production sur un petit VPS, le fossé reste souvent énorme. C’est justement ce fossé que la virtualisation par conteneur aide à réduire : même stack, même configuration, du portable de développement jusqu’au serveur en ligne. Concrètement, un projet WordPress devient un dossier avec un fichier docker-compose.yml, quelques volumes et des variables d’environnement bien pensées, que l’on peut lancer en quelques commandes.
Pour un commerce de centre-ville, un camping ou un cabinet libéral, la promesse est simple : moins de temps perdu sur la technique, plus de maîtrise sur l’infrastructure. En local, un environnement propre permet de tester des thèmes, des plugins, une refonte complète sans toucher au site web en ligne. En production, Docker apporte de la portabilité, un déploiement plus prévisible et une meilleure isolation entre services. Reste à construire une architecture WordPress cohérente et à ne pas oublier les fondamentaux : sauvegardes, sécurité, performance, coûts réels sur un petit serveur. C’est là que le trio WordPress + Docker + Docker Compose devient vraiment intéressant quand il est abordé avec une logique terrain, et pas comme un simple gadget de développeur.
En bref
- Objectif : utiliser Docker et Docker Compose pour déployer un site web WordPress en local puis en production sans multiplier les surprises entre les environnements.
- Architecture : séparer les rôles dans des conteneurs dédiés (PHP-FPM, Nginx ou Apache, MariaDB/MySQL, éventuellement Redis et phpMyAdmin) avec des volumes persistants.
- Développement local : cloner un template Docker Compose WordPress, adapter le fichier .env, lancer quelques commandes et disposer d’un environnement complet en quelques minutes.
- Production : reprendre la même base, renforcer la configuration, ajouter un reverse proxy, SSL, monitoring et une stratégie de sauvegarde sérieuse.
- Limites : Docker ne corrige pas un code mal optimisé ni une absence de sauvegardes, il apporte surtout cohérence, portabilité et automatisation si la configuration est maîtrisée.
Pourquoi dockeriser WordPress avec Docker Compose pour le local et la production
Pour comprendre l’intérêt réel de Docker autour de WordPress, autant partir d’un cas concret. Imagine un artisan de Périgueux qui veut moderniser son site web vitrine. Une petite agence prend le projet, installe WordPress en local sur XAMPP, teste des plugins, puis livre le site sur un hébergement mutualisé. Résultat classique : en local tout va bien, en production les versions de PHP diffèrent, certaines extensions plantent, et les échanges avec le support de l’hébergeur tournent vite en rond.
Avec Docker Compose, ce scénario change complètement. Le même stack s’exécute en local et sur le serveur : même image WordPress, même version de PHP, même image MariaDB, même configuration Nginx ou Apache. Le fameux « ça marche sur ma machine » devient beaucoup plus rare, parce que la machine n’est plus vraiment la question, c’est le conteneur qui fait foi.
Reproductibilité et portabilité du site web WordPress
WordPress repose sur un noyau PHP, une base MySQL ou MariaDB, quelques extensions, un thème, le tout saupoudré de réglages serveur. Sur un poste, on a PHP 8.1, sur un autre 8.2, en prod 7.4 encore en circulation, et chaque différence de version peut faire surgir un bug subtil. En conteneurisant WordPress, l’ensemble de la pile logicielle est décrit dans des fichiers plutôt que laissée au hasard des installations.
Un simple fichier docker-compose.yml peut décrire les versions exactes des images, les ports exposés, les volumes de données, les variables d’environnement. Tu peux ensuite déplacer ce projet d’un PC sous Windows à un Mac ou une machine Linux, voire à un VPS, sans tout réinstaller à la main. Pour une agence qui gère dix à vingt petits sites WordPress, cette portabilité change la donne : un nouveau développeur récupère le dépôt Git, lance Docker Compose, et retrouve le site tel qu’il a été prévu.
Isolation des services et simplification du multi‑projets
Autre avantage fort : l’isolation. Chaque projet WordPress vit dans son propre micro-écosystème composé de ses conteneurs. Plus besoin de jongler avec plusieurs versions PHP sur le même serveur ou de craindre qu’une mise à jour système casse l’ensemble des sites hébergés. Pour une TPE qui héberge quelques sites sur un unique serveur, cette séparation nette évite bien des sueurs froides.
Un projet peut avoir besoin d’un vieux plugin qui ne supporte pas PHP 8.3, un autre vient d’un thème récent qui réclame cette version. Plutôt que de choisir entre casser un site ou bloquer l’autre, Docker permet d’exécuter les deux environnements côte à côte. Certains hébergeurs gèrent déjà ces cas via des images pré-packagées, mais en Docker, l’agence garde le contrôle complet et peut ajuster les conteneurs à la réalité de chaque client.
Automatisation, CI/CD et travail en équipe
Sur les projets un peu plus structurés, la containerisation ouvre la porte à des pipelines d’intégration continue. Un dépôt Git, un Docker Compose et un script de déploiement suffisent pour automatiser les mises à jour : à chaque merge sur une branche de production, le serveur reconstruit les conteneurs, applique les migrations nécessaires, puis redémarre la stack WordPress. Même sur un petit parc de sites, le gain en fiabilité est visible.
En équipe, plus besoin d’envoyer des tutos longs comme le bras pour installer PHP, MySQL, Node et compagnie. Les développeurs récupèrent la configuration existante, la lancent, et se concentrent sur le code ou l’intégration. Pour un webdesigner ou un intégrateur qui ne veut pas passer sa vie à réparer son environnement local, c’est assez confortable. L’idée-clé de cette première partie reste simple : Docker ne sert pas à faire « joli » mais à rendre WordPress prévisible, du local à la production.
Architecture WordPress sous Docker Compose : conteneurs, services et bonnes pratiques
Une fois convaincu par l’idée, reste la question qui fâche parfois : comment structurer une architecture WordPress en conteneurs sans transformer un simple site vitrine en usine à gaz. En pratique, un schéma sobre suffit pour la majorité des cas : un service PHP-FPM avec WordPress, un serveur web Nginx ou Apache, une base MariaDB ou MySQL, parfois un Redis, plus un outil type phpMyAdmin pour les interventions ponctuelles.
Le piège classique consiste à tout entasser dans un seul conteneur « WordPress complet ». C’est confortable au début, mais très vite, les mises à jour ou le debug deviennent pénibles. Séparer les rôles permet de faire évoluer chaque brique indépendamment et de mieux diagnostiquer les problèmes quand ils surviennent.
Une architecture Docker Compose type pour WordPress
Dans une configuration courante, on retrouve trois services principaux définis dans docker-compose.yml. D’abord, la base de données : un conteneur issu d’une image MariaDB ou MySQL, avec ses variables d’environnement (nom de base, utilisateur, mot de passe) et un volume pour persister les données. Ensuite, le service WordPress basé sur une image officielle en PHP-FPM, connecté à cette base via le réseau Docker interne. Enfin, un Nginx qui reçoit les requêtes HTTP/HTTPS et les transmet au PHP-FPM.
Voici un schéma de répartition qui résume les rôles, utile pour ne pas se perdre :
| Service | Rôle principal | Données à persister | Points de vigilance |
|---|---|---|---|
| PHP-FPM + WordPress | Exécuter le code PHP du CMS et des plugins | wp-content (thèmes, plugins, uploads) | Limiter les droits d’écriture, éviter le root dans le conteneur |
| Nginx / Apache | Servir les pages et les assets statiques | Aucune donnée critique, configuration montée en volume | Gérer les headers, le cache navigateur, les redirects |
| MariaDB / MySQL | Stocker les contenus, comptes, réglages | Dossier /var/lib/mysql monté sur un volume | Plan de sauvegarde régulier, tuning de base pour la performance |
Cette séparation rend la stack plus lisible. Un incident sur la base n’oblige pas à reconstruire Nginx, une mise à jour WordPress ne nécessite pas de toucher au serveur HTTP. Même sur un simple VPS, cette clarté structurelle se ressent au fil des mois.
Reverse proxy, multi-sites et mutualisation
Dès que plusieurs sites sont hébergés sur la même machine, la question du routage arrive. Plutôt que d’exposer chaque conteneur WordPress sur un port différent, de nombreuses équipes choisissent de placer un reverse proxy en frontal, souvent Nginx ou Traefik. Ce service unique écoute sur les ports 80 et 443, reçoit toutes les requêtes, puis les redirige vers le bon conteneur en fonction du nom de domaine.
Deux approches reviennent souvent. La première consiste à créer un stack Docker Compose par site WordPress, avec son propre fichier docker-compose.yml et sa base dédiée. L’isolation est maximale, chaque projet peut être démarré ou arrêté sans toucher aux autres. La seconde approche regroupe plusieurs services WordPress dans un même fichier Compose, avec un reverse proxy intégré et des réseaux Docker internes bien cloisonnés. Ce choix dépend surtout de la taille de l’équipe et du nombre de sites à maintenir. Une chose est sûre : pour un parc de sites conséquent, un reverse proxy proprement configuré devient vite un allié indispensable.
Volumes, permissions et sécurité de base
Une architecture Docker propre ne se limite pas à l’organisation des conteneurs, elle se joue aussi beaucoup sur les volumes. Tout ce qui doit survivre à la recréation d’un conteneur doit vivre dans un volume : la base de données, les fichiers WordPress personnalisés, certains fichiers de configuration. En pratique, beaucoup d’agences persistent au minimum le dossier wp-content et le dossier de données MySQL, le reste pouvant être reconstruit depuis les images officielles.
Sur la sécurité, Docker ne dispense pas des fondamentaux. Il reste nécessaire de limiter les droits d’écriture au strict nécessaire, d’éviter les comptes root exposés, de fermer les ports inutiles et de surveiller les logs d’accès. Une stack WordPress bien dockerisée, c’est surtout une stack où l’on sait exactement où se trouvent les données sensibles et comment les mettre à l’abri. Cette vision architecturale pose la base avant de parler d’installation concrète en local.
Mettre en place un environnement WordPress Docker Compose en local pas à pas
Passons au concret. En local, l’objectif reste assez simple : démarrer un site WordPress fonctionnel avec Docker Compose en quelques commandes, sur Windows, macOS ou Linux. Pour un freelance ou une petite agence, le gain se mesure en heures économisées à chaque nouveau projet. Il existe plusieurs templates prêts à l’emploi qui combinent WordPress, MariaDB, phpMyAdmin, WP-CLI et un Makefile pour simplifier la vie.
Une structure typique issue d’un dépôt Git propose un répertoire mysql pour la base, un dossier wordpress pour les fichiers du CMS, un dossier wpcli avec un Dockerfile pour l’interface en ligne de commande, un docker-compose.yml et un fichier .env pour les variables d’environnement. Quelques ajustements suffisent pour adapter ce kit à n’importe quel nouveau projet client.
Télécharger un modèle Docker Compose pour WordPress
La première étape consiste à cloner un dépôt de référence contenant un exemple de configuration. Une fois le projet récupéré, on se retrouve avec une arborescence du type :
files/wordpress-docker-compose
LICENSE, Makefile, README, dossier config pour les réglages PHP, docker-compose.yml, wp-auto-config.yml pour l’automatisation, dossiers mysql et wordpress pour les données, répertoire wpcli pour WP-CLI. Chaque élément a un rôle précis, ce qui évite de deviner où brancher la configuration.
Un simple passage en revue des fichiers permet de comprendre comment la stack est câblée. Le docker-compose.yml définit les services, le .env centralise les variables d’environnement, le Makefile rassemble des commandes utiles comme install, start, down ou reset. Cette approche convient bien à des profils qui n’ont pas envie de taper de longues lignes Docker à chaque fois.
Configurer le fichier .env avant le premier lancement
Avant de lancer quoi que ce soit, il vaut mieux adapter les valeurs du fichier .env. On y trouve généralement plusieurs sections. D’abord, le nom de projet utilisé par Docker Compose, souvent en minuscules sans espaces. Ce nom sert parfois de préfixe aux conteneurs et au réseau interne, et peut même être réutilisé comme nom de base de données WordPress.
Viennent ensuite les identifiants pour la base de données (utilisateur et mot de passe), puis les paramètres destinés à l’auto-configuration du site : titre du site, URL, structure des permaliens, identifiants administrateur (nom d’utilisateur, mot de passe, e-mail). On trouve aussi les versions de WordPress et de MariaDB à utiliser, le port d’exposition de phpMyAdmin et les chemins locaux des volumes. Une fois ces réglages alignés avec le besoin du projet, le terrain est prêt.
Installation automatique ou manuelle en local
Deux stratégies cohabitent pour installer WordPress dans ce contexte. La première, assez pédagogique, mélange installation automatique et configuration manuelle via l’interface. On commence par construire les images et démarrer les services avec :
docker-compose build
docker-compose up -d
docker-compose run –rm healthcheck
La commande healthcheck vérifie que la base de données et le service WordPress répondent correctement. Un alias make install permet de regrouper ces étapes sur macOS et Linux. Une fois les conteneurs démarrés, il suffit de se rendre sur http://localhost, choisir la langue, créer le compte admin, et le tour est joué.
La seconde méthode pousse l’automatisation plus loin en utilisant WP-CLI. On lance d’abord les conteneurs, puis un service supplémentaire applique une configuration automatique en se basant sur les variables définies dans .env :
docker-compose up -d –build
docker-compose -f docker-compose.yml -f wp-auto-config.yml run –rm wp-auto-config
Cette approche est redoutable en termes de rapidité : en quelques minutes, un site WordPress complet, avec compte admin et permaliens configurés, est prêt à être testé. Sur un parc de nombreux sites locaux, l’économie de temps est nette.
Commandes utiles pour la vie quotidienne en local
Une fois l’environnement en place, quelques commandes reviennent souvent. Pour arrêter et supprimer les conteneurs, un simple docker-compose down suffit, sans effacer les données persistantes stockées dans mysql et wordpress. Pour redémarrer, docker-compose up -d relance les mêmes services en arrière-plan. En cas de besoin de réinitialisation totale, on combine docker-compose down avec la suppression des dossiers mysql/* et wordpress/*, ce qui efface la base et les fichiers du site.
Les adeptes de Make peuvent aller plus vite avec des raccourcis comme make start, make down ou make reset. L’accès à WordPress se fait via http://localhost et le back-office via /wp-login.php avec les identifiants définis dans .env. La base de données reste accessible via phpMyAdmin sur http://localhost:8080 avec un compte root et son mot de passe. Cette boîte à outils couvre l’essentiel des besoins pour expérimenter sereinement en local avant de penser au déploiement en production.
Déployer WordPress Dockerisé en production : adaptation, sécurité, sauvegardes
Une fois le projet stabilisé en local, vient le moment délicat du déploiement. Passer un WordPress Docker Compose sur un serveur en production ne consiste pas à copier-coller le setup local. Il faut l’adapter à la réalité du serveur, renforcer la sécurité, ajouter un certificat SSL, penser au monitoring et surtout verrouiller les sauvegardes. Heureusement, la structure de base reste la même, ce qui limite les surprises.
La première décision touche au type d’hébergement. Certains choisissent un VPS léger pour garder la main sur Docker, d’autres préfèrent un serveur dédié pour un gros projet. Sur de très petits sites, il arrive encore que l’hébergement mutualisé soit conservé, avec Docker réservé au développement. Le choix dépend du budget, du trafic attendu et du niveau de confort souhaité sur l’infrastructure.
Adapter le docker-compose.yml au contexte serveur
Pour la production, le fichier docker-compose.yml doit tenir compte d’un reverse proxy réel, des bonnes règles de firewall et des volumes stockés sur un disque fiable. Les URL définies dans le fichier .env doivent passer de http://localhost à l’URL publique du site, par exemple https://www.moncabinet.fr. Les ports 80 et 443 sont exposés vers l’extérieur, généralement via un proxy comme Traefik ou un Nginx dédié qui gère aussi les certificats Let’s Encrypt.
Les images utilisées gagnent à être figées sur des versions précises plutôt que sur latest, pour éviter les mises à jour inattendues lors d’un simple docker-compose pull. Le stockage peut être confié à des volumes Docker classiques ou à des montages sur disque externe selon la stratégie de sauvegarde retenue. Pour un site qui vit toute l’année, cette étape d’ajustement n’est pas négociable.
Sauvegardes des volumes et de la base en environnement de production
Une stack Docker bien montée ne vaut rien sans un plan de sauvegarde. Côté fichiers, le volume contenant wp-content doit être archivé régulièrement, par exemple via un cron qui tar l’ensemble et pousse l’archive vers un stockage externe. Côté base, la plupart des équipes préfèrent un dump régulier via mysqldump, lancé soit depuis un conteneur dédié, soit directement depuis l’hôte :
docker exec -t mon_stack_db mysqldump -u wp_user -pmotdepasse wordpress > backup.sql
Ces dumps peuvent ensuite être compressés, chiffrés et envoyés vers un espace distant. L’idée est toujours la même : en cas de souci, il faut pouvoir reconstruire un conteneur propre, remonter les volumes ou réinjecter une base, et retrouver le site dans un état acceptable. Sans cette discipline, Docker donne parfois une fausse impression de sécurité.
Performance, monitoring et limites de Docker pour WordPress
Sur le plan des performances, Docker ajoute une légère couche d’abstraction, surtout sur de petits VPS. Sur une machine un peu limitée, un WordPress très lourd peut souffrir si la configuration des conteneurs n’est pas ajustée. Un minimum de tuning sur PHP-FPM et MariaDB reste nécessaire : nombre de workers, taille des buffers, caches appropriés. Pour certains sites à fort trafic, un Redis partagé et un CDN type Cloudflare aident beaucoup.
Côté surveillance, les logs sont répartis entre plusieurs conteneurs : Nginx, PHP-FPM, MariaDB, éventuellement un reverse proxy. Des outils comme Prometheus ou Netdata peuvent consolider ces informations, mais pour les petites structures, une approche plus simple avec quelques scripts et une veille manuelle reste souvent utilisée. Le point clé, c’est d’être capable de détecter rapidement une surconsommation CPU, un disque qui se remplit, une base qui commence à peiner. Docker aide à segmenter les responsabilités, mais ne remplace pas le regard sur le serveur.
Bonnes pratiques, erreurs courantes et cas d’usage typiques avec WordPress Dockerisé
Avec un peu de recul, certains schémas reviennent toujours lorsqu’une agence ou un freelance adopte Docker pour WordPress. Les projets qui se passent le mieux sont ceux où la configuration reste simple, documentée et pensée dès le départ pour être réutilisée. À l’inverse, les configurations bricolées à la va-vite sans respect des volumes, des versions ou des droits d’accès finissent souvent par poser problème au premier incident.
Un bon réflexe consiste à partir d’un template stable, à l’ajuster aux besoins de l’équipe, puis à le décliner pour chaque nouveau client en changeant le .env et quelques paramètres ciblés. Cette standardisation douce sécurise les projets sans les enfermer dans un moule trop rigide.
Erreurs fréquentes lors du déploiement d’un site web WordPress dockerisé
Parmi les pièges les plus courants, la gestion des volumes figure en bonne place. Oublier de persister le bon dossier peut conduire à une perte totale des modifications au redémarrage des conteneurs. Un simple rebuild peut alors effacer thèmes, plugins ou uploads. Une vérification systématique de ce qui est monté en volume avant un passage en production évite ce genre de frayeur.
Autre gourde classique : laisser les identifiants par défaut dans .env, surtout en copiant un modèle conçu pour le développement. Un admin WordPress avec « wordpress / wordpress » en production, même derrière un proxy, n’est jamais une bonne idée. Les ports exposés inutilement (phpMyAdmin ouvert au monde, par exemple) font aussi partie des oublis qui attirent les ennuis. La règle simple reste la meilleure : en ligne, on n’expose que ce qui est strictement nécessaire.
Cas d’usage où Docker Compose pour WordPress a le plus de sens
Sur le terrain, certains profils tirent un bénéfice immédiat de Docker Compose. Les agences qui gèrent un parc de sites pour des commerçants, des offices de tourisme ou des professions libérales y gagnent une capacité accrue à reproduire à l’identique un environnement pour tester une mise à jour majeure. Avant de toucher au site en ligne, on clone la base et les fichiers dans un stack de préproduction, on monte les mêmes conteneurs et on observe.
Les freelances qui interviennent sur des sites existants apprécient aussi de pouvoir embarquer un ancien WordPress avec sa version spécifique de PHP sans polluer leur machine principale. Pour les écoles ou les centres de formation, un kit Docker Compose WordPress prêt à l’emploi rend la vie plus simple aux apprenants : tous partent d’une base identique, les exercices se concentrent sur le CMS et non sur la configuration serveur locale. Enfin, pour les structures qui explorent une migration vers une infrastructure plus large (Kubernetes, cloud managé), Docker Compose sert souvent de première étape, plus accessible et directement exploitable.
Liste de réflexes utiles pour garder un WordPress dockerisé sain
Pour finir, voici une liste de réflexes concrets à garder sous la main lorsqu’un projet WordPress Docker Compose démarre :
- Figer les versions des images WordPress, PHP et MariaDB dans docker-compose.yml au lieu de s’en remettre à latest.
- Documenter le .env avec des commentaires clairs afin que n’importe quel membre de l’équipe sache quoi modifier avant un déploiement.
- Automatiser au minimum les sauvegardes de la base et des volumes critiques via des scripts ou un outil existant.
- Tester chaque mise à jour majeure (PHP, WordPress, gros plugin) dans un stack de préproduction issu du même fichier Compose.
- Limiter ce qui est exposé vers l’extérieur : ports, outils d’administration, comptes admin, et ne garder que l’indispensable en production.
Avec ces quelques habitudes, Docker Compose devient un allié fiable pour WordPress, plutôt qu’un outil de plus à surveiller. Au final, ce n’est pas la technologie qui fait la différence, mais la façon dont elle s’inscrit dans un quotidien déjà bien chargé entre clients, contenus, saisonnalité et contraintes de terrain.
Faut-il absolument utiliser Docker en production pour un site WordPress ?
Non. Docker apporte une vraie cohérence entre local et production, mais un site WordPress modeste peut très bien tourner sur un hébergement classique. Beaucoup d’équipes utilisent Docker uniquement pour le développement et les tests, puis déploient sur un mutualisé ou un VPS sans conteneurs. La question centrale reste le niveau de maîtrise et de temps disponible pour gérer l’infrastructure.
Comment migrer un WordPress existant vers Docker Compose ?
La migration se fait en quatre grandes étapes : copier les fichiers du site actuel dans le volume prévu (au minimum le dossier wp-content), exporter la base SQL existante, adapter le fichier wp-config.php ou les variables d’environnement pour pointer vers la nouvelle base, puis corriger les URL via un outil de recherche/remplacement dans la base si nécessaire. Un test complet en préproduction est vivement conseillé avant de basculer le DNS vers la nouvelle stack.
Un WordPress en conteneur est-il plus rapide qu’un WordPress classique ?
Pas forcément. La performance dépend surtout de la qualité du code, des réglages PHP/MySQL, des caches et des ressources du serveur. Docker ajoute une petite couche d’abstraction, mais sur un serveur correctement dimensionné, la différence reste marginale. En revanche, Docker facilite la mise en place de bonnes pratiques de performance, comme le découpage des services, l’usage de Redis ou l’ajout d’un reverse proxy optimisé.
Que faire si Docker pose des problèmes sur Windows avec la base MariaDB ?
Certains systèmes de fichiers Windows gèrent mal les entrées/sorties asynchrones attendues par MariaDB. Dans ce cas, on peut ajouter à la configuration du service base la commande suivante : `command: –innodb-flush-method=fsync –innodb-use-native-aio=0`. Cette option désactive l’I/O asynchrone côté InnoDB et contourne le problème. Beaucoup de templates récents l’intègrent déjà lorsqu’ils ciblent un usage Windows.
Docker Compose suffit-il pour un très gros site WordPress à fort trafic ?
Pour un trafic important, Docker Compose peut encore servir pour l’orchestration initiale, mais on bascule souvent vers des architectures plus avancées : plusieurs réplicas WordPress derrière un load balancer, base de données gérée en cluster, cache Redis mutualisé, stockage des médias externalisé (type S3) et plateformes d’orchestration plus robustes. Docker reste une brique utile, mais n’est qu’un morceau du puzzle global d’infrastructure.
