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

Docker sur Mac a rarement l’air enorme d’un coup. Il grossit par couches.

Au debut, c’est une image, un projet, un volume de base de donnees, un conteneur arrete, un cache de build que tu comptes nettoyer plus tard. Puis la machine se serre, Docker Desktop commence a paraitre suspect, et la conclusion habituelle est vague mais emotionnellement satisfaisante : “Docker me bouffe mon disque.”

Cette conclusion va dans la bonne direction, mais elle est trop imprcise pour etre utile. Le vrai probleme n’est generalement pas “Docker en general.” C’est l’accumulation entre images, couches, cache de build, conteneurs arretes, volumes et donnees de runtime que personne n’a examine comme un systeme.

Reponse rapide

Pourquoi Docker grossit silencieusement sur Mac

Docker est concu pour conserver un etat utile jusqu’a ce que tu lui dises explicitement le contraire. La documentation de Docker decrit le nettoyage comme conservateur : les images, conteneurs, volumes et reseaux inutilises ne sont generalement pas supprimes sauf si tu demandes a Docker de le faire.

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

Sur Mac, la situation est encore moins evidente car Docker Desktop stocke les conteneurs et images Linux dans un seul fichier d’image disque volumineux. Resultat : l’hote peut afficher une empreinte Docker importante alors que les vraies causes sont enfouies dans plusieurs couches de donnees de runtime.

Le schema de croissance est generalement une combinaison de :

• images tirees et reconstruites a travers plusieurs projets ;
• couches partagees reutilisees entre tags et versions ;
• conteneurs arretes qui gardent encore des couches inscriptibles ;
• volumes qui contiennent des bases de donnees, des fichiers uploade ou un etat de service local ;
• cache de build qui garde les builds rapides jusqu’a ce qu’il devienne couteux ;
• objets pendantes laisses apres des rebuilds et des retagages.

Le resultat est une empreinte qui s’etend silencieusement parce que chaque ajout individuel semble normal.

Ce qui prend reellement l’espace disque de Docker sur Mac

Si tu veux un plan de nettoyage utile, separe l’empreinte Docker en categories plutot que de la traiter comme une boite noire geante.

C’est pourquoi un flux generique “dossier le plus gros” est faible pour Docker. Le meme total peut signifier des decisions de nettoyage tres differentes selon que l’espace est surtout du cache de build ou surtout de vraies donnees de volume.

Images Docker et couches partagees

Les images sont souvent la premiere chose a laquelle les developpeurs pensent, mais l’histoire plus profonde concerne les couches. Une machine avec plusieurs runtimes de langage, des builds locaux facon CI et plusieurs microservices peut accumuler rapidement beaucoup de couches partagees et uniques.

C’est pourquoi l’utilisation disque ne correspond pas toujours proprement a la liste d’images dont tu te souviens avoir tirees.

Cache de build Docker

Le cache de build est l’une des causes cachees 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’a ce que tu le nettoies. Ca signifie aussi que le supprimer est generalement un compromis de performance, pas un gain gratuit.

Conteneurs Docker arretes

Les developpeurs 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 ou le risque augmente. Ils peuvent contenir les donnees qui t’importent vraiment : bases de donnees, miroirs de paquets, uploads, index de recherche, contenu de registre local ou etat de service.

C’est la difference 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 surs. La documentation de prune de Docker definit les images pendantes comme des images qui ne sont pas taguees et ne sont referencees par aucun conteneur. Ce sont exactement le type d’accumulation qui croit au fil de l’iteration normale.

Comment verifier 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 recuperable. C’est le moyen le plus rapide d’arreter de deviner.

Utilise cet ordre de revision :

1. Commence avec docker system df -v

C’est le meilleur resume initial car il affiche :

• l’utilisation totale et recuperable des images ;
• l’utilisation des conteneurs ;
• l’utilisation des volumes locaux ;
• une repartition plus detaillee avec le flag verbose.

Si l’espace recuperable est faible, un nettoyage large n’aidera probablement pas beaucoup.

2. Examine les conteneurs arretes avant de faire un prune

Verifie s’il y a beaucoup de conteneurs sortis dont plus personne n’a besoin. Ce sont souvent des candidats de nettoyage plus surs que les volumes ou l’etat de runtime actif.

3. Examine les images separement du cache de build

Les images et le cache de build resolvent des problemes differents. Si le cache est le principal responsable, un nettoyage axe sur le cache est generalement preferable a une reinitialisation large de tout ce que Docker possede.

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

C’est l’etape que les gens sautent et regrettent. Un volume peut sembler detache d’un conteneur en cours d’execution mais representer encore de vraies donnees 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 plutot que la taille reellement consommee. Ca compte parce qu’un chiffre effrayant cote hote ne correspond pas toujours a du gaspillage immediatement recuperable.

Avant de faire un prune

Commandes rapides de revision 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 reellement recuperable avant de choisir une portee de prune.

Pourquoi supprimer les dossiers Docker directement est risqué

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

Il y a deux raisons.

Premierement, Docker suit l’etat du runtime et les metadonnees. Quand tu supprimes des fichiers geres 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 reellement sur le disque.

Deuxiemement, sur Mac l’empreinte Docker est liee a l’image disque geree par Docker Desktop et au stockage de runtime. La documentation Docker pour Mac avertit explicitement de ne pas deplacer l’image disque directement dans Finder car Docker Desktop peut la perdre de vue. La meme lecon generale s’applique a la suppression forcee dans le stockage gere par Docker : les actions Docker-aware sont plus sres que les suppositions sur le systeme de fichiers.

C’est aussi pourquoi supprimer des fichiers dans un conteneur en cours d’execution n’est pas la meme chose que de recuperer de l’espace disque hote. La documentation Docker pour Mac note que l’espace hote est recupere quand les images sont supprimees, pas automatiquement quand des fichiers disparaissent dans des conteneurs en cours d’execution.

Quand prune est utile

prune est utile quand tu comprends deja l’empreinte et que tu veux que Docker supprime les objets qu’il considere inutilises.

Les principaux cas ou c’est utile sont directs :

• docker system prune quand les conteneurs arretes, reseaux inutilises, images pendantes et cache de build inutilise se sont accumules ;
• docker builder prune quand le cache de build est le vrai probleme ;
• docker volume prune quand tu as verifie que les volumes inutilises sont vraiment jetables ;
• nettoyage filtre par le temps ou par label quand tu veux reduire la portee 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 “inutilise” dans Docker peut toujours signifier “important pour mon flux de travail.”

Sois prudent quand :

• un conteneur arrete fait partie d’un environnement local que tu comptes reprendre ;
• le prochain build a besoin du cache que tu t’appretes a effacer ;
• les volumes locaux contiennent des donnees de base de donnees 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’appretes a ajouter le nettoyage des volumes sans avoir d’abord confirme ce que ces volumes representent.

La documentation Docker est explicite : les volumes ne sont pas supprimes automatiquement car cela pourrait detruire des donnees. C’est le bon modele mental pour le nettoyage des volumes en general : les volumes meritent plus de suspicion que les images ou le cache pendante.

Comment comprendre les consequences avant le nettoyage

Avant de nettoyer quoi que ce soit, reponds a la question des consquences en termes simples :

Que devrai-je reconstruire, retirer, restaurer ou recrer apres ca?

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

Pour Docker, la revision pratique ressemble generalement a ca :

1. L’empreinte principale est-elle composee d’images, de cache de build, de conteneurs arretes ou de volumes?
2. Des conteneurs en cours d’execution font-ils partie du plan, ou le nettoyage necessite-t-il de les arreter 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 etat de service ou donnees disparaitront avec eux?
5. Est-ce que j’utilise le nettoyage Docker pour resoudre un vrai probleme d’espace recuperable, ou est-ce que je reagis a une seule image disque opaque?

C’est la difference entre un nettoyage developpeur controle et une panique de stockage aleatoire.

Pourquoi le nettoyage dev est different du nettoyage de fichiers ordinaire

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

Le nettoyage Docker a besoin de questions differentes :

• est-ce du cache reconstructible ou des donnees de service persistantes ;
• le runtime le signale-t-il comme recuperable ;
• le nettoyage devrait-il passer par des commandes Docker plutot que par suppression sur le systeme de fichiers ;
• les conteneurs en cours d’execution, les conteneurs arretes ou les volumes font-ils partie du modele de consequences ;
• ai-je besoin d’une revision guidee avant d’appliquer un chemin de nettoyage risqué?

C’est pourquoi Docker appartient a un flux container-aware, pas au meme panier mental que supprimer des telechargements ou vider un dossier de cache generique.

Ou StorageRadar intervient

Ca compte parce que Docker n’est pas juste “un gros dossier.” C’est un ecosysteme de types d’objets avec des consequences de nettoyage differentes.

Si le cache de build est le probleme, ton action est differente de celle pour une machine chargee en volumes. Si les conteneurs en cours d’execution doivent etre arretes d’abord, ca devrait etre visible avant le nettoyage. Si le profil est risqué, le flux devrait te ralentir expres.

Ce qu’il ne faut pas faire

Evite ces erreurs courantes :

• ne traite pas chaque empreinte Docker importante comme un seul probleme avec une seule commande ;
• ne lance pas de rm -rf direct dans des repertoires geres par Docker parce que les chemins paraissent gros ;
• ne suppose pas qu’une grande image disque Docker Desktop signifie que tout cet espace est securment recuperable maintenant ;
• n’ajoute pas le nettoyage des volumes a la legere si tu n’as pas verifie ce que ces volumes contiennent ;
• n’utilise pas un prune large juste avant une demo, une release ou un rebuild d’environnement local que tu ne peux pas te permettre.

Si Docker n’est qu’une partie d’un probleme 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 generalement pas mysterieuse 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 arretes, les volumes, les objets pendantes et le stockage de runtime Docker Desktop.

Le bon geste est d’inspecter l’empreinte d’abord, de separer les artefacts reconstructibles des donnees persistantes, et d’utiliser un nettoyage Docker-aware seulement apres avoir compris les consequences.