Espace disque Docker et WSL sous Windows
Docker annonce une forte réduction après un nettoyage, mais C: ne gagne pas tout de suite le même espace. Identifiez la couche qui est mesurée. Les ressources Docker vivent dans son environnement ; un système de fichiers Linux peut vivre dans un disque virtuel ; Windows voit ce disque comme un fichier. L’espace réutilisable à l’intérieur de l’environnement diffère de la capacité libérée sur l’hôte.
Identifier d’abord l’environnement
Inspectez le contexte Docker actuel et l’inventaire du stockage. Ces commandes lisent des informations sans supprimer de ressources.
docker context show
docker system df -v
docker ps -a
docker volume ls
wsl --list --verbose
Une connexion Docker distante rapporte des ressources distantes plutôt que l’usage local de C:. Vérifiez aussi si DOCKER_HOST ou DOCKER_CONTEXT est défini ; des variables d’environnement peuvent remplacer la cible de connexion, comme le décrit la documentation des contextes. La liste WSL identifie les distributions locales et leurs versions. La documentation du backend WSL de Docker explique que l’organisation des données dépend de l’historique d’installation ; ne supposez pas que chaque PC a la même répartition des données Docker.
Les couches d’image partagées changent le calcul
La référence d’usage disque de Docker sépare les tailles d’image partagées et uniques. Les images peuvent réutiliser des couches, donc en retirer une ne libère pas forcément son total affiché. Récupérable décrit des candidats selon les relations de référence actuelles, pas une garantie que leur contenu est indésirable.
| Ressource | Contenu typique | À vérifier avant le retrait |
|---|---|---|
| Images | Couches d’exécution et d’application | Peuvent-elles être tirées ou reconstruites, et d’autres conteneurs les utilisent-ils ? |
| Conteneurs | Instances et couches inscriptibles | Un conteneur arrêté contient-il un contenu non exporté ? |
| Cache de build | Résultats de build réutilisables | Le prochain build peut-il télécharger et recalculer ce dont il a besoin ? |
| Volumes | Bases de données persistantes ou fichiers envoyés | Quel projet les possède, et la récupération est-elle vérifiée ? |
Dans un exemple hypothétique, deux images de 2 Go partagent 1,5 Go. En retirer une n’implique pas un gain de 2 Go. Un volume sans référence de conteneur actuelle peut encore contenir la base de données que vous venez d’arrêter.
Cibler le cache de build quand c’est le problème
Vérifiez que les sources, les sources de dépendances et la configuration de build restent disponibles. Si vous acceptez de reconstruire les résultats en cache, la commande builder prune de Docker cible le cache de build. La commande suivante supprime le cache éligible : lisez son invite avant d’accepter, et gardez la confirmation interactive activée.
docker builder prune
Son périmètre est plus étroit que docker system prune, qui cible aussi les conteneurs arrêtés, certaines images et des réseaux. Les options supplémentaires de system prune élargissent encore le retrait. Évitez une commande universelle pour chaque projet. Avec plusieurs builders, identifiez celui qui est sélectionné ; nettoyer un environnement ne prouve pas que les autres ont été traités.
Sauvegarder les données persistantes à part
Exportez les bases de données avec leurs propres outils et vérifiez la restauration dans un environnement isolé. Le guide de sauvegarde de Docker sépare les données d’images et de volumes. Enregistrer ou committer une image n’inclut pas les fichiers des volumes attachés. Un fichier Compose décrit une configuration plutôt qu’il ne contient le contenu de la base.
Pour une sauvegarde complète du disque virtuel de Docker Desktop, suivez la procédure d’arrêt documentée, identifiez le backend et l’emplacement des données configuré, puis copiez le bon fichier. Un VHDX en cours de modification n’est pas une sauvegarde stable. Sauvegardez les distributions WSL personnelles à part avec les indications d’export WSL. Désinscrire une distribution retire ses données ; ce n’est pas une étape courante de libération d’espace.
Comparer les couches Linux et Windows
Dans votre propre distribution, df -h / rapporte l’usage du système de fichiers racine, tandis que du -h --max-depth=1 /home aide à localiser la croissance des dossiers utilisateur. La seconde commande n’est pas un total de tout le système, et les droits et d’autres dossiers limitent sa couverture. Commencez par un grand dossier connu plutôt que de parcourir chaque lecteur monté.
Le guide de stockage WSL de Microsoft explique la croissance dynamique des VHD. Le plafond de capacité de Linux n’est pas l’usage alloué de Windows. Une suppression peut augmenter l’espace réutilisable interne sans rétrécir tout de suite le fichier extérieur. Pour une récupération côté hôte, vérifiez les versions actuelles de WSL et de Docker et les procédures prises en charge. Évitez de supprimer ou de déplacer les disques virtuels d’AppData, et ne confondez pas l’augmentation d’une limite de capacité avec la libération de C:. Pour récupérer le fichier hôte, libérez d’abord de l’espace dans la distribution, puis compactez le disque virtuel en suivant le guide d’espace disque WSL de Microsoft et les paramètres d’image disque de Docker Desktop ; la commande exacte dépend de la version de WSL et du backend Docker, donc utilisez les étapes propres à la version au lieu de copier une seule commande.
Après le nettoyage, répétez docker system df -v, lancez les services que vous conservez, inspectez les enregistrements de base et terminez le build d’origine. Vérifiez séparément les lectures Docker, Linux et Windows. La page Analyser de Mole peut localiser les gros fichiers ; la gestion des ressources et des disques virtuels appartient aux outils propriétaires. Voir le guide des caches de développement pour les caches de paquets ordinaires.