Je viens d'inspecter mon dossier/var/lib/docker/volumes et j'ai découvert qu'il regorge de dossiers nommés comme Docker UUID, chacun contenant un fichier config.json avec un contenu dans le sens de
{"ID":"UUID","Path":"/path/to/mounted/volume","IsBindMount":true,"Writable":true}
où
/path/to/mounted/volume
est le chemin d'accès au dossier sur l'hôte qui a été monté sur un conteneur Docker avec le commutateur -v à un moment donné. J'ai de tels dossiers qui remontent au début de mes expériences avec Docker, c'est-à-dire il y a environ 3 semaines.
Les conteneurs en question ont été arrêtés et le docker a été commandé il y a longtemps, je ne peux donc pas voir que ces entrées n'ont pas dépassé leur date de péremption. Cela soulève la question - est-ce que je reste sur un bug ou faut-il supprimer manuellement ces entrées de/var/lib/docker/volumes?
Pour Docker 1.9 et versions ultérieures, il existe une méthode native:
Liste tous les volumes orphelins avec
$ docker volume ls -qf dangling=true
Éliminez-les tous avec
$ docker volume rm $(docker volume ls -qf dangling=true)
Dans le guide de l'utilisateur Docker:
Si vous supprimez des conteneurs qui montent des volumes, y compris le conteneur dbdata initial ou les conteneurs suivants db1 et db2, les volumes ne seront pas supprimés. Pour supprimer le volume du disque, vous devez appeler explicitement docker rm -v contre le dernier conteneur avec une référence au volume. Cela vous permet de mettre à niveau ou de migrer efficacement des volumes de données entre conteneurs. - source
Il s'agit d'un comportement intentionnel pour éviter la perte accidentelle de données. Vous pouvez utiliser un outil comme docker-cleanup-volumes pour nettoyer les volumes inutilisés.
Pour Docker 1.13+ et les numéros de version ce/ee 17+, utilisez le volume Prune
commande
docker volume Prune
Contrairement au dangling=true
requête, cela ne supprimera pas les volumes basés sur des pilotes "distants".