Docker volumes
| Fiche express | |
|---|---|
| Type | Persistance de données au-delà du cycle de vie d'un conteneur |
| Types de montage | Volume nommé · Bind mount · tmpfs |
| Storage driver | overlay2 (par défaut sur les distributions récentes) |
| Voir aussi | Docker containers · Docker images · Docker |
Par défaut, les données écrites dans un conteneur disparaissent avec lui. Les volumes Docker répondent à ce problème : ils fournissent un espace de stockage qui survit à la suppression du conteneur, peut être partagé entre plusieurs conteneurs, et peut être local ou distant. Cas d'usage typiques : faire persister les données d'une base de données, faciliter les sauvegardes, ou partager un même jeu de fichiers entre plusieurs conteneurs.
Storage drivers
Le storage driver détermine comment Docker assemble les couches d'image en système de fichiers pour un conteneur :
- overlay2 — driver de type filesystem storage, par défaut sur les distributions Linux récentes ; c'est le choix recommandé dans la grande majorité des cas.
- devicemapper — driver de type block storage, historiquement utilisé sur les distributions plus anciennes (CentOS/RHEL antérieurs à la 7 notamment) ; adapté à des charges avec beaucoup d'I/O mais aujourd'hui considéré comme un choix de dernier recours, à éviter sur une installation neuve.
- aufs — autre driver de type filesystem storage, antérieur à overlay2, désormais rarement rencontré.
- Object storage — les conteneurs peuvent aussi s'appuyer sur du stockage objet, mais dans ce cas c'est l'application elle-même qui doit être conçue pour en tirer parti ; ce n'est pas un mécanisme géré nativement par Docker.
Le driver peut se surcharger dans la configuration du démon (/etc/docker/daemon.json) plutôt que sur la ligne de commande du service (méthode recommandée) :
{
"storage-driver": "overlay2"
}
(La surcharge directe de ExecStart dans l'unité systemd du démon — dockerd --storage-driver ... -H fd:// --containerd=/run/containerd/containerd.sock — fonctionne mais n'est pas la méthode recommandée : elle est écrasée à chaque mise à jour du paquet.)
Gestion des volumes nommés
docker volume ls
docker volume create myDebian
# montage du volume dans un conteneur
docker run -d --name c1 -v myDebian:/var/data/ debian:latest
docker volume inspect myDebian
Résultat type d'un inspect :
[
{
"CreatedAt": "2024-09-04T15:19:33Z",
"Driver": "local",
"Labels": null,
"Mountpoint": "/var/lib/docker/volumes/myDebian/_data",
"Name": "myDebian",
"Options": null,
"Scope": "local"
}
]
Les données sont physiquement accessibles côté hôte sous /var/lib/docker/volumes/<nom>/_data :
ls /var/lib/docker/volumes/myDebian/_data
docker volume rm myDebian
Types de montage
Docker propose trois mécanismes de montage, sélectionnables via l'option --mount (plus explicite que l'ancienne syntaxe -v) :
| Type | Principe | Persistance |
|---|---|---|
Volume nommé (type=volume) |
Espace de stockage géré par Docker, indépendant de l'arborescence de l'hôte | Oui, gérée par Docker |
Bind mount (type=bind) |
Monte un chemin existant de l'hôte directement dans le conteneur | Oui, gérée manuellement côté hôte |
tmpfs (type=tmpfs) |
Espace de travail temporaire en mémoire, jamais écrit sur disque | Non, perdu à l'arrêt du conteneur |
Chacun accepte les options ,readonly ou ,readwrite :
# bind mount : point de montage existant de l'hôte
docker run -d -it --name c1 --mount type=bind,source=/data,destination=/var/data/,readonly debian:latest bash
# volume nommé Docker
docker run -d -it --name c1 --mount type=volume,source=myDebian,destination=/var/data/ debian:latest bash
# tmpfs : temporaire, en mémoire
docker run -d -it --name c1 --mount type=tmpfs,destination=/var/data/ debian:latest bash
docker inspect c1