Nettoyer Docker sur Mac sans perdre de données

Docker Desktop peut occuper des dizaines de gigaoctets, car les images, les couches inscriptibles des conteneurs, le cache de build et les volumes se trouvent dans un disque virtuel Linux. Ces catégories ne se jettent pas toutes de la même façon. Le cache de build est en général reproductible ; un volume de base de données peut être la seule copie de données importantes. Un nettoyage sûr commence par l’inventaire Docker, pas par la commande de prune la plus large.

Pourquoi l’espace Docker ne revient pas

Docker Desktop sur macOS exécute une machine virtuelle Linux et stocke en principe ses données dans un disque virtuel creux (sparse) nommé Docker.raw. Le guide de stockage Mac de Docker indique Docker Desktop > Settings > Resources > Advanced pour son emplacement, la limite de disque et l’espace réellement consommé. Déplacez-le avec ce réglage, pas avec le Finder. Un fichier creux a une taille logique maximale et une allocation physique plus petite, donc ls -lh seul peut le faire paraître bien plus gros que la capacité qu’il occupe actuellement.

Voyez ce que Docker lui-même estime utiliser :

docker system df -v

La vue détaillée décompose les images, les conteneurs, les volumes locaux et le cache de build. « Reclaimable » signifie que Docker ne voit aucune référence courante qui exige cet objet ; cela ne prouve pas que vous n’aurez pas besoin demain d’un conteneur arrêté, d’une ancienne image ou d’un volume. Inspectez aussi docker ps -a et docker volume ls avant tout prune.

Commencer par un nettoyage ciblé

Récupérez toujours l’espace depuis Docker, pas en supprimant le fichier de disque virtuel. Commencez par la catégorie que vous maîtrisez. Un prune est irréversible : vérifiez d'abord si des images, des modifications de conteneurs ou des volumes contiennent des données uniques, puis sauvegardez-les :

docker builder prune --filter until=168h
docker image prune
docker container prune

La première commande supprime le cache de build de plus de sept jours ; ajustez l’âge selon votre travail. Les deux suivantes demandent confirmation avant de retirer les images orphelines (dangling) et les conteneurs arrêtés. Relancez docker system df -v après chaque étape pour voir quelle action a compté.

Le guide de pruning de Docker documente docker system prune comme commande de commodité plus large. Ajouter -a retire toutes les images inutilisées, pas seulement les couches orphelines. Ajouter --volumes élargit l’opération aux volumes anonymes inutilisés, qui peuvent contenir des fichiers de base de données ou d’autre état. N’en faites pas une habitude : docker system prune -a --volumes ne doit pas être la commande de nettoyage par défaut. Avant tout prune de volumes, inspectez les noms et la propriété :

docker volume ls
docker volume inspect <volume-name>

Les volumes créés par Compose portent en général des labels de projet et de service. Identifiez le projet propriétaire et exportez ou sauvegardez les données qui ne peuvent pas être reconstruites avant de supprimer le volume. Pour une base de données, utilisez sa fonction de sauvegarde ou arrêtez les écritures avant de copier ses fichiers, afin d’obtenir une sauvegarde cohérente.

Récupérer l’image disque elle-même

Supprimer Docker.raw dans le Finder n’est pas un moyen sûr de récupérer de l’espace. Ce fichier est le disque entier de la VM Linux : le supprimer dans le Finder ou avec rm détruit toutes les images, tous les conteneurs et tous les volumes qu’il contient, pas seulement l’espace inutilisé, et Docker recrée un disque vide au lancement suivant. Récupérez plutôt l’espace depuis Docker : lancez un prune, laissez le disque creux restituer ses blocs, et réglez l’emplacement et la limite de l’image disque dans Settings. Le chiffre énorme affiché est souvent le maximum logique d’un fichier creux, pas l’espace physique occupé ; mesurez l’allocation réelle avant de supposer que tout est récupérable.

Après un prune, des blocs libres existent dans le système de fichiers Linux avant que macOS ne les reçoive nécessairement du disque creux. La documentation Docker actuelle indique qu’une image Docker.raw rend en général l’espace hôte éligible en quelques secondes ; les anciennes images Docker.qcow2 s’appuient sur un processus en arrière-plan qui peut prendre plusieurs minutes. Remesurez l’usage réel du disque au lieu de juger le maximum logique du fichier. Une réinitialisation d’usine n’est pas une compaction : elle détruit les conteneurs locaux, les images, les volumes et les réglages. Ne l’utilisez que lorsque cette perte totale est volontaire et que les données de volume importantes ont été exportées.

Sous le capot : pourquoi le fichier grossit et ne rétrécit pas

Docker Desktop exécute une machine virtuelle Linux, et Docker.raw est le disque virtuel de cette VM : un fichier creux qui grossit quand l’invité écrit, mais qui ne rend pas nécessairement l’espace immédiatement à macOS lorsque l’invité supprime. Retirer une image marque des blocs libres dans le système de fichiers de la VM, mais le fichier hôte ne rétrécit que si l’invité émet un TRIM/discard et que Docker Desktop peut utiliser discard et compaction pour restituer les blocs éligibles. Le délai dépend de la version et de l’implémentation de l’image disque. C’est pourquoi un nettoyage logique et un changement de capacité côté hôte doivent être mesurés séparément, et pourquoi supprimer le fichier hôte revient à détruire tout l’environnement Docker.

Où une carte disque aide

Une carte disque comme la vue Analyser de Mole peut révéler le disque virtuel et son empreinte physique. C’est le CLI de Docker qui doit décider quels objets internes sont référencés. Les deux vues répondent à des questions différentes : macOS montre où la capacité est allouée, tandis que Docker explique ce que cette allocation contient.

Un ordre d’opérations sûr

Exécutez docker system df -v, repérez les anciens projets et les volumes avec état, exportez les données uniques, et prunez une catégorie à la fois. Revérifiez à la fois les totaux internes de Docker et la capacité physique de macOS. N’utilisez les drapeaux de prune larges qu’après avoir examiné leur portée élargie, et ne traitez jamais une réinitialisation d’usine comme raccourci de routine pour récupérer de l’espace. Le gain sûr le plus rapide est en général l’ancien cache de build, pas des volumes inconnus.