Volume on slash-root.fr

Docker : Configuration et gestion du stockage

Sun, 15 Jun 2025 16:56:25 +0200

Salut les admins sys et autres dompteurs de conteneurs ! Aujourd'hui, plongeons dans les profondeurs du stockage Docker. Comme on dit dans notre jargon : "Un disque mal configuré est à un admin système ce que Kryptonite est à Superman - une faiblesse qui peut tout paralyser."

Comprendre le stockage dans Docker

Docker utilise un système de stockage en couches qui peut être à la fois génial et déroutant. Chaque instruction dans un Dockerfile crée une nouvelle couche en lecture seule, et seul le conteneur en fonctionnement dispose d'une couche supérieure en lecture-écriture.

Par défaut, Docker stocke toutes ses données (images, conteneurs, volumes) dans /var/lib/docker. Sur un serveur de production, cette partition peut rapidement devenir le goulot d'étranglement de votre système.

Configuration du pilote de stockage

Docker propose plusieurs pilotes de stockage, chacun avec ses avantages et inconvénients. Vous pouvez configurer le pilote à utiliser dans le fichier /etc/docker/daemon.json :

{
 "storage-driver": "overlay2"
}

Note : overlay2 est généralement le pilote recommandé pour les distributions Linux modernes, offrant le meilleur équilibre entre performance et fonctionnalités.

Après cette modification, un redémarrage du service Docker est nécessaire :

sudo systemctl restart docker

Les différents pilotes de stockage

overlay2 : Le pilote recommandé pour la plupart des cas d'usage
- Avantages : Bonnes performances, compatibilité
- Prérequis : Noyau Linux 4.0+ et systèmes de fichiers modernes
Le pilote overlay2 repose sur la fonctionnalité OverlayFS du noyau Linux, qui permet de superposer plusieurs systèmes de fichiers. Il fonctionne avec la plupart des systèmes de fichiers courants (ext4, xfs) et offre de bien meilleures performances que l'ancien pilote overlay.
devicemapper : Utilisé principalement sur les anciennes versions de CentOS/RHEL
- Pour la production, configurez-le en mode direct-lvm plutôt qu'en mode loop-lvm par défaut
- Permet d'utiliser un périphérique de bloc dédié pour les données Docker, offrant de meilleures performances

{
 "storage-driver": "devicemapper",
 "storage-opts": [
 "dm.directlvm_device=/dev/xvdf"
 ]
}

Systèmes de fichiers avancés et distribués : Pour aller plus loin
- Les systèmes comme btrfs et zfs offrent des fonctionnalités avancées comme les snapshots
- Les systèmes de fichiers distribués comme Ceph ou GlusterFS permettent de créer une infrastructure de stockage Docker hautement disponible et évolutive
Astuce : Pour tirer pleinement profit de ces systèmes distribués, utilisez la technique du "volume bind déguisé" qui permet de créer un volume Docker qui pointe vers un point de montage réseau

Déplacer le répertoire de données Docker

Si votre partition /var est trop petite, vous pouvez déplacer le répertoire de données Docker vers un autre emplacement :

{
 "data-root": "/mnt/docker-data"
}

Attention : Ne modifiez jamais ce paramètre sur une installation Docker existante sans migrer correctement les données !

Pour migrer les données d'une installation existante :

# Arrêter Docker
sudo systemctl stop docker

# Créer le nouveau répertoire
sudo mkdir -p /mnt/docker-data

# Copier les données existantes
sudo rsync -aP /var/lib/docker/ /mnt/docker-data/

# Configurer le nouveau chemin dans daemon.json
# Puis redémarrer Docker
sudo systemctl start docker

Volumes bind déguisés : la technique du ninja du stockage

Une des techniques les plus astucieuses dans l'arsenal de l'admin Docker est celle du "volume bind déguisé" - ou comment faire passer un bind mount pour un volume Docker respectable, tout en gardant le contrôle sur l'emplacement physique des données.

Imaginez pouvoir dire à vos conteneurs : "Voici un volume Docker standard" alors qu'en coulisses, vous stockez les données sur votre cluster Ceph soigneusement configuré. C'est comme servir un plat végétarien à vos invités sans qu'ils ne remarquent l'absence de viande - l'élégance à l'état pur.

Cette technique est particulièrement précieuse quand vous travaillez avec :

Des systèmes de stockage distribués (Ceph, GlusterFS)
Des montages NFS pour un stockage partagé
Des volumes qui doivent survivre à la migration de vos conteneurs

Pour les détails d'implémentation, consultez mon article dédié : Docker : Volume bind déguisé qui vous explique pas à pas comment mettre en place cette technique.

Nettoyage de l’espace disque

Docker a tendance à accumuler des données inutilisées. Voici quelques commandes pour faire le ménage :

# Supprimer les conteneurs arrêtés, réseaux non utilisés, images dangling et cache de build
docker system prune

# Pour être encore plus agressif et supprimer aussi les images non utilisées
docker system prune -a

# Pour récupérer de l'espace sur les volumes non utilisés
docker volume prune

Bonnes pratiques pour la gestion du stockage

Utilisez des images légères : Préférez les images basées sur Alpine quand c'est possible
Optimisez vos Dockerfiles :
- Combinez les commandes RUN pour réduire le nombre de couches
- Nettoyez les caches de paquets dans la même instruction qui les installe

RUN apt update && apt install -y \
 package1 \
 package2 \
 && apt clean \
 && rm -rf /var/lib/apt/lists/*

Utilisez .dockerignore pour exclure les fichiers inutiles du contexte de build
Surveillez régulièrement l'espace disque utilisé par Docker avec docker system df
Configurez un cron job pour nettoyer périodiquement les ressources inutilisées

Conclusion

La gestion du stockage Docker ressemble parfois à un jeu de Tetris où les blocs seraient des gigaoctets - il faut savoir optimiser l'espace pour éviter le game over.

En configurant correctement votre pilote de stockage et en adoptant de bonnes pratiques de nettoyage, vous pourrez éviter ce moment gênant où vous devez expliquer pourquoi le serveur de production s'est arrêté juste parce qu'il y avait trop d'images "hello-world" qui traînaient.

Et souvenez-vous : dans un monde de conteneurs éphémères, les données persistantes méritent toujours une réflexion approfondie (et un bon volume Docker).

Docker : Volume bind déguisé

Wed, 11 Oct 2023 11:25:12 +0200

Avec Docker, il y a principalement 2 types de volumes qui sont utilisés :

Les volumes "volume" : Permet de stocker un répertoire du conteneur dans un volume docker stocké sur l'host (/var/lib/docker/volumes).
Les volumes "bind" : Permet de monter un répertoire présent sur l'host dans un conteneur.

Personnellement, j'utilise la plupart du temps des volumes de type "bind" afin d'avoir de la persistence pour certaines données d'un conteneur. Par exemple, une base de donnée.

Le problème que je recontre parfois est la gestion des utilisateurs/groupes propriétaires et des permissions sur les données stockées dans ce type de volume "bind".

Avec un volume "volume", l'avantage est que tout est géré par docker. Par contre, je ne souhaite pas forcément stocker ce volume docker dans /var/lib/docker/volumes de l'host.

Alors, nous allons voir comment utilisé un volume docker mais qui en faites sera un volume de type bind. Ce que je nomme un volume bind déguisé en volume docker 🙂

Création du volume docker

Tout d'abord, créer un répertoire local sur l'host qui stockera les données :

sudo mkdir -m 775 -p /srv/docker/volumes/data

Puis, changer l'utilisateur et groupe propriétaire :

sudo chown -R $USER:docker /srv/docker/volumes

Enfin, créer le volume docker :

docker volume create --driver local \
 --opt type=none \
 --opt device=/srv/docker/volumes/data \
 --opt o=bind vol_data

--driver local : Définit le driver docker à utiliser à local (par défaut).
--opt type=none : Il est important de bien définir le type à none.
--opt device= : Où seront stocké les données du volume sur l'host.
--opt o=bind : C'est avec cette option que le volume docker sera en faites un volume bind.

Vérifier la création du volume :

$ docker volume list
DRIVER VOLUME NAME
local vol_data

Vérifier les propriétés du volume :

$ docker inspect vol_data
[
 {
 "CreatedAt": "2023-10-11T11:15:38+02:00",
 "Driver": "local",
 "Labels": null,
 "Mountpoint": "/var/lib/docker/volumes/vol_data/_data",
 "Name": "vol_data",
 "Options": {
 "device": "/srv/docker/volumes/data",
 "o": "bind",
 "type": "none"
 },
 "Scope": "local"
 }
]

Un volume nommé vol_data est à présent disponible pour un conteneur.

Utilisation du volume docker

Avec docker run

Pour utiliser ce volume docker avec docker run , comme avec un volume docker "classique", utiliser l'option --volume vol_data:/data. Cela montera le volume docker "vol_data" précédement créé dans le point de montage "/data" du conteneur.

Avec docker compose

Pour utiliser ce volume docker dans un docker-compose.yml, c'est comme un volume classique :

version: '3'
services
 app:
 #...
 volumes:
 - vol_data:/data
 #...
volumes:
 vol_data:

Portainer

Si portainer est utilisé pour gérer l'hôte docker, le volume apparaitra dans la section "Volumes" de l'interface web. Si vous créez vos conteneurs, services, stacks swarm sur Portainer, vous pourrez l'utiliser sans problème.

Toutefois, il est impossible de créer ce genre de volume via l'interface web de portainer.

Attention cependant au nom du volume que vous lui donner lors de sa création.

Par exemple, je souhaite utiliser un volume docker (qui finalement sera de type bind) dans une stack swarm qui s'appelle "webapp". Lors de la création du volume, je le nommerai "webapp_vol_data" et dans mon fichier yaml de la stack, j'appelerai ce volume uniquement "vol_data".

Si le volume utilisé dans un docker-compose n'est pas bien définit au niveau du nommage, un volume docker "standard" sera alors automatiquement créer à la place et celui-ci sera dans /var/lib/docker/volumes.

Donc bien penser à vérifier que les données soient au bon endroit sur l'host. Surtout si les données doivent être stockées sur un volume réseau !