Où se cachent vraiment les gigaoctets
Docker Desktop sous WSL2 range tout — images, conteneurs, volumes, cache de build — dans des distributions WSL spéciales, chacune stockée sur C: sous forme d'un unique fichier VHDX dynamique. Chaque pull ajoute des couches, chaque build ajoute du cache, et supprimer ne libère de l'espace qu'à l'intérieur du système de fichiers Linux : le fichier hôte reste à son niveau record. Vos propres Ubuntu ou Debian font le même numéro avec leur ext4.vhdx, et rien de tout ça n'apparaît en chassant les « gros dossiers », puisque pour Windows ce ne sont que quelques fichiers opaques.
- docker-desktop-data (anciens Docker) ou docker_data.vhdx (récents) : le principal dévoreur de 30–80 Go dans %LOCALAPPDATA%\Docker\wsl — images, conteneurs, volumes, cache
- docker-desktop : la distribution système, plus petite, où tourne le moteur Docker lui-même
- Vos distributions WSL2 : un ext4.vhdx chacune sous %LOCALAPPDATA%\Packages\...\LocalState
- Cache de build : docker builder garde les couches intermédiaires même après la suppression de l'image finale
- Images fantômes et conteneurs arrêtés : couches orphelines de builds et de pulls interrompus
- Volumes anonymes : créés en silence à chaque build compose, ils survivent même à docker image prune
Nettoyez d'abord dedans : compacter un disque sale, c'est du travail perdu
Compacter un VHDX bourré d'images mortes ne donne qu'un fichier plus petit qui regonfle aussitôt : l'ordre des opérations décide de tout. Commencez dedans : docker system df montre ce qu'occupent réellement images, conteneurs, volumes et cache, et les chiffres surprennent souvent. docker system prune -a supprime images inutilisées et conteneurs arrêtés ; --volumes ajoute les volumes orphelins — vérifiez de ne pas effacer des données que vous vouliez garder. Ensuite docker builder prune purge le cache de build que les reconstructions répétées enflent ; seulement quand docker system df affiche un chiffre acceptable, le fichier hôte mérite qu'on s'y attaque.
Puis compacter le disque : trois voies officielles
D'abord wsl --shutdown, sinon le fichier reste verrouillé par les conteneurs et distributions en marche. Sur les builds WSL récents, wsl --manage <distro> --set-sparse true marque le VHDX comme sparse et Windows récupère les blocs libres ; sur les anciennes versions, la voie fiable est l'export-import — wsl --export vers un .tar, wsl --unregister, wsl --import dans un dossier neuf — et le fichier est reconstruit à la taille réelle des données. Docker Desktop sait aussi déménager l'image disque entière sur un autre lecteur — Settings > Resources > Advanced — et migre les données pour vous ; c'est la solution honnête quand C: est simplement trop petit pour votre travail. Et limitez la croissance pendant que vous y êtes : la même page propose une taille de disque maximale, et le réflexe mensuel de consulter docker system df vous garde en dessous.
Questions et réponses
Pourquoi Docker Desktop prend-il autant de place ?
Docker stocke chaque image, couche, volume et entrée de cache dans un VHDX dynamique qui grossit à la demande et ne rétrécit jamais seul. Regardez la répartition avec docker system df, nettoyez l'inutile, puis compactez le disque.
Comment réduire le fichier VHDX de Docker sous WSL2 ?
Lancez d'abord wsl --shutdown, puis marquez le disque sparse avec wsl --manage <distro> --set-sparse true. Ou exportez la distribution en .tar, unregister puis réimportez-la : le VHDX neuf collera à la taille réelle de vos données.
Vérifiez le contenu avant l'achat.
L'essai unique de 30 minutes couvre les fonctions de base. Les fonctions marquées PRO restent verrouillées jusqu'à l'activation d'une licence payante.
À lire ensuite
Écrivez-nous: [email protected]