Docker auf dem Mac aufräumen, ohne Daten zu verlieren

Docker Desktop kann Dutzende Gigabyte belegen, weil Images, beschreibbare Container-Schichten, Build-Cache und Volumes in einer Linux-Virtualdisk liegen. Diese Kategorien sind nicht gleichermaßen verzichtbar. Build-Cache ist meist reproduzierbar; ein Datenbank-Volume kann die einzige Kopie wichtiger Daten sein. Sicheres Aufräumen beginnt mit dem Docker-Inventar, nicht mit dem breitesten Prune-Befehl.

Warum Docker-Speicherplatz nicht zurückkommt

Docker Desktop unter macOS betreibt eine Linux-VM und speichert seine Daten in der Regel in einer Sparse-Virtualdisk namens Docker.raw. Der Mac-Speicherleitfaden von Docker verweist auf Docker Desktop > Settings > Resources > Advanced für Speicherort, Disk-Limit und den tatsächlich belegten Platz. Verschieben Sie die Datei mit dieser Einstellung, nicht mit dem Finder. Eine Sparse-Datei hat eine maximale logische Größe und eine kleinere physische Belegung; ls -lh allein kann sie daher deutlich größer erscheinen lassen, als sie aktuell belegt.

Sehen Sie nach, was Docker selbst als belegt meldet:

docker system df -v

Die Detailansicht gliedert Images, Container, lokale Volumes und Build-Cache. „Reclaimable“ bedeutet, dass Docker keinen aktuellen Verweis kennt, der das Objekt braucht; es beweist nicht, dass Sie einen gestoppten Container, ein altes Image oder ein Volume morgen nicht brauchen. Prüfen Sie vor dem Prunen auch docker ps -a und docker volume ls.

Mit gezieltem Aufräumen beginnen

Geben Sie Speicher immer von innen in Docker frei, nicht indem Sie die Virtualdisk-Datei löschen. Beginnen Sie mit der Kategorie, die Sie verstehen:

docker builder prune --filter until=168h
docker image prune
docker container prune

Der erste Befehl entfernt Build-Cache älter als sieben Tage; passen Sie das Alter an Ihre Arbeit an. Die beiden nächsten fragen nach, bevor hängende (dangling) Images und gestoppte Container entfernt werden. Führen Sie nach jedem Schritt erneut docker system df -v aus, damit Sie sehen, welche Aktion etwas gebracht hat.

Der Pruning-Leitfaden von Docker beschreibt docker system prune als breiteren Komfortbefehl. Mit -a werden alle ungenutzten Images entfernt, nicht nur hängende Schichten. Mit --volumes erweitert sich der Vorgang auf ungenutzte anonyme Volumes, die Datenbankdateien oder anderen Zustand enthalten können. Machen Sie aus docker system prune -a --volumes keinen Standard-Aufräumbefehl. Prüfen Sie vor jedem Volume-Prune Namen und Zugehörigkeit:

docker volume ls
docker volume inspect <volume-name>

Von Compose erzeugte Volumes tragen in der Regel Projekt- und Service-Labels. Identifizieren Sie das zugehörige Projekt und exportieren oder sichern Sie Daten, die sich nicht neu erzeugen lassen, bevor Sie das Volume entfernen.

Die Disk-Image selbst freigeben

Nach einem Prune existieren freie Blöcke im Linux-Dateisystem, bevor macOS sie unbedingt von der Sparse-Disk zurückerhält. Die aktuelle Docker-Dokumentation sagt, dass ein Docker.raw-Image freigabefähigen Host-Speicher normalerweise innerhalb von Sekunden zurückgibt; ältere Docker.qcow2-Images nutzen einen Hintergrundprozess, der Minuten dauern kann. Messen Sie den tatsächlichen Festplattenverbrauch erneut, statt die logische Maximalgröße der Datei zu beurteilen. Ein Factory Reset ist keine Verdichtung: er zerstört lokale Container, Images, Volumes und Einstellungen. Nutzen Sie ihn nur, wenn dieser vollständige Verlust beabsichtigt ist und wichtige Volume-Daten exportiert wurden.

Unter der Haube: warum die Datei wächst und nicht schrumpft

Docker Desktop betreibt eine Linux-VM, und Docker.raw ist die Virtualdisk dieser VM: eine Sparse-Datei, die wächst, wenn der Gast schreibt, aber Speicher nicht automatisch an macOS zurückgibt, wenn der Gast löscht. Das Entfernen eines Images markiert Blöcke im Dateisystem der VM als frei, aber die Host-Datei schrumpft nur, wenn der Gast TRIM/discard ausgibt und Docker Desktop discard und Verdichtung nutzen kann, um freigabefähige Blöcke zurückzugeben. Der Zeitpunkt hängt von Version und Disk-Image-Implementierung ab. Deshalb müssen logisches Aufräumen und die Änderung der Host-Kapazität getrennt gemessen werden – und warum das Löschen der Host-Datei dem Zerstören der gesamten Docker-Umgebung entspricht.

Wo eine Festplattenkarte hilft

Eine Festplattenkarte wie die Analyze-Ansicht von Mole kann die Virtualdisk und ihren physischen Fußabdruck zeigen. Welches interne Objekt referenziert ist, muss Dockers eigene CLI entscheiden. Die beiden Sichten beantworten verschiedene Fragen: macOS zeigt, wo Kapazität belegt ist; Docker erklärt, was diese Belegung enthält.

Eine sichere Reihenfolge

Führen Sie docker system df -v aus, identifizieren Sie alte Projekte und zustandsbehaftete Volumes, exportieren Sie einzigartige Daten und prunen Sie eine Kategorie nach der anderen. Prüfen Sie erneut sowohl Dockers interne Summen als auch die physische Kapazität unter macOS. Nutzen Sie breite Prune-Flags erst, nachdem Sie ihren erweiterten Umfang geprüft haben, und verwenden Sie einen Factory Reset nie als routinemäßigen Shortcut zur Speicherfreigabe. Der schnellste sichere Gewinn ist meist alter Build-Cache, nicht unbekannte Volumes.