Gérer plusieurs environnements WordPress peut vite tourner au cauchemar, surtout quand on jongle entre développement, tests et mise en production. Avec Docker et une stack bien pensée, on peut créer un écosystème complet qui simplifie drastiquement ce processus. Dans cet article, je vous partage ma configuration Docker complète pour orchestrer vos projets WordPress de A à Z, avec tous les outils nécessaires pour un workflow professionnel.
Configuration et structure Docker avancée
Une stack WordPress bien architecturée avec Docker nécessite une approche méthodique et une compréhension fine des interactions entre services. Contrairement à une installation classique, cette approche permet de créer un environnement reproductible et scalable.
Architecture multi-services avec Docker Compose
L’architecture que je recommande s’articule autour de cinq services essentiels qui travaillent en symbiose. Le service WordPress utilise l’image wordpress:latest comme base ; il s’agit du cœur de notre application web. Pour la base de données, j’opte systématiquement pour mariadb:10.6 qui offre des performances supérieures à MySQL classique.
Le service Redis (redis:alpine) joue le rôle de cache en mémoire – un élément crucial pour optimiser les performances de WordPress. phpMyAdmin facilite la gestion de base de données pendant le développement, tandis que Traefik (traefik:v3.0) agit comme reverse proxy intelligent.
Cette configuration crée un réseau Docker isolé où chaque service communique via des noms de domaine internes. Par exemple, WordPress se connecte à la base via mariadb:3306 plutôt qu’une IP fixe.
Variables d’environnement et fichiers de configuration
La gestion des environnements multiples passe obligatoirement par une structure de fichiers bien pensée. Je structure toujours mes projets avec un docker-compose.yml principal et trois fichiers d’environnement : .env.dev, .env.staging, et .env.prod.
Les variables critiques incluent WORDPRESS_DB_PASSWORD et MYSQL_ROOT_PASSWORD pour la sécurité, TRAEFIK_HOST pour définir les noms de domaine (wordpress.local en dev, staging.monsite.com en pré-production), et les ports d’exposition selon l’environnement.
Cette approche permet de switcher facilement entre environnements avec la commande docker-compose --env-file .env.prod up -d par exemple. Et c’est particulièrement utile quand on travaille en équipe !
Optimisation des volumes et performances
La stratégie de volumes varie drastiquement selon l’environnement d’exécution. En développement, j’utilise exclusivement le bind mounting pour le répertoire wp-content : cela permet de modifier les thèmes et plugins directement depuis l’IDE.
Pour la production, les volumes nommés sont incontournables. Ils offrent une meilleure isolation et des performances optimisées. La base de données MariaDB bénéficie toujours d’un volume dédié (mariadb_data) pour garantir la persistance.
Une astuce que j’applique systématiquement : séparer les volumes statiques (uploads, thèmes) des volumes dynamiques (cache Redis). Cela facilite grandement les sauvegardes et la migration entre environnements. Et n’oubliez pas de configurer les bonnes permissions sur les volumes montés !
Mise en place des environnements de développement, staging et production
Maintenant que nous avons défini l’architecture de base, il est temps de configurer nos trois environnements distincts. Chaque environnement répond à des besoins spécifiques et nécessite une approche adaptée.
Configuration locale avec Docker Desktop
L’environnement de développement local doit privilégier la simplicité et la rapidité d’exécution. Avec Docker Desktop, la configuration est relativement directe :
# docker-compose.dev.yml
version: '3.8'
services:
wordpress:
ports:
- "8080:80"
volumes:
- ./wp-content:/var/www/html/wp-content
- ./themes:/var/www/html/wp-content/themes
environment:
- XDEBUG_MODE=develop,debug
L’avantage du bind mounting ? Vos modifications sont immédiatement visibles dans le conteneur. Attention cependant à bien configurer xdebug si vous souhaitez déboguer votre code PHP ; cela nécessite quelques ajustements dans la configuration du conteneur.
Environnement de staging sécurisé
Pour le staging, la sécurité devient primordiale. On utilise Traefik comme reverse proxy avec une authentification basique :
# Labels Traefik pour le staging
labels:
- "traefik.http.routers.staging.rule=Host(`staging.monsite.com`)"
- "traefik.http.middlewares.staging-auth.basicauth.users=admin:$$2y$$10$$hash"
- "traefik.http.routers.staging.tls.certresolver=letsencrypt"
Let’s Encrypt gère automatiquement les certificats SSL. Mais n’oubliez pas de configurer les volumes persistants pour éviter de perdre vos données lors des redémarrages !
Déploiement en production avec SSL automatique
En production, chaque détail compte. Les optimisations de sécurité passent par la limitation des logs et l’utilisation de volumes nommés plutôt que des bind mounts :
logging:
driver: "json-file"
options:
max-size: "10m"
max-file: "3"
Pour le monitoring, j’intègre souvent Prometheus et Grafana dans la stack. Ces outils permettent un suivi en temps réel des performances et facilitent la détection d’anomalies. Les backups automatisés ? Indispensables ! Un simple script avec mysqldump et rsync peut suffire dans bien des cas.
Synchronisation des données entre environnements
La synchronisation entre environnements est souvent le point délicat. wp-cli en conteneur simplifie grandement les opérations :
# Synchronisation de la base de données
docker exec wordpress-prod wp db export - | docker exec -i wordpress-staging wp db import -
Pour les fichiers uploads, rsync reste une valeur sûre. Cependant, attention aux permissions ! Docker peut parfois créer des conflits de propriétaire entre les environnements.
Concernant les secrets, évitez à tout prix de les stocker dans vos fichiers docker-compose. Les Docker secrets ou les variables d’environnement chiffrées constituent une approche bien plus sécurisée. Par exemple, vous pouvez utiliser un fichier .env.secret qui ne sera jamais versionné dans votre repository Git.
Workflow de développement et déploiement automatisé
Une fois vos environnements Docker configurés, il devient essentiel de structurer un workflow de développement efficace. Cette approche permet d’automatiser les tâches répétitives et de garantir une cohérence entre les différents environnements.
Organisation des branches Git et correspondance Docker
La structure de vos branches Git doit refléter vos environnements Docker pour faciliter le déploiement. Je recommande généralement trois branches principales :
- develop : synchronisée avec l’environnement de développement local
- staging : déclenchant automatiquement le déploiement sur l’environnement de test
- main : correspondant à la production, avec déploiement manuel requis
Chaque branche peut avoir son propre fichier .env versionné (.env.develop, .env.staging, .env.prod) pour adapter automatiquement la configuration Docker selon le contexte.
# Exemple de switch automatique d'environnement
git checkout staging
cp .env.staging .env
docker-compose up -d
Scripts d’automatisation essentiels
Trois scripts bash sont indispensables pour automatiser votre workflow : build.sh, deploy.sh et backup.sh.
Le script build.sh gère la création d’images personnalisées :
#!/bin/bash
ENV=${1:-dev}
echo "Building for environment: $ENV"
docker-compose -f docker-compose.$ENV.yml build --no-cache
docker image prune -f
Le script deploy.sh orchestre le déploiement selon l’environnement :
#!/bin/bash
if [ "$1" = "prod" ]; then
echo "Production deployment requires manual confirmation"
read -p "Continue? (y/n): " confirm
[ "$confirm" != "y" ] && exit 1
fi
docker-compose -f docker-compose.$1.yml up -d
Enfin, backup.sh automatise les sauvegardes critiques :
#!/bin/bash
BACKUP_DIR="./backups/$(date +%Y%m%d_%H%M%S)"
mkdir -p $BACKUP_DIR
docker exec wordpress_db mysqldump -u root -p$MYSQL_ROOT_PASSWORD wordpress > $BACKUP_DIR/database.sql
docker cp wordpress:/var/www/html/wp-content $BACKUP_DIR/
Intégration continue avec GitHub Actions
L’automatisation via GitHub Actions permet de tester et déployer automatiquement vos modifications. Voici un workflow basique mais efficace :
name: WordPress Docker CI/CD
on:
push:
branches: [staging, main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Test Docker containers
run: |
docker-compose -f docker-compose.staging.yml up -d
sleep 30
curl -f http://localhost || exit 1
deploy-staging:
if: github.ref == 'refs/heads/staging'
needs: test
runs-on: self-hosted
steps:
- name: Deploy to staging
run: ./deploy.sh staging
Cette configuration teste automatiquement vos conteneurs et déploie sur staging, mais nécessite une validation manuelle pour la production – une sécurité indispensable !
Outils complémentaires pour la gestion quotidienne
Plusieurs outils peuvent considérablement améliorer votre productivité quotidienne. WP-CLI en conteneur facilite les tâches d’administration :
# Installation de plugins via WP-CLI
docker exec -it wordpress wp plugin install contact-form-7 --activate
# Migration de base de données
docker exec -it wordpress wp search-replace 'oldurl.com' 'newurl.com'
Pour la synchronisation entre environnements, WP Migrate DB reste une référence, mais vous pouvez aussi utiliser des scripts personnalisés :
# Synchronisation staging vers développement
./backup.sh staging
docker exec wordpress_dev wp db import /backups/latest/database.sql
En développement, l’intégration de browser-sync dans votre conteneur WordPress permet le hot-reload :
# Dans docker-compose.dev.yml
services:
browsersync:
image: node:16-alpine
command: npx browser-sync start --proxy wordpress:80 --files '/var/www/html/**/*'
ports:
- "3000:3000"
volumes:
- ./wp-content:/var/www/html/wp-content
Commandes Docker Compose courantes
Voici quelques commandes que j’utilise quotidiennement et qui peuvent vous faire gagner un temps précieux :
# Reconstruction complète avec nettoyage
docker-compose down -v && docker-compose build --no-cache && docker-compose up -d
# Logs en temps réel des services spécifiques
docker-compose logs -f wordpress mariadb
# Exécution de commandes dans un service spécifique
docker-compose exec wordpress bash
docker-compose exec mariadb mysql -u root -p
# Mise à l'échelle d'un service (utile pour les tests de charge)
docker-compose up -d --scale wordpress=3
Ces outils et workflows, une fois maîtrisés, transforment complètement votre approche du développement WordPress. Et croyez-moi, revenir en arrière devient quasiment impossible !