Volumes Docker : comprendre leur fonctionnement et leur gestion sur WordPress

Un site WordPress qui fonctionne dans Docker peut sembler parfaitement stable… jusqu’au jour où l’on supprime un conteneur et que la bibliothèque de médias disparaît avec lui. Ce n’est pas de la magie noire, ni une blague particulièrement drôle de l’équipe technique : c’est souvent une question de volumes.

Les volumes Docker permettent de conserver les données en dehors du cycle de vie des conteneurs. Pour WordPress, ils sont essentiels : ils protègent les fichiers du site et la base de données, facilitent les sauvegardes et rendent les environnements de développement plus prévisibles. Voyons comment ils fonctionnent, comment les gérer et quelles erreurs éviter pour ne pas transformer une mise à jour banale en séance de récupération d’urgence.

Conteneur et volume : deux rôles bien différents

Un conteneur Docker est une instance en fonctionnement, créée à partir d’une image. On peut le démarrer, l’arrêter, le remplacer ou le supprimer. Cette souplesse est l’un des grands intérêts de Docker, mais elle a une conséquence importante : les données écrites uniquement dans le système de fichiers du conteneur ne sont pas conçues pour durer.

Un volume, lui, stocke des données à l’extérieur du système de fichiers propre au conteneur. Docker relie ensuite ce stockage à un emplacement précis dans le conteneur. WordPress peut ainsi accéder à ses fichiers comme s’ils se trouvaient dans son environnement habituel, tandis qu’ils restent disponibles même si le conteneur est recréé.

Imaginez un conteneur comme une salle de travail temporaire et un volume comme une armoire que l’on conserve lorsqu’on change de salle. On peut réaménager la pièce sans jeter les dossiers. Pour un site, ces dossiers sont notamment les images envoyées dans la médiathèque, les extensions installées et les données de la base.

Pourquoi WordPress a besoin de volumes

Une installation WordPress repose principalement sur deux familles de données persistantes : les fichiers et la base de données. Les fichiers comprennent le cœur du site, les thèmes, les extensions et, surtout, le répertoire des téléversements. La base contient le contenu, les réglages, les comptes et une grande partie de la configuration.

Si ces éléments restent uniquement dans des conteneurs, leur remplacement peut entraîner une perte de données. Or, remplacer un conteneur est une opération normale : on le recrée pour appliquer une nouvelle image, modifier une configuration ou réparer un service. Un déploiement réussi ne devrait pas dépendre du fait que l’on n’ose jamais toucher à son conteneur.

Avec des volumes correctement configurés, on peut mettre à jour le conteneur WordPress tout en conservant les fichiers du site. On peut également redémarrer la base de données sans perdre son contenu. Attention, toutefois : un volume n’est pas une sauvegarde. Il protège les données contre la suppression du conteneur, mais pas contre une panne du disque, une erreur humaine ou une corruption de base.

Les principaux types de stockage Docker

Docker propose plusieurs manières de relier des données à un conteneur. Pour un projet WordPress, les volumes nommés et les montages de dossiers sur l’hôte sont les deux options les plus courantes.

Le volume nommé est créé et géré par Docker. On lui attribue un nom, par exemple wordpress_fichiers, et Docker choisit l’emplacement où ses données seront conservées. C’est généralement une option fiable pour les environnements de test et de production.
Le montage de dossier sur l’hôte relie un répertoire de l’ordinateur à un emplacement du conteneur. Le dossier est visible directement depuis le système hôte. C’est pratique pour modifier le code localement et voir les changements sans reconstruire l’image.
Le système de fichiers temporaire conserve les données uniquement pendant la durée de vie du conteneur. Il convient à des fichiers provisoires, mais pas aux médias WordPress ou à une base de données que l’on souhaite garder.

En développement, monter le dossier du projet facilite le travail quotidien. En production, un volume nommé est souvent plus simple à administrer et moins dépendant de l’organisation des dossiers de la machine. Il n’existe pas de choix universel : il faut surtout savoir où sont les données et qui en est responsable.

Exemple avec Docker Compose

Voici un exemple volontairement simplifié d’un environnement WordPress avec une base MariaDB et deux volumes nommés. L’un conserve les fichiers WordPress, l’autre les données de la base.

services:  wordpress:    image: wordpress:latest    ports:      - "8080:80"    environment:      WORDPRESS_DB_HOST: base      WORDPRESS_DB_NAME: site      WORDPRESS_DB_USER: utilisateur      WORDPRESS_DB_PASSWORD: mot_de_passe    volumes:      - wordpress_fichiers:/var/www/html    depends_on:      - base  base:    image: mariadb:11    environment:      MARIADB_DATABASE: site      MARIADB_USER: utilisateur      MARIADB_PASSWORD: mot_de_passe      MARIADB_ROOT_PASSWORD: mot_de_passe_admin    volumes:      - wordpress_base:/var/lib/mysqlvolumes:  wordpress_fichiers:  wordpress_base:

Dans cette configuration, Docker crée les volumes déclarés à la fin du fichier et les relie aux emplacements indiqués. Le chemin /var/www/html contient les fichiers utilisés par WordPress, tandis que /var/lib/mysql accueille les données de MariaDB.

Un détail mérite votre attention : l’image WordPress peut contenir des fichiers initiaux dans son répertoire. Lorsqu’un volume vide est monté à cet emplacement, Docker peut y copier le contenu initial prévu par l’image. Ce comportement est pratique, mais il ne remplace pas une vérification : avant de modifier un déploiement existant, identifiez précisément le volume utilisé et les fichiers qu’il contient.

L’exemple emploie une image désignée par latest pour rester facile à lire. En production, mieux vaut choisir une version précise et la faire évoluer de manière contrôlée. Une mise à jour d’image ne devrait jamais être une surprise que l’on découvre après le café du lundi.

Créer, inspecter et retrouver un volume

Docker Compose crée les volumes déclarés lors du démarrage des services. Pour voir ceux qui existent sur la machine, utilisez :

docker volume ls

Pour examiner un volume précis et connaître son emplacement ainsi que ses informations de montage :

docker volume inspect wordpress_fichiers

Si les noms sont préfixés par le nom du projet Compose, c’est normal : Compose évite ainsi les collisions entre plusieurs projets. Le volume peut alors porter un nom tel que monsite_wordpress_fichiers. Pour savoir quel volume utilise un conteneur, inspectez également celui-ci :

docker inspect nom_du_conteneur

La sortie est détaillée. Recherchez la partie consacrée aux montages : elle indique le volume ou le dossier source, ainsi que son chemin dans le conteneur. Cette vérification est particulièrement utile avant une suppression ou une migration. Deviner le nom d’un volume est une méthode rapide, mais rarement une méthode rassurante.

Que se passe-t-il lorsqu’on supprime un conteneur ?

Supprimer un conteneur ne supprime généralement pas les volumes nommés qui lui sont associés. On peut donc recréer le service et rattacher le même volume pour retrouver les données. C’est précisément l’intérêt de séparer le stockage du conteneur.

Les commandes Compose demandent toutefois un peu de prudence. docker compose down arrête et supprime les conteneurs du projet, mais conserve normalement les volumes nommés. En revanche, l’option -v demande aussi la suppression des volumes associés au projet :

docker compose down -v

Dans un environnement de test, cette commande peut être utile pour repartir de zéro. Sur un site contenant des données importantes, elle peut effacer la base et les fichiers persistants. Avant de l’utiliser, vérifiez deux fois le projet, les volumes et la présence de sauvegardes récentes. La commande ne connaît pas la valeur sentimentale de votre médiathèque.

Un montage de dossier sur l’hôte suit une autre logique : les fichiers se trouvent dans le dossier indiqué sur la machine, et non dans un volume géré par Docker. La suppression du conteneur ne supprime donc pas automatiquement ce dossier. Mais si vous effacez ou déplacez celui-ci, le contenu ne sera plus disponible à l’emplacement attendu.

Volumes et montages de dossiers : choisir selon l’usage

Pour développer un thème ou une extension, le montage d’un dossier local est souvent très pratique. Vous éditez les fichiers avec votre environnement habituel, puis vous observez le résultat dans WordPress. Il convient cependant de faire attention aux permissions : le processus du serveur web dans le conteneur doit pouvoir lire les fichiers et, lorsque nécessaire, écrire dans les répertoires concernés.

Pour conserver une base de données ou les fichiers d’un site en production, un volume nommé apporte une séparation plus nette entre le service et ses données. Il est plus facile à rattacher à un nouveau conteneur et moins lié à un chemin précis de l’ordinateur hôte. Il faut néanmoins prévoir comment il sera sauvegardé, restauré et, si besoin, déplacé vers un autre serveur.

Évitez de monter un dossier vide sur l’ensemble de /var/www/html sans comprendre l’effet obtenu. Le contenu de l’image peut être masqué par le dossier de l’hôte, ce qui donne parfois l’impression que WordPress a disparu ou qu’il manque des fichiers. Pour ne partager que les extensions ou les thèmes en développement, il peut être préférable de monter uniquement les sous-dossiers concernés.

Sauvegarder et restaurer : le volume ne suffit pas

Un volume est un espace de stockage persistant, pas un mécanisme de sauvegarde automatique. Une suppression accidentelle, une défaillance matérielle ou une mauvaise manipulation peut toujours compromettre les données. Une stratégie sérieuse prévoit des copies indépendantes, conservées à un autre emplacement, et des essais réguliers de restauration.

Pour WordPress, sauvegardez les fichiers nécessaires et exportez la base de données. Une copie des seuls fichiers ne contient pas les articles, les comptes et les réglages enregistrés dans MariaDB. À l’inverse, une sauvegarde de la base ne récupère pas les images téléversées. Les deux parties doivent donc être prises en compte et idéalement associées à une même date de sauvegarde.

Après une restauration, vérifiez que le conteneur utilise bien les volumes restaurés, que les permissions permettent l’accès aux fichiers et que les identifiants de connexion à la base sont cohérents. Enfin, ouvrez le site et testez quelques fonctions essentielles : connexion à l’administration, affichage d’une page, accès aux médias et publication d’un contenu de test.

Quelques habitudes qui évitent les mauvaises surprises

Nommez clairement vos volumes. Un nom comme site_production_base est plus explicite qu’une suite de caractères incompréhensible, surtout plusieurs mois plus tard.
Documentez les chemins montés. Notez ce qui contient les fichiers WordPress, ce qui contient la base et quels services y ont accès.
Évitez les suppressions à l’aveugle. Avant une commande de nettoyage, examinez les volumes existants et confirmez ceux qui peuvent réellement être supprimés.
Testez les mises à jour ailleurs qu’en production. Une copie de test permet de vérifier la compatibilité des extensions et du thème avant de toucher au site en ligne.
Testez les restaurations. Une sauvegarde que personne n’a jamais restaurée est une promesse, pas encore une preuve.

Les volumes Docker ne sont pas la partie la plus visible d’un site WordPress, mais ils en sont souvent l’une des fondations les plus importantes. Comprendre où résident les fichiers et la base permet de recréer des conteneurs sans crainte, de mieux organiser les mises à jour et de préparer une vraie stratégie de sauvegarde. En somme, Docker peut rendre votre site plus facile à faire évoluer — à condition de ne pas confondre conteneur jetable et données jetables.