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

Pourquoi Docker paraît énorme sous macOS

Docker Desktop exécute les conteneurs Linux dans une machine virtuelle légère. Les images, les couches inscriptibles des conteneurs, le cache de build et les volumes sont stockés dans un gros fichier d’image disque — généralement nommé Docker.raw, selon la version et la configuration de Docker Desktop — 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 creux (sparse) peut réserver une grande plage logique tout en occupant moins de blocs physiques sur le Mac. Commencez par les mesures de Docker et l’espace libre de macOS, plutôt que de supposer que le plus gros chiffre affiché dans le Finder est immédiatement récupérable.

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 : la documentation de Docker pour Mac demande de changer son emplacement dans Settings.

Effectuer un audit en lecture seule

Démarrez Docker Desktop, ouvrez le Terminal et 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 la colonne RECLAIMABLE (récupérable) avec prudence. Une image peut être partagée par plusieurs conteneurs : supprimer un tag ne libère donc pas forcément toute la taille indiquée. Un volume peut sembler inutilisé parce qu’aucun conteneur n’y est rattaché, tout en contenant une base de données que vous comptez restaurer plus tard.

Ouvrez aussi Docker Desktop Settings > Resources et notez la limite d’utilisation du disque et l’emplacement de l’image disque proposés par votre version, avant de modifier quoi que ce soit. Si Docker ne démarre plus, sauvegardez son fichier de données selon la procédure de récupération de Docker avant toute réinitialisation ou réinstallation.

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 ou workflows de CI actuels.
4. Listez les volumes avec docker volume ls, puis vérifiez propriétaire et sauvegarde de chacun.
5. Examinez le cache de build en dernier, avec docker builder du ou les commandes prises en charge par 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 les conteneurs dont vous savez qu’ils sont obsolètes avec docker container rm suivi de leur nom ou identifiant. Leur couche inscriptible disparaît, mais les volumes nommés restent en place, sauf si vous demandez explicitement leur suppression.

Supprimez une image dont vous savez qu’elle est inutilisée avec docker image rm suivi de son tag ou identifiant. Si Docker indique qu’un conteneur la référence encore, examinez ce conteneur plutôt que de forcer la suppression. Garder quelques images de base volumineuses peut être raisonnable si vous reconstruisez souvent et que votre connexion est lente.

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 orphelines (dangling) ; -a l’étend à toutes les images qu’aucun conteneur n’utilise. Lisez le résumé de confirmation à chaque fois.

É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 prises en charge par votre version. Les deux commandes demandent une confirmation, sauf si vous ajoutez une option de forçage : gardez cette demande, c’est un garde-fou utile.

Le prochain build d’image sera plus lent et devra retélécharger ou recréer des couches. Si le problème revient chaque semaine, améliorez le Dockerfile et la politique de cache plutôt que de programmer des purges systématiques : installez les dépendances avant de copier le code qui change souvent, resserrez .dockerignore et donnez aux builders de CI persistants un budget de cache explicite.

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 orphelines (dangling) et cache de build inutilisé. N’exécutez cette combinaison qu’après avoir audité 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 l’ajoutez pas à la légère, et ne copiez pas une commande de nettoyage trouvée sur un forum sans vérifier ce que votre version de Docker annonce qu’elle supprimera.

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. Vérifiez l’espace libre de macOS après avoir laissé à Docker Desktop le temps de restituer l’espace au Mac.

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 les volumes comme des documents, et non comme du cache, tant que vous ne connaissez pas leur propriétaire et leur sauvegarde.

La documentation de Docker rappelle que les données des volumes doivent être sauvegardées 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 réglages disponibles varient selon la version, mais cette interface est l’endroit prévu pour modifier la limite d’utilisation du disque ou l’emplacement de l’image disque.

Ne faites pas glisser Docker.raw vers un autre disque dans le Finder : Docker demande explicitement de déplacer l’image disque via Settings. 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 de l’espace à macOS peut être différée selon le format de l’image disque et le comportement de Docker Desktop ; d’après la FAQ Mac de Docker, Docker.raw la restitue généralement bien plus vite que l’ancien format qcow2. Mesurez de nouveau une fois l’élagage terminé au lieu de supprimer immédiatement davantage de données.

Ce qu’AskClean fait — et ne fait pas

AskClean peut révéler le cache du lanceur de Docker Desktop et montrer où le stockage géré par Docker occupe de l’espace sur le Mac. Il marque délibérément Docker.raw, les données du group container de Docker, les identifiants, les images et les volumes comme gérés par Docker ou jamais présélectionnés, au lieu de les traiter comme un cache d’application ordinaire.

Utilisez la CLI et les réglages de Docker pour ses objets et son disque virtuel. Le rôle d’AskClean est de rendre visible cet espace caché côté Mac et d’empêcher qu’un nettoyage trop large n’atteigne les identifiants ou les données des volumes. La démarche sûre reste : repérer l’espace occupé 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.

FAQ