Configuration d’un laboratoire local de volumes Docker avec exemples pratiques

Introduction

Les volumes Docker sont l’une des fonctionnalités les plus importantes pour tout développeur travaillant avec des conteneurs. Ils permettent aux données de survivre après la suppression d’un conteneur, à plusieurs conteneurs de partager des fichiers, et offrent souvent de meilleures performances que les montages bind. Pourtant, le comportement des volumes peut prêter à confusion, surtout lorsque vous débutez avec Docker ou que vous essayez de déboguer la disparition de données après le redémarrage d’un conteneur.

Ce guide vous accompagne dans la mise en place d’un laboratoire local de volumes Docker sûr. Le laboratoire vous offre un environnement contrôlé pour expérimenter avec les volumes nommés, les montages bind, la sauvegarde et la restauration, ainsi que les scénarios de défaillance courants, sans risquer les données de production. À la fin, vous disposerez d’un ensemble d’étapes et de commandes reproductibles que vous pourrez utiliser pour gagner en confiance et diagnostiquer les problèmes dans vos propres projets.

Un laboratoire bien défini transforme les concepts en étapes vérifiées et réutilisables. Séparer la configuration, les expériences et la validation réduit les retouches et vous aide à inspecter ce qui se passe sous le capot. Le premier pilote utile doit être étroit, mesurable et facile à inspecter localement avant de l’appliquer à des charges de travail réelles.

Inventaire des versions et de l’environnement

Avant de commencer, assurez-vous que votre environnement répond aux prérequis. Cette section répertorie les versions et les outils utilisés dans ce guide, la topologie du laboratoire et les commandes de vérification initiales.

Versions de Docker Engine et Compose

Ce guide suppose Docker Engine 20.10 ou ultérieur et Docker Compose v2. Vous pouvez vérifier votre version installée avec :

docker version

La sortie attendue inclut les versions client et serveur, par exemple :

Client: Docker Engine - Community
 Version:           24.0.5
 API version:       1.43
 Go version:        go1.20.6
 Git commit:        ced0996
 Built:             Fri Jul 21 12:55:16 2023
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          24.0.5
  API version:      1.43 (minimum version 1.12)
  Go version:       go1.20.6
  Git commit:       a61e2b4
  Built:            Fri Jul 21 12:55:16 2023
  OS/Arch:          linux/amd64
  Experimental:     false

Pour Docker Compose, exécutez :

docker compose version

Sortie attendue :

Docker Compose version v2.20.2

Topologie du laboratoire

Le laboratoire utilise un seul hôte Docker (votre machine locale). Vous allez créer quelques volumes nommés, un répertoire de montage bind et un nombre limité de conteneurs. Cette portée garde l’environnement gérable et facile à nettoyer. Aucun service externe ni réseau n’est requis.

Vérification des prérequis

Confirmez que Docker est en cours d’exécution et que vous avez la permission d’exécuter des commandes :

docker info

Recherchez Server Version et Storage Driver (par exemple, overlay2). Si vous obtenez une erreur de permission, ajoutez votre utilisateur au groupe docker ou utilisez sudo (mais préférez l’approche par groupe pour plus de commodité).

Chemin de configuration sûr

Dans ce laboratoire, vous travaillez avec deux types de volumes : les volumes nommés et les montages bind. Les volumes nommés sont gérés par Docker et stockés dans une partie du système de fichiers de l’hôte. Les montages bind mappent un répertoire hôte directement dans un conteneur. Vous verrez également comment sauvegarder et restaurer les données d’un volume à l’aide d’un conteneur temporaire et d’archives tar. Ces techniques sont le fondement de nombreux modèles de gestion de données du monde réel.

Création d’un volume nommé et écriture de données

Commencez par créer un volume nommé :

docker volume create lab_volume

Sortie attendue :

lab_volume

Exécutez maintenant un conteneur temporaire qui écrit un fichier dans le volume et se termine. Utilisez l’option --rm pour que le conteneur soit supprimé après son exécution :

docker run --rm -v lab_volume:/data alpine sh -c 'echo "Bonjour depuis le volume nommé" > /data/hello.txt'

Aucune sortie si la commande réussit. Vérifiez que les données persistent en les lisant dans un autre conteneur :

docker run --rm -v lab_volume:/data alpine cat /data/hello.txt

Sortie attendue :

Bonjour depuis le volume nommé

Utilisation d’un montage bind

Créez un répertoire sur l’hôte :

mkdir -p ~/docker-lab/bind-mount

Exécutez un conteneur qui écrit un fichier via le montage bind :

docker run --rm --mount type=bind,source=~/docker-lab/bind-mount,target=/data alpine sh -c 'echo "Bonjour depuis le montage bind" > /data/hello.txt'

Vérifiez le fichier sur l’hôte :

cat ~/docker-lab/bind-mount/hello.txt

Sortie attendue :

Bonjour depuis le montage bind

Les montages bind vous permettent de voir les fichiers directement, ce qui est utile pour le développement. Les volumes nommés sont meilleurs pour les performances et la gestion, surtout en production.

Sauvegarde et restauration d’un volume nommé

Pour sauvegarder les données d’un volume nommé, vous pouvez monter le volume dans un conteneur temporaire et créer une archive tar sur l’hôte :

docker run --rm -v lab_volume:/source -v $(pwd):/backup alpine tar czf /backup/lab_volume_backup.tar.gz -C /source .

Cette commande crée lab_volume_backup.tar.gz dans votre répertoire courant. Vérifiez que l’archive existe :

ls -lh lab_volume_backup.tar.gz

La sortie attendue montre la taille du fichier, par exemple :

-rw-r--r-- 1 user user 123 Jan  1 12:00 lab_volume_backup.tar.gz

Pour restaurer, créez d’abord un nouveau volume :

docker volume create lab_volume_restored

Puis extrayez l’archive dans ce volume :

docker run --rm -v lab_volume_restored:/target -v $(pwd):/backup alpine sh -c 'tar xzf /backup/lab_volume_backup.tar.gz -C /target'

Vérifiez en lisant le fichier :

docker run --rm -v lab_volume_restored:/data alpine cat /data/hello.txt

Sortie attendue :

Bonjour depuis le volume nommé

Ce modèle de sauvegarde et de restauration fonctionne pour tout volume nommé et constitue une compétence essentielle pour la gestion des données.

Partage de volumes entre conteneurs

L’un des principaux avantages des volumes nommés est le partage de données entre conteneurs. Testons cela en exécutant deux conteneurs qui montent tous deux lab_volume et écrivent ou lisent des fichiers.

D’abord, démarrez un conteneur à longue durée de vie qui écrit un horodatage chaque seconde dans un fichier sur le volume :

docker run -d --name writer -v lab_volume:/data alpine sh -c 'while true; do date >> /data/timestamps.txt; sleep 1; done'

Maintenant, démarrez un second conteneur qui lit le fichier :

docker run --rm -v lab_volume:/data alpine tail -f /data/timestamps.txt

Vous devriez voir les horodatages apparaître en temps réel. Cela démontre que les deux conteneurs accèdent aux mêmes données de volume. Appuyez sur Ctrl+C pour arrêter le lecteur, puis arrêtez et supprimez l’écrivain :

docker stop writer && docker rm writer

Montages en lecture seule

Parfois, vous voulez qu’un conteneur accède aux données d’un volume sans les modifier. Utilisez le suffixe :ro pour les montages en lecture seule :

docker run --rm -v lab_volume:/data:ro alpine sh -c 'cat /data/hello.txt; echo "essayer d\'écrire" > /data/newfile.txt'

Sortie attendue :

Bonjour depuis le volume nommé
sh: can't create /data/newfile.txt: Read-only file system

Les montages en lecture seule sont utiles pour servir du contenu statique ou fournir des fichiers de configuration aux conteneurs.

Vérification et diagnostics

Après avoir configuré les volumes, vous devez vérifier qu’ils se comportent comme prévu et inspecter leur état. Docker fournit plusieurs commandes pour cela.

Liste des volumes

Utilisez docker volume ls pour voir tous les volumes :

docker volume ls

La sortie attendue inclut les volumes que vous avez créés :

DRIVER    VOLUME NAME
local     lab_volume
local     lab_volume_restored

Inspection d’un volume

Pour voir des informations détaillées, y compris le point de montage sur l’hôte, utilisez :

docker volume inspect lab_volume

Sortie attendue (tronquée pour la lisibilité) :

[
    {
        "CreatedAt": "2023-01-01T00:00:00Z",
        "Driver": "local",
        "Labels": null,
        "Mountpoint": "/var/lib/docker/volumes/lab_volume/_data",
        "Name": "lab_volume",
        "Options": null,
        "Scope": "local"
    }
]

Le Mountpoint est l’endroit où les données du volume résident sur l’hôte. Vous ne pouvez l’inspecter que si vous avez un accès root ; traitez-le comme interne et ne le modifiez pas sauf nécessité.

Vérification des montages de volume d’un conteneur

Pour un conteneur en cours d’exécution, vous pouvez inspecter ses montages :

docker run -d --name test_container -v lab_volume:/data alpine sleep 300

Puis :

docker inspect test_container --format '{{ json .Mounts }}'

La sortie attendue montre la configuration du montage :

[{"Type":"volume","Name":"lab_volume","Source":"/var/lib/docker/volumes/lab_volume/_data","Destination":"/data","Driver":"local","Mode":"","RW":true,"Propagation":""}]

Cela valide que le conteneur utilise le bon volume.

Utilisation du disque par les volumes

Vous pouvez vérifier l’espace disque utilisé par un volume avec la commande docker system df :

docker system df -v

Recherchez la section Local Volumes pour voir chaque volume et sa taille. Cela vous aide à identifier les volumes qui occupent trop d’espace.

Modes de défaillance et récupération

Les volumes sont fiables, mais vous pouvez rencontrer des problèmes. Cette section couvre les modes de défaillance courants, comment récupérer et comment annuler les modifications.

Suppression accidentelle d’un conteneur mais pas du volume

Si vous supprimez un conteneur qui utilise un volume nommé, le volume et ses données restent. Vous pouvez tester cela :

docker run -d --name data_container -v lab_volume:/data alpine sleep 300
# écrire des données
docker exec data_container sh -c 'echo "persistant" > /data/persist.txt'
docker rm -f data_container

Exécutez maintenant un nouveau conteneur utilisant le même volume et vérifiez que les données sont toujours là :

docker run --rm -v lab_volume:/data alpine cat /data/persist.txt

Sortie attendue :

persistant

Cela montre que les volumes nommés survivent à la suppression du conteneur.

Suppression d’un volume et perte de données

Si vous supprimez un volume nommé avec docker volume rm, les données sont définitivement perdues (sauf si vous avez des sauvegardes). Sauvegardez toujours avant de supprimer :

docker volume rm lab_volume_restored

Sortie attendue :

lab_volume_restored

Si vous tentez de supprimer un volume encore utilisé par un conteneur, Docker renvoie une erreur :

docker volume rm lab_volume

Erreur :

Error response from daemon: remove lab_volume: volume is in use - [container_id]

Arrêtez et supprimez d’abord le conteneur, puis supprimez le volume.

Retour en arrière via sauvegarde

Si vous corrompez des données dans un volume, vous pouvez restaurer à partir d’une archive de sauvegarde comme indiqué précédemment. C’est le principal mécanisme de retour en arrière. Conservez toujours des sauvegardes récentes des volumes critiques.

Problèmes de permission avec les montages bind

Lors de l’utilisation de montages bind, le conteneur peut ne pas avoir la permission d’écrire dans le répertoire hôte, surtout avec SELinux ou AppArmor activés. Si vous obtenez une erreur « Permission denied », vous pouvez utiliser le suffixe :z ou :Z sur le montage pour réétiqueter les fichiers de manière appropriée. Par exemple :

docker run --rm -v ~/docker-lab/bind-mount:/data:z alpine sh -c 'echo test > /data/test.txt'

N’utilisez :z ou :Z que si vous comprenez les implications de sécurité ; ils sont principalement nécessaires sur les systèmes basés sur Red Hat.

Corruption de données ou écritures partielles

Si un conteneur plante pendant l’écriture dans un volume, les données peuvent être corrompues ou incomplètes. Cela est rare avec les volumes locaux, mais vous pouvez le simuler en arrêtant brusquement un conteneur pendant une écriture. Pour récupérer, restaurez à partir d’une sauvegarde ou réparez manuellement les fichiers. En production, utilisez un pilote de volume qui prend en charge les instantanés pour une récupération plus robuste.

Pièges et erreurs courants

De nombreux développeurs rencontrent les mêmes problèmes lorsqu’ils travaillent avec les volumes Docker. Voici les pièges les plus courants, pourquoi ils surviennent et comment les éviter ou les corriger.

Utiliser des montages bind au lieu de volumes nommés pour les données persistantes

Pourquoi cela arrive : Les montages bind sont faciles à comprendre car vous pouvez voir les fichiers sur l’hôte. Mais ils sont liés à la structure de répertoires de l’hôte, ce qui les rend moins portables et potentiellement plus lents.

Comment éviter ou corriger : Utilisez des volumes nommés pour les données d’application qui doivent persister et être gérées par Docker. Réservez les montages bind au développement où vous avez besoin d’un accès en direct au code source ou aux fichiers de configuration.

Ne pas sauvegarder les volumes avant de les supprimer

Pourquoi cela arrive : Les développeurs supposent que puisqu’un volume survit à la suppression du conteneur, il survivra aussi à la suppression du volume. Mais docker volume rm supprime définitivement les données.

Comment éviter ou corriger : Sauvegardez toujours les volumes critiques avant suppression. Automatisez les sauvegardes avec un script ou utilisez un pilote de volume prenant en charge les instantanés.

Ignorer les permissions sur les montages bind

Pourquoi cela arrive : Sur Linux, l’utilisateur du conteneur peut ne pas correspondre aux ID utilisateur de l’hôte, provoquant des erreurs de permission. C’est particulièrement courant avec SELinux ou AppArmor.

Comment éviter ou corriger : Utilisez les options de montage :z ou :Z pour réétiqueter les fichiers, ou ajustez les ID utilisateur avec l’option --user. Pour le développement, vous pouvez également définir les permissions du répertoire pour autoriser les écritures de l’utilisateur du conteneur.

Monter le même volume dans plusieurs conteneurs sans coordination

Pourquoi cela arrive : Plusieurs conteneurs écrivant dans le même volume peuvent provoquer des conditions de concurrence ou des corruptions de fichiers s’ils ne sont pas conçus pour un accès concurrent.

Comment éviter ou corriger : Utilisez des montages en lecture seule pour les conteneurs qui n’ont besoin que de lire les données. Pour les écrivains, implémentez un verrouillage de fichiers ou utilisez une base de données qui gère l’accès concurrent.

Laisser des volumes orphelins

Pourquoi cela arrive : Avec le temps, des volumes s’accumulent à partir de conteneurs supprimés sans utiliser docker rm -v ou docker compose down -v. Ces volumes orphelins consomment de l’espace disque.

Comment éviter ou corriger : Utilisez docker volume prune pour supprimer les volumes inutilisés, mais veillez à ne pas supprimer les volumes encore nécessaires. En production, mettez en place une politique de nettoyage.

Liste de vérification opérationnelle

Utilisez cette liste à chaque fois que vous configurez ou modifiez votre laboratoire de volumes Docker. Elle garantit la cohérence et vous aide à éviter les erreurs courantes.

Parcourez cette liste après tout changement expérimental pour confirmer que le laboratoire reste dans un état connu et bon.

Conclusion

Vous avez maintenant mis en place un laboratoire local de volumes Docker et travaillé sur des exemples pratiques de volumes nommés, de montages bind, de sauvegarde et restauration, de vérification et de récupération. Ces étapes vous offrent un environnement sûr pour explorer des sujets plus avancés, tels que les pilotes de volume, la configuration des volumes dans Docker Compose et les stratégies de migration de données.

Un laboratoire pratique réduit la portée à ce que vous pouvez mesurer et inspecter. Commencez par des expériences simples, conservez des sauvegardes et documentez vos résultats. À mesure que vous gagnez en aisance, étendez le laboratoire pour refléter les modèles de données de vos applications réelles.

Prochaines étapes : essayez d’attacher le même volume nommé à plusieurs conteneurs pour observer le partage, automatisez la sauvegarde avec un script et expérimentez les montages en lecture seule (:ro) pour comprendre les contrôles d’accès. Chaque étape s’appuie sur les fondations que vous avez établies ici.