Utilisation disque de Docker sur Mac : ce qui consomme vraiment l'espace

Docker sur Mac à rarement l’air énorme d’un coup. Il grossit par couches.

Au début, c’est une image, un projet, un volume de base de données, un conteneur arrête, un cache de build que tu comptes nettoyer plus tard. Puis la machine se serré, Docker Desktop commence à paraître suspect, et la conclusion habituelle est vague mais émotionnellement satisfaisante : “Docker me bouffe mon disque.”

Cette conclusion va dans la bonne direction, mais elle est trop imprécise pour être utile. Le vrai problème n’est généralement pas “Docker en général.” C’est l’accumulation entre images, couches, cache de build, conteneurs arrêtés, volumes et données de runtime que personne n’a examiné comme un système.

Réponse rapide

Pourquoi Docker grossit silencieusement sur Mac

Docker est conçu pour conserver un état utile jusqu’à ce que tu lui dises explicitement le contraire. La documentation de Docker décrit le nettoyage comme conservateur : les images, conteneurs, volumes et réseaux inutilisés ne sont généralement pas supprimes sauf si tu demandes à Docker de le faire.

C’est pratique pour les flux développeur, et c’est exactement pourquoi l’utilisation disque augmente progressivement.

Sur Mac, la situation est encore moins évidente car Docker Desktop stocke les conteneurs et images Linux dans un seul fichier d’image disque volumineux. Résultat : l’hôte peut afficher une empreinte Docker importante alors que les vraies causes sont enfouies dans plusieurs couches de données de runtime.

Le schéma de croissance est généralement une combinaison de :

• images tirées et reconstruites à travers plusieurs projets ;
• couches partagées réutilisées entre tags et versions ;
• conteneurs arrêtés qui gardent encore des couches inscriptibles ;
• volumes qui contiennent des bases de données, des fichiers téléversés ou un état de service local ;
• cache de build qui garde les builds rapides jusqu’à ce qu’il devienne coûteux ;
• objets pendantes laissés après des reconstructions et des re-tags.

Le résultat est une empreinte qui s’étend silencieusement parce que chaque ajout individuel semble normal.

Où Docker stocke-t-il ses données sur Mac ?

Sur Mac, Docker n’éparpille pas ses fichiers sur le disque comme le ferait une app native. Docker Desktop exécute Linux dans une machine virtuelle et range presque tout (images, conteneurs et volumes) dans un seul gros fichier d’image disque.

Par défaut, ce fichier se trouve à peu près ici :

~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw

Le chemin exact peut changer d’une version de Docker Desktop à l’autre, mais l’idée reste la même : un fichier géré porte toute l’empreinte côté Linux. C’est pourquoi un seul Docker.raw peut apparaître dans le Finder comme des dizaines de gigaoctets alors qu’une bonne partie de cet espace est récupérable, ou n’est que la taille maximale que l’image disque a le droit d’atteindre.

Deux conséquences découlent de cette conception :

• La taille affichée dans le Finder induit en erreur. Les outils de l’hôte rapportent souvent la taille maximale de l’image disque, pas l’espace que Docker occupe réellement à l’intérieur.
• Ne touche pas Docker.raw directement. La documentation Mac de Docker déconseille de déplacer ou de supprimer l’image disque dans le Finder, parce que Docker Desktop peut en perdre la trace. L’espace se récupère via Docker, pas via le système de fichiers.

Ce qui prend réellement l’espace disque de Docker sur Mac

Si tu veux un plan de nettoyage utile, sépare l’empreinte Docker en catégories plutôt que de la traiter comme une boîte noire géante.

C’est pourquoi un flux générique “dossier le plus gros” est faible pour Docker. Le même total peut signifier des décisions de nettoyage très différentes selon que l’espace est surtout du cache de build ou surtout de vraies données de volume.

Images Docker et couches partagées

Les images sont souvent la première chose à laquelle les développeurs pensent, mais l’histoire plus profonde concerne les couches. Une machine avec plusieurs runtimes de langage, des builds locaux façon CI et plusieurs microservices peut accumuler rapidement beaucoup de couches partagées et uniques.

C’est pourquoi l’utilisation disque ne correspond pas toujours proprement à la liste d’images dont tu te souviens avoir tirées.

Cache de build Docker

Le cache de build est l’une des causes cachées les plus courantes sur les machines de dev actives. Il existe pour rendre les builds futurs plus rapides, ce qui signifie qu’il reste jusqu’à ce que tu le nettoies. Ça signifie aussi que le supprimer est généralement un compromis de performance, pas un gain gratuit.

Conteneurs Docker arrêtés

Les développeurs sous-estiment constamment celui-ci. Un conteneur qui ne tourne pas est encore un objet de stockage. S’il existe encore, il peut encore prendre de l’espace disque.

Volumes Docker

Les volumes sont l’endroit où le risque augmente. Ils peuvent contenir les données qui t’importent vraiment : bases de données, miroirs de paquets, uploads, index de recherche, contenu de registre local ou état de service.

C’est la différence entre le nettoyage Docker et le nettoyage de cache ordinaire. Une partie du stockage Docker est reconstructible. Une partie constitue ton environnement.

Images et objets Docker pendantes

Les objets pendantes sont souvent les candidats de nettoyage les plus sûrs. La documentation de prune de Docker définit les images pendantes comme des images qui ne sont pas taguées et ne sont référencées par aucun conteneur. Ce sont exactement le type d’accumulation qui croit au fil de l’itération normale.

Comment vérifier l’utilisation disque de Docker sur Mac

Le meilleur premier pas n’est pas Finder. C’est une vue Docker de ce que le daemon pense consommer de l’espace.

La recommandation de Docker sur Mac commence par docker system df -v, qui affiche l’utilisation des images, conteneurs, volumes locaux et espace récupérable. C’est le moyen le plus rapide d’arrêter de deviner.

Utilise cet ordre de révision :

1. Commence avec docker system df -v

C’est le meilleur résumé initial car il affiche :

• l’utilisation totale et récupérable des images ;
• l’utilisation des conteneurs ;
• l’utilisation des volumes locaux ;
• une répartition plus détaillée avec le flag verbose.

Si l’espace récupérable est faible, un nettoyage large n’aidera probablement pas beaucoup.

2. Examine les conteneurs arrêtés avant de faire un prune

Vérifie s’il y a beaucoup de conteneurs sortis dont plus personne n’a besoin. Ce sont souvent des candidats de nettoyage plus sûrs que les volumes ou l’état de runtime actif.

3. Examine les images séparément du cache de build

Les images et le cache de build résolvent des problèmes différents. Si le cache est le principal responsable, un nettoyage axé sur le cache est généralement préférable à une réinitialisation large de tout ce que Docker possède.

4. Examine les volumes avant toute commande utilisant --volumes

C’est l’étape que les gens sautent et regrettent. Un volume peut sembler détaché d’un conteneur en cours d’exécution mais représenter encore de vraies données locales pour un projet que tu comptes relancer demain.

5. Examine l’image disque Mac de Docker Desktop

La FAQ Docker pour Mac note que Docker Desktop stocke les conteneurs et images Linux dans un seul fichier d’image disque et que certains outils affichent la taille maximale du fichier plutôt que la taille réellement consommée. Ça compte parce qu’un chiffre effrayant cote hôte ne correspond pas toujours à du gaspillage immédiatement récupérable.

Avant de faire un prune

Commandes rapides de révision Docker

Ces commandes d’inspection sont utiles avant de supprimer quoi que ce soit :

docker system df -v
docker ps -a --size
docker images --format 'table {{.Repository}}\t{{.Tag}}\t{{.Size}}'
docker volume ls

Utilise-les pour confirmer ce qui est réellement récupérable avant de choisir une portée de prune.

Comment libérer de l’espace disque Docker sur Mac

Une fois que docker system df -v montre ce qui est vraiment récupérable, libère de l’espace avec la portée la plus étroite qui règle le problème, plutôt qu’avec un grand balayage :

# supprimer les conteneurs arrêtés
docker container prune

# supprimer le cache de build (BuildKit)
docker builder prune

# supprimer les images pendantes (sans tag)
docker image prune

# supprimer les volumes inutilisés - seulement après avoir vérifié qu'ils ne portent rien d'utile
docker volume prune

Si tu veux que Docker nettoie plusieurs types d’objets d’un coup, docker system prune prend en charge les conteneurs arrêtés, les réseaux inutilisés, les images pendantes et le cache de build inutilisé en une étape. Ajoute -a pour retirer aussi les images qu’aucun conteneur n’utilise, et --volumes uniquement quand tu es certain qu’aucun volume ne porte de vraies données.

Tu peux aussi récupérer de l’espace depuis Docker Desktop : ouvre Settings → Resources pour ajuster ou réduire la taille du disque virtuel, ou utilise Troubleshoot → Clean / Purge data pour une remise à zéro plus lourde. Les deux restent dans le flux de Docker, ce qui est plus sûr que de toucher Docker.raw à la main.

Le compromis est toujours le même : élaguer le cache et les images te coûte des builds plus lents et de nouveaux téléchargements, pas ton code source, tandis qu’élaguer les volumes peut supprimer de vraies données locales, donc traite cette portée avec le plus de prudence.

Pourquoi supprimer les dossiers Docker directement est risqué

La suppression directe semble attrayante parce qu’elle a l’air décisive. C’est aussi comment tu transformes le nettoyage Docker en roulette de nettoyage de runtime.

Il y a deux raisons.

Premièrement, Docker suit l’état du runtime et les métadonnées. Quand tu supprimes des fichiers gérés par Docker en dehors du flux de Docker, tu risques de briser la relation entre ce que le runtime croit exister et ce qui est réellement sur le disque.

Deuxièmement, sur Mac l’empreinte Docker est liée à l’image disque gérée par Docker Desktop et au stockage de runtime. La documentation Docker pour Mac avertit explicitement de ne pas déplacer l’image disque directement dans Finder car Docker Desktop peut la perdre de vue. La même leçon générale s’applique à la suppression forcée dans le stockage géré par Docker : les actions Docker-aware sont plus sûres que les suppositions sur le système de fichiers.

C’est aussi pourquoi supprimer des fichiers dans un conteneur en cours d’exécution n’est pas la même chose que de récupérer de l’espace disque hôte. La documentation Docker pour Mac note que l’espace hôte est récupère quand les images sont supprimées, pas automatiquement quand des fichiers disparaissent dans des conteneurs en cours d’exécution.

Quand prune est utile

prune est utile quand tu comprends déjà l’empreinte et que tu veux que Docker supprime les objets qu’il considère inutilisés.

Les principaux cas où c’est utile sont directs :

• docker system prune quand les conteneurs arrêtés, réseaux inutilisés, images pendantes et cache de build inutilisé se sont accumulés ;
• docker builder prune quand le cache de build est le vrai problème ;
• docker volume prune quand tu as vérifie que les volumes inutilisés sont vraiment jetables ;
• nettoyage filtre par le temps ou par label quand tu veux réduire la portée au lieu de tout balayer.

C’est ici que le nettoyage Docker-aware est clairement meilleur que la suppression brute de fichiers. Le runtime comprend les types d’objets. Finder, non.

Quand docker system prune est dangereux

Le danger n’est pas que prune soit mauvais. Le danger est que “inutilisé” dans Docker peut toujours signifier “important pour mon flux de travail.”

Sois prudent quand :

• un conteneur arrête fait partie d’un environnement local que tu comptes reprendre ;
• le prochain build à besoin du cache que tu t’apprêtes à effacer ;
• les volumes locaux contiennent des données de base de données ou de service qui t’importent encore ;
• docker system prune -a supprimerait des images qui ne tournent pas maintenant mais font encore partie d’un travail actif ;
• tu t’apprêtes à ajouter le nettoyage des volumes sans avoir d’abord confirme ce que ces volumes représentent.

La documentation Docker est explicite : les volumes ne sont pas supprimés automatiquement car cela pourrait détruire des données. C’est le bon modèle mental pour le nettoyage des volumes en général : les volumes méritent plus de suspicion que les images ou le cache pendante.

Comment comprendre les conséquences avant le nettoyage

Avant de nettoyer quoi que ce soit, réponds à la question des conséquences en termes simples :

Que devrai-je reconstruire, retirer, restaurer ou recréer après ça?

Cette question est plus utile que “Combien puis-je supprimer?”

Pour Docker, la révision pratique ressemble généralement à ça :

1. L’empreinte principale est-elle composée d’images, de cache de build, de conteneurs arrêtés ou de volumes?
2. Des conteneurs en cours d’exécution font-ils partie du plan, ou le nettoyage nécessite-t-il de les arrêter d’abord?
3. Si je fais un prune du cache, est-ce que j’accepte des builds ou pulls plus lents ensuite?
4. Si je fais un prune des volumes, quel état de service ou données disparaîtront avec eux?
5. Est-ce que j’utilise le nettoyage Docker pour résoudre un vrai problème d’espace récupérable, ou est-ce que je réagis à une seule image disque opaque?

C’est la différence entre un nettoyage développeur contrôle et une panique de stockage aléatoire.

Pourquoi le nettoyage dev est différent du nettoyage de fichiers ordinaire

Le nettoyage de fichiers ordinaire demande “Quel dossier est gros?”

Le nettoyage Docker à besoin de questions différentes :

• est-ce du cache reconstructible ou des données de service persistantes ;
• le runtime le signale-t-il comme récupérable ;
• le nettoyage devrait-il passer par des commandes Docker plutôt que par suppression sur le système de fichiers ;
• les conteneurs en cours d’exécution, les conteneurs arrêtés ou les volumes font-ils partie du modèle de conséquences ;
• ai-je besoin d’une révision guidée avant d’appliquer un chemin de nettoyage risqué?

C’est pourquoi Docker appartient à un flux container-aware, pas au même panier mental que supprimer des téléchargements ou vider un dossier de cache générique.

Ou StorageRadar intervient

Ça compte parce que Docker n’est pas juste “un gros dossier.” C’est un écosystème de types d’objets avec des conséquences de nettoyage différentes.

Si le cache de build est le problème, ton action est différente de celle pour une machine chargée en volumes. Si les conteneurs en cours d’exécution doivent être arrêtés d’abord, ça devrait être visible avant le nettoyage. Si le profil est risqué, le flux devrait te ralentir exprès.

Ce qu’il ne faut pas faire

Évite ces erreurs courantes :

• ne traite pas chaque empreinte Docker importante comme un seul problème avec une seule commande ;
• ne lance pas de rm -rf direct dans des répertoires gérés par Docker parce que les chemins paraissent gros ;
• ne suppose pas qu’une grande image disque Docker Desktop signifie que tout cet espace est récupérable sans risque maintenant ;
• n’ajoute pas le nettoyage des volumes à la légère si tu n’as pas vérifie ce que ces volumes contiennent ;
• n’utilise pas un prune large juste avant une démo, une release ou un rebuild d’environnement local que tu ne peux pas te permettre.

Si Docker n’est qu’une partie d’un problème plus large de machine de dev, le guide compagnon sur Xcode DerivedData qui prend trop de place sur Mac est une bonne lecture suivante.

Conclusion

L’utilisation disque de Docker sur Mac n’est généralement pas mystérieuse une fois que tu la divises dans les bons compartiments. Les plus grands contributeurs sont typiquement les images, les couches, le cache de build, les conteneurs arrêtés, les volumes, les objets pendantes et le stockage de runtime Docker Desktop.

Le bon geste est d’inspecter l’empreinte d’abord, de séparer les artefacts reconstructibles des données persistantes, et d’utiliser un nettoyage Docker-aware seulement après avoir compris les conséquences.