Volumes Docker : conserver les données et prévoir les sauvegardes

Les volumes Docker conservent les fichiers applicatifs hors de la couche accessible en écriture du conteneur. Un volume nommé peut subsister après la suppression du conteneur et être réutilisé par son remplaçant. Cette persistance ne constitue pas une sauvegarde et ne garantit pas la conservation des données si l'hôte ou son disque est supprimé.

Ce guide présente les choix de stockage, un petit contrôle de persistance et la différence entre remplacement d'un conteneur et suppression des données. Les exemples utilisent des conteneurs Linux et des données de test jetables. Vérifiez l'hôte Docker et le nom du volume avant de les exécuter.

Choisir entre volume, montage bind et couche du conteneur

La présentation du stockage Docker distingue les données applicatives du stockage des images et des couches des conteneurs. Les fichiers conservés uniquement dans la couche accessible en écriture disparaissent à la suppression du conteneur. Un simple arrêt est différent : cette couche reste disponible au redémarrage du même conteneur.

• Volume nommé : utilisez un nom reconnaissable, géré par Docker, pour des données qui doivent survivre à un conteneur.
• Montage bind : choisissez un chemin précis sur l'hôte lorsque ses outils et un conteneur doivent accéder aux mêmes fichiers, par exemple du code source ou une configuration.
• Stockage temporaire en mémoire : envisagez tmpfs pour des données d'exécution jetables adaptées à ce mécanisme, après vérification de ses limites. Ce stockage n'est pas persistant.

Un volume local par défaut appartient à l'hôte du démon Docker. Une nouvelle VM ne le récupère pas automatiquement. Le stockage réseau et les plugins de volume ont leurs propres conditions de configuration, d'accès et de panne. Sur une VM cloud, vérifiez séparément le cycle de vie des disques auprès du fournisseur ; un réglage Docker ne peut pas le déterminer.

Comprendre les noms, les chemins et les montages

Un volume anonyme reçoit un nom généré. Il est plus difficile à identifier et n'est pas réutilisé automatiquement par chaque nouveau conteneur. Avec docker run --rm, les volumes anonymes associés sont normalement supprimés à la sortie du conteneur, tandis que les volumes nommés restent. Préférez un nom explicite pour les données à réutiliser.

Un montage peut masquer les fichiers déjà présents au chemin cible. Un volume vide peut recevoir une copie des fichiers de l'image situés à cet endroit ; volume-nocopy désactive cette initialisation. Un volume non vide n'est pas actualisé à partir d'une nouvelle image. La documentation des montages de volumes décrit ces comportements. Vérifiez le chemin de données documenté par l'application au lieu de reprendre celui d'une ancienne version.

Les montages bind utilisent des chemins sur l'hôte du démon, qui peut différer de l'ordinateur exécutant le client Docker. Ils sont accessibles en écriture par défaut : un conteneur peut donc modifier les fichiers de l'hôte. Préférez la lecture seule lorsque c'est possible. Par défaut, --mount signale une source absente plutôt que de créer silencieusement un répertoire ; la syntaxe courte -v peut en créer un.

Créer un volume nommé et vérifier la persistance

Utilisez un hôte hors production sur lequel vous pouvez exécuter des conteneurs Linux. Le contexte courant aide à identifier l'environnement sélectionné. Vérifiez que le serveur est accessible et examinez les noms des volumes existants :

docker context show
docker version
docker compose version
docker volume ls

Arrêtez-vous si le contexte est inattendu ou si la connexion au serveur échoue. Choisissez un autre nom si volume-demo-20261030 existe déjà. docker volume create peut réutiliser un nom présent sur le même pilote ; cette commande ne garantit pas un nouveau volume vide.

docker volume create volume-demo-20261030
docker volume inspect volume-demo-20261030

Le résultat de l'inspection indique le nom, le pilote, les options et le point de montage. Vérifiez ces éléments, mais accédez aux données par un conteneur qui monte le volume. Ne modifiez pas directement le répertoire interne de Docker.

Écrivez une valeur connue avec un conteneur temporaire. La commande peut télécharger l'image Alpine si elle est absente. Elle ne demande ni port publié ni accès réseau pour le conteneur :

docker run --rm --network none --mount type=volume,src=volume-demo-20261030,dst=/data alpine:3.22 sh -c "printf '%s\n' volume-check > /data/note.txt"

Après la réussite de cette commande, son conteneur est supprimé. Lancez un autre conteneur avec le même volume nommé, monté cette fois en lecture seule :

docker run --rm --network none --mount type=volume,src=volume-demo-20261030,dst=/data,readonly alpine:3.22 cat /data/note.txt

Le résultat attendu est volume-check. Ce contrôle vérifie qu'un fichier reste lisible après le remplacement du conteneur qui l'a écrit, conformément au modèle de persistance Docker. Il ne teste ni une panne de l'hôte, ni la récupération d'une sauvegarde, ni la cohérence d'une base. Examinez tout code de sortie non nul avant de poursuivre.

L'exemple utilise alpine:3.22, une branche figurant dans le calendrier de support Alpine. Un tag peut recevoir des mises à jour. Pour une procédure de production contrôlée, choisissez et consignez un digest d'image approuvé, puis maintenez-le selon votre processus de mise à jour.

Monter le volume existant avec Docker Compose

Enregistrez ce contenu dans compose.yaml, dans un nouveau répertoire de test. Le service lit le fichier créé précédemment. La syntaxe longue du montage précise son type, sa source, sa cible et son accès en lecture seule :

services:
  reader:
    image: alpine:3.22
    network_mode: none
    command: ["cat", "/data/note.txt"]
    volumes:
      - type: volume
        source: demo-data
        target: /data
        read_only: true

volumes:
  demo-data:
    external: true
    name: volume-demo-20261030

La clé demo-data est une référence Compose. Le champ name désigne le volume Docker réel. Avec external: true, Compose exige que ce volume existe et ne le crée pas. Ce réglage décrit la gestion de son cycle de vie ; il ne signifie ni stockage distant ni sauvegarde indépendante.

Commencez par valider la configuration, puis effectuez une exécution ponctuelle avec Compose. Ne lancez la seconde commande que si la validation réussit :

docker compose -p volume-lab-20261030 -f compose.yaml config --quiet
docker compose -p volume-lab-20261030 -f compose.yaml run --rm reader

Le service reader doit afficher la même valeur. Pour une application réelle, le service utiliserait son image et son répertoire de données. Sans nom explicite, Compose associe normalement le nom d'un volume géré à celui du projet. Un changement de projet peut sélectionner un autre volume et donner l'impression que l'application est vide. Inspectez le montage réel avant toute restauration ou suppression.

Organiser les sauvegardes selon l'application

Monter une source en lecture seule la protège des écritures du conteneur de sauvegarde. Cela n'empêche pas un autre conteneur de la modifier pendant la copie. Une commande d'archivage réussie peut donc avoir capturé des fichiers applicatifs incohérents.

Pour une base de données, utilisez la méthode de sauvegarde prise en charge ou coordonnez un instantané cohérent. Les règles de sauvegarde du système de fichiers PostgreSQL expliquent, par exemple, pourquoi une copie ordinaire d'un répertoire actif ne suffit pas. Traitez l'arrêt et les instantanés comme des procédures propres à l'application.

Consignez les éléments à récupérer : fichiers de données, version applicative, configuration, propriétaires, permissions, clés éventuelles et dépendances externes. Gardez une copie protégée indépendamment avec une politique de conservation définie. Notre guide de la sauvegarde cloud couvre cette organisation.

Restaurez dans un nouveau volume de test et une instance applicative isolée. Vérifiez des enregistrements connus, les permissions et le comportement de l'application. Mesurez le délai de récupération. Notre guide des tests de récupérabilité aide à transformer ces contrôles en critères d'acceptation.

Savoir quelles opérations de nettoyage suppriment les données

Un docker compose down ordinaire supprime les conteneurs et réseaux du projet, mais conserve par défaut les volumes nommés gérés. L'option --volumes supprime les volumes gérés déclarés et les volumes anonymes attachés. Les volumes externes sont exclus de cette suppression par Compose, mais restent supprimables par d'autres outils.

docker volume prune vise actuellement les volumes locaux anonymes inutilisés par défaut ; --all inclut aussi les volumes nommés inutilisés. « Inutilisé » signifie qu'aucun conteneur ne référence le volume, pas que ses données sont sans valeur. docker system prune --volumes a une portée différente. Lisez la documentation et l'avertissement de la commande exacte avant tout nettoyage.

Uniquement après avoir confirmé que les données de cet exercice sont jetables et qu'aucune application n'en a besoin, supprimez ce nom précis avec docker volume rm :

docker volume rm volume-demo-20261030

Ne remplacez pas ce nom par celui d'un volume de production et n'ajoutez pas d'option de forçage pour contourner une erreur inattendue. Pour vos applications, désignez un responsable pour chaque volume et documentez son usage, sa sauvegarde et sa politique de suppression. Un nom de stockage indique où chercher ; une procédure de récupération testée établit si les données sont récupérables.