AskCleanAskClean

Docker occupe trop d’espace sur Mac ? Le récupérer sans risque

Équipe AskClean · Mis à jour 2026-07-31

Exécutez docker system df -v pour déterminer si l’espace vient des images, conteneurs arrêtés, caches de build ou volumes. Élaguez d’abord la catégorie diagnostiquée, gardez les volumes nommés tant que leurs données ne sont pas sauvegardées et ne supprimez ni ne déplacez jamais Docker.raw manuellement dans le Finder.

Stockage Docker isométrique avec conteneurs, couches d’images, fragments de cache et volume de données protégé
Le stockage Docker réunit plusieurs catégories dans un disque virtuel : inspectez chacune avant de l’élaguer.

Pourquoi Docker paraît énorme sous macOS

Docker Desktop exécute les conteneurs Linux dans une machine virtuelle légère. Images, couches inscriptibles, cache de build et volumes vivent dans une grande image disque, souvent appelée Docker.raw, et non dans des dossiers ordinaires à modifier avec le Finder.

La capacité maximale du fichier, sa taille apparente et l’espace réellement utilisé par Docker ne sont pas toujours identiques. Un fichier sparse peut réserver une grande plage logique tout en occupant moins de blocs physiques. Commencez par les mesures de Docker et l’espace libre macOS.

Supprimer Docker.raw contourne le modèle d’objets de Docker et peut détruire d’un coup images, conteneurs et volumes locaux. Le déplacer dans le Finder peut aussi casser Docker Desktop ; utilisez Settings pour changer son emplacement.

Effectuer un audit en lecture seule

Démarrez Docker Desktop puis exécutez docker system df. La commande résume images, conteneurs, volumes locaux, cache de build et espace récupérable. Ajoutez -v pour le détail : docker system df -v.

Interprétez « reclaimable » avec prudence. Une image peut être partagée par plusieurs conteneurs et un volume détaché peut encore contenir une base de données destinée à être restaurée.

Ouvrez aussi Docker Desktop Settings > Resources et relevez la limite d’usage du disque ainsi que l’emplacement de l’image disque disponibles dans votre version. Si Docker ne démarre plus, sauvegardez son fichier de données selon la procédure de récupération avant toute réinitialisation.

  1. Exécutez docker system df -v et enregistrez la sortie datée.
  2. Listez les conteneurs avec docker ps -a et identifiez ceux qui sont réellement obsolètes.
  3. Listez les images avec docker image ls et associez les tags importants aux projets actifs.
  4. Listez les volumes avec docker volume ls, puis vérifiez propriétaire et sauvegarde de chacun.
  5. Inspectez le cache de build avec docker builder du ou les commandes de votre builder actif.

L’absence de conteneur actif attaché à un volume ne prouve pas que ses données sont jetables. Les projets Compose et les bases arrêtées laissent souvent des volumes légitimes détachés.

Supprimer sélectivement conteneurs et images

Supprimez un conteneur arrêté connu avec docker container rm suivi de son nom ou identifiant. Sa couche inscriptible disparaît, mais les volumes nommés restent normalement présents sauf demande explicite contraire.

Supprimez une image inutilisée connue avec docker image rm. Si Docker indique qu’un conteneur la référence, inspectez ce conteneur plutôt que de forcer. Garder quelques images de base lourdes peut être rationnel si vous reconstruisez souvent.

Les commandes par catégorie limitent l’impact. docker container prune retire tous les conteneurs arrêtés après confirmation. docker image prune ne cible par défaut que les images dangling ; -a l’étend à toutes celles non référencées par un conteneur.

Élaguer le cache de build sans toucher aux volumes

BuildKit conserve des couches afin de réutiliser les étapes inchangées. Sur une machine de développement active, ce cache peut devenir la plus grosse catégorie récupérable tout en restant reproductible depuis les Dockerfiles et contextes.

Utilisez docker builder prune pour le builder par défaut ou docker buildx prune pour un builder géré par buildx. Examinez les options de votre version et gardez la demande de confirmation comme contrôle de sécurité.

La prochaine construction sera plus lente et devra retélécharger ou recréer les couches. Si le problème revient chaque semaine, améliorez .dockerignore, l’ordre des instructions du Dockerfile et le budget de cache plutôt que de purger systématiquement.

Comprendre docker system prune

docker system prune combine plusieurs nettoyages. Par défaut, Docker documente la suppression des conteneurs arrêtés, réseaux inutilisés, images dangling et cache de build inutilisé. N’exécutez cette combinaison qu’après audit de chaque catégorie.

La commande par défaut ne supprime pas les volumes. L’option --volumes ajoute les volumes anonymes, qui peuvent contenir de vraies données applicatives. Ne la copiez pas sans vérifier précisément le résumé de confirmation de votre version.

L’option -a étend la suppression à toutes les images inutilisées par des conteneurs. Même sans perte de données, le coût de téléchargement et de reconstruction peut être important ; ciblez les grandes images reconnues quand c’est possible.

  1. Terminez l’audit en lecture seule et sauvegardez tout volume important.
  2. Élaguez séparément le cache de build ou les conteneurs arrêtés si une catégorie explique le problème.
  3. N’exécutez docker system prune sans -a ni --volumes que si vous acceptez chaque catégorie annoncée.
  4. Relancez docker system df -v et vérifiez que les projets importants démarrent.
  5. Mesurez de nouveau l’espace libre macOS après que Docker Desktop a récupéré les blocs hôte.

Protéger volumes et bases de données

Les volumes sont conçus pour survivre aux conteneurs. Un volume PostgreSQL, MySQL ou d’un service de développement peut contenir l’unique copie locale des données, même si son conteneur est arrêté ou supprimé. Traitez-le comme un document jusqu’à connaître son propriétaire et sa sauvegarde.

Sauvegardez les données des volumes séparément. Préférez l’export natif de la base ou une procédure de sauvegarde testée ; copier un répertoire d’une base active ne produit pas automatiquement une sauvegarde cohérente.

Nommez les volumes dans les fichiers Compose et documentez projet, restauration et date d’expiration. Le prochain nettoyage devient alors une décision de conservation, pas une devinette.

Réduire, déplacer ou réinitialiser le stockage Docker

Si l’élagage ne suffit pas, gérez l’image disque dans Docker Desktop Settings. Les contrôles varient selon la version, mais cette interface est l’emplacement pris en charge pour modifier limite ou chemin.

Ne déplacez pas Docker.raw dans le Finder. Avant une réinitialisation d’usine, une désinstallation ou un changement destructif, exportez les images nécessaires ou vérifiez qu’elles sont récupérables, sauvegardez les volumes et conservez la configuration utile.

La restitution d’espace à macOS peut être différée selon le format et le comportement de Docker Desktop. Mesurez après la fin de l’élagage au lieu de supprimer immédiatement davantage de données.

Ce qu’AskClean fait — et ne fait pas

AskClean rend visible l’empreinte Mac de Docker, mais marque Docker.raw, données de group-container, identifiants, images et volumes comme gérés par le fournisseur ou jamais présélectionnés. Il ne les traite pas comme un cache d’application ordinaire.

Utilisez la CLI et Settings de Docker pour ses objets et son disque virtuel. Le flux sûr reste : repérer l’empreinte avec AskClean, diagnostiquer avec docker system df -v, puis élaguer exactement la catégorie Docker concernée.

Risque de nettoyage par catégorie Docker

Le disque virtuel contient à la fois des couches régénérables et des données persistantes.

CatégorieInspectionConséquence de suppression
Cache de builddocker system df -v / outils du builderSera reconstruit ou retéléchargé ; les volumes ne devraient pas être touchés.
Conteneur arrêtédocker ps -aSa couche inscriptible disparaît ; les volumes nommés restent normalement.
Image inutiliséedocker image lsDevra être retéléchargée ou reconstruite si elle redevient nécessaire.
Volumedocker volume lsDes données persistantes d’application ou de base peuvent être perdues définitivement.
Docker.rawDocker Desktop SettingsUne suppression manuelle peut effacer tous les objets et volumes locaux.

FAQ

Pourquoi Docker.raw est-il si volumineux ?

C’est le disque virtuel contenant images, conteneurs, caches et volumes Linux de Docker Desktop. Sa taille logique peut différer des blocs hôte utilisés ; vérifiez docker system df -v et Settings.

docker system prune est-il sans risque ?

Seulement si vous acceptez les catégories listées : par défaut conteneurs arrêtés, réseaux inutilisés, images dangling et cache de build. Évitez -a et --volumes avant d’en comprendre le coût et le risque.

docker system prune supprime-t-il les volumes ?

Pas par défaut. --volumes ajoute les volumes anonymes. Même inutilisé en apparence, un volume peut contenir une base importante : identifiez-le et sauvegardez-le d’abord.

Puis-je supprimer Docker.raw dans le Finder ?

Non. Une suppression ou un déplacement manuel peut effacer tout l’état Docker local ou casser Docker Desktop. Utilisez la CLI pour les objets et Settings pour l’image disque.

Sources

Poursuivre le nettoyage du stockage développeur