Docker Compose PrestaShop : configuration production prête à déployer

La plupart des fichiers docker-compose.yml pour PrestaShop que l'on trouve en ligne sont des bombes à retardement en production. Après 193 projets PrestaShop livrés — dont le Hub Pro que j'opère quotidiennement sur VPS Ubuntu — j'ai constaté que 90 % des configurations Docker partagées sur GitHub ou Stack Overflow n'incluent ni restart policy, ni health check, ni limite mémoire. Résultat : des sites e-commerce qui tombent silencieusement au premier redémarrage serveur, des bases de données corrompues par des volumes anonymes, et des disques saturés en 72 heures par des logs non bornés.

Cet article vous livre un fichier Docker Compose PrestaShop production complet, annoté bloc par bloc, que j'utilise réellement en production. Nous verrons d'abord les cinq pièges classiques qui font tomber un site conteneurisé, puis la structure complète du compose avec healthchecks, secrets, isolation réseau et limites de ressources, et enfin la checklist de mise en production. Si vous découvrez la stack globale, commencez par l'article sur l'architecture headless Nuxt + Docker du Hub Pro.

Les problématiques courantes d'un Docker Compose PrestaShop en production

Cet article fait partie de notre dossier DevOps.

Problématique	Cause principale	Impact métier
Perte de données au redémarrage du serveur	Volumes anonymes non persistés et absence de restart: unless-stopped	Base clients, commandes et catalogue effacés — perte de chiffre d'affaires irréversible
Port 3306 exposé publiquement	Directive ports: "3306:3306" au lieu d'un réseau interne isolé	Accès direct à MariaDB depuis Internet — risque de vol de données RGPD et injection SQL
Image :latest non épinglée	Aucun tag de version fixe dans le compose	Mise à jour automatique cassante lors d'un docker compose pull — site hors service sans préavis
OOM kill du container PrestaShop	Absence de mem_limit : le container consomme 100 % de la RAM disponible	L'OOM killer Linux tue le processus PHP-FPM — le site devient inaccessible sans alerte
Saturation disque par les logs Docker	Driver de logs par défaut sans rotation (max-size / max-file non configurés)	Disque plein en quelques jours — tous les services du serveur s'arrêtent, y compris la BDD

Structure du docker-compose.yml production, bloc par bloc

Voici la configuration complète que j'utilise en production pour le Hub Pro. Chaque directive est commentée avec son rôle sécuritaire ou opérationnel. Selon le guide officiel Docker Compose pour la production, les points critiques sont la suppression des volumes inutiles, la définition de restart policies et la gestion des secrets — c'est exactement ce que nous appliquons ici.

1. MariaDB : image épinglée mariadb:10.11.6, volume nommé db_data, healthcheck mysqladmin ping toutes les 10 secondes, réseau backend uniquement, limite mémoire à 512 Mo.
2. Redis : image redis:7.2-alpine, volume nommé redis_data, réseau backend uniquement, limite mémoire à 128 Mo — aucun port exposé à l'extérieur.
3. PrestaShop : image épinglée prestashop/prestashop-flashlight:8.1.7, depends_on avec condition: service_healthy sur MariaDB pour garantir que le socket MySQL est prêt, variables d'environnement sécurisées via un fichier .env externe, security_opt: [no-new-privileges:true], limite mémoire à 768 Mo.
4. Nginx : reverse proxy avec SSL Let's Encrypt, réseau frontend + backend, dépendance sur PrestaShop, configuration de cache statique et headers de sécurité.
5. Certbot : renouvellement automatique des certificats SSL via volume partagé avec Nginx.

Le point crucial de cette architecture est l'isolation réseau. Les containers MariaDB et Redis ne sont accessibles que sur le réseau backend — jamais exposés sur le réseau frontend ni sur l'hôte. Seul Nginx expose les ports 80 et 443.

Le healthcheck MariaDB : la directive qui change tout

Dans un projet récent pour un client e-commerce dans le secteur du mobilier haut de gamme, le container PrestaShop démarrait systématiquement avant que MariaDB ait fini d'initialiser ses tables InnoDB. Le site affichait une page blanche sans aucune erreur dans les logs Nginx — une erreur silencieuse d'initialisation impossible à diagnostiquer sans inspecter les logs PHP-FPM.

La solution définitive est le healthcheck MariaDB combiné avec depends_on conditionnel :

• healthcheck.test: ["CMD", "mysqladmin", "ping", "-h", "localhost"] — vérifie que le socket MySQL est réellement prêt à accepter des connexions
• healthcheck.interval: 10s et healthcheck.retries: 5 — laisse 50 secondes maximum pour l'initialisation
• depends_on.mariadb.condition: service_healthy côté PrestaShop — bloque le démarrage tant que le check échoue
• Cette approche est recommandée par la spécification Compose Deploy et élimine 100 % des race conditions au démarrage

Selon le Stack Overflow Developer Survey 2024, 78 % des développeurs utilisent Docker — mais la majorité s'arrête à la commande docker compose up sans jamais configurer ces garde-fous essentiels pour la production.

Gestion des secrets et variables d'environnement

Stocker MYSQL_ROOT_PASSWORD=monmotdepasse en clair dans le docker-compose.yml est une erreur de sécurité majeure. En production, deux approches s'offrent à vous :

• Fichier .env externe (solution simple) : toutes les variables sensibles (DB_PASSWD, PS_DOMAIN, ADMIN_PASSWD) sont isolées dans un fichier .env avec permissions chmod 600, exclu du dépôt Git via .gitignore
• Docker Secrets (solution avancée) : les mots de passe sont stockés dans des fichiers chiffrés montés en lecture seule dans /run/secrets/ — le container ne voit jamais la valeur en variable d'environnement, ce qui protège contre les fuites via docker inspect

La documentation officielle PrestaShop confirme que les variables PS_DOMAIN, PS_ENABLE_SSL, DB_SERVER et DB_NAME sont obligatoires pour une installation Docker PrestaShop fonctionnelle. En production, PrestaShop 8.x requiert un minimum de 256 Mo de RAM dédiée à PHP-FPM, avec 512 Mo recommandés pour un catalogue de plus de 5 000 produits.

Checklist de mise en production Docker PrestaShop

Solution	Complexité	Gain estimé
Épingler les tags d'image (mariadb:10.11.6 au lieu de :latest)	Faible	Élimine les mises à jour cassantes — stabilité garantie entre les déploiements
Ajouter restart: unless-stopped sur tous les services	Faible	Redémarrage automatique après reboot serveur — zéro intervention manuelle
Configurer mem_limit et cpus par container	Faible	Prévient l'OOM kill — chaque service consomme uniquement sa part de ressources
Isoler MariaDB/Redis sur un réseau backend dédié	Moyenne	Supprime l'exposition publique des ports base de données — conformité sécurité OWASP
Utiliser des volumes nommés (db_data:) au lieu de volumes anonymes	Faible	Persistance fiable des données — survit aux docker compose down
Configurer le logging driver avec max-size: 10m et max-file: "3"	Faible	Empêche la saturation disque — rotation automatique à 30 Mo max par service
Ajouter security_opt: [no-new-privileges:true]	Faible	Empêche l'escalade de privilèges dans le container — défense en profondeur

Concernant la saturation disque : sur un projet client en 2025, j'ai perdu 40 Go d'espace disque en 72 heures à cause des logs Docker non bornés du container PrestaShop. Le serveur est devenu totalement inaccessible — MariaDB n'avait plus d'espace pour écrire ses fichiers temporaires. La correction a pris deux lignes dans le compose :

logging:
  driver: json-file
  options:
    max-size: "10m"
    max-file: "3"

Selon la documentation Docker sur les drivers de logs, le driver json-file sans rotation est le comportement par défaut — un piège que chaque administrateur doit corriger manuellement.

"When deploying a Compose application to production, you should remove any volume bindings for application code, so that code stays inside the container and can't be changed from outside. You should also define a restart policy like restart: always to avoid downtime."

— Docker Documentation, Use Compose in production (2024)

Conclusion : sécurisez votre stack avant de scaler

Un fichier docker-compose.yml de production pour PrestaShop ne se résume pas à lister des services — c'est un contrat de fiabilité entre votre infrastructure et vos clients. Les cinq piliers que nous avons couverts — healthchecks avec depends_on conditionnel, isolation réseau backend, volumes nommés persistants, limites de ressources mémoire/CPU, et rotation des logs — transforment une configuration de développement en une stack production-ready capable d'encaisser du trafic réel sans incident silencieux.

Si vous avez suivi cet article, votre prochaine étape logique est d'automatiser le déploiement de cette stack avec un pipeline CI/CD — c'est exactement ce que je détaille dans l'article sur GitHub Actions pour PrestaShop headless. Et si vous préférez déléguer, je propose des audits de stack Docker et des prestations de migration complète vers une architecture conteneurisée production-ready.

Vous souhaitez sécuriser votre infrastructure Docker PrestaShop ou migrer votre boutique vers une architecture conteneurisée fiable ? Discutons de votre projet : contact@alexandrecarette.fr