/var/lib/docker wächst, bis es zum Problem der ganzen Festplatte wird. Die Lösung ist ein einziger Befehl, aber ihn blind auszuführen ist genau der Weg, wie Leute das Basis-Image löschen, auf dem sie gerade aufbauen wollten. Erst hinschauen, dann aufräumen.
1. Sehen, wohin der Platz verschwunden ist
$ clai zeig wie viel speicherplatz docker belegt und wie viel sich freigeben lässt→ docker system dfTYPE TOTAL ACTIVE SIZE RECLAIMABLEImages 47 13 28.88GB 20GB (69%)Containers 16 9 126.8MB 513.8kB (0%)Local Volumes 38 7 6.311GB 4.084GB (64%)Build Cache 181 0 0B 0BLies zuerst die Spalte RECLAIMABLE. Hier sind Images das Problem, Volumes kommen an zweiter Stelle, Container sind Rauschen.
2. Die sichere Aufräumaktion
$ clai entferne gestoppte container, verwaiste images und ungenutzte netzwerke→ docker system pruneDas einfache prune nimmt gestoppte Container, verwaiste Images (Layer ohne verbleibenden Tag), ungenutzte Netzwerke und den Build-Cache. Getaggte Images und Volumes bleiben unangetastet. Diesen Befehl kannst du bedenkenlos ausführen.
3. Die aggressive Aufräumaktion
$ clai entferne alle images die kein laufender container verwendet→ docker system prune -a⚠ CAUTION — entfernt jedes Image, das kein laufender Container nutzt-a erweitert "ungenutzt" von ohne Tag zu aktuell von keinem laufenden Container verwendet. Dein sorgfältig gepulltes 4-GB-Basis-Image gilt als ungenutzt, wenn gerade nichts läuft — beim nächsten Build lädst du es erneut herunter.
4. Volumes: der Platz, den niemand erwartet
$ clai liste docker volumes auf die kein container verwendet→ docker volume ls -qf dangling=truePrune überspringt Volumes standardmäßig, ganz bewusst — dort leben die Datenbanken. Erst auflisten, die Namen erkennen, und erst dann entscheiden. docker volume prune löscht Daten, die per Definition kein Backup haben.
5. Nur der Build-Cache
$ clai leere den docker build cache der älter als eine woche ist→ docker builder prune --filter 'until=168h'Auf einer CI-Maschine ist das meist der größte und sicherste Gewinn. --filter until= lässt dich aktuelle Layer behalten, damit der nächste Build weiterhin schnell bleibt.
6. Damit es nicht wieder passiert
$ clai begrenze docker container log dateien auf 10 megabyte und 3 dateien→ sudo tee /etc/docker/daemon.json <<'EOF'{"log-driver":"json-file","log-opts":{"max-size":"10m","max-file":"3"}}EOFContainer-Logs haben standardmäßig keine Rotation. Das ist die eine Einstellung, die den häufigsten Wiederholungsfall verhindert. Sie gilt für Container, die nach einem Neustart des Daemons erstellt werden.
Fallstricke
prune -alöscht alles, wenn nichts läuft. Die Definition von "in Benutzung" ist ein laufender Container, nicht ein Image, das dir gefällt. Starte zuerst deinen Stack, oder nimm stattdessen--filter 'until=720h'.- Prune verkleinert eine volle Festplatte unter Docker Desktop nicht. Unter macOS und Windows gibt das VM-Disk-Image den Platz nicht automatisch an den Host zurück.
- Ein gelöschtes Volume ist weg. Es gibt keinen Papierkorb. Sichere Volumes, bevor du sie prunst, jedes Mal.
Verwandte Fragen
Was ist der Unterschied zwischen docker system prune und docker image prune -a? system prune erfasst Container, Netzwerke, Images und Build-Cache in einem Durchgang; image prune -a entfernt nur Images, dafür auch getaggte.
Warum ist /var/lib/docker/overlay2 so groß? Das sind Image- und Container-Layer. Lösche dort nichts von Hand — die Metadaten liegen woanders, und du zerstörst dir den Image-Store. Nutze prune.
Kann ich sehen, welches Image am größten ist? docker image ls --format '{{.Size}}\t{{.Repository}}:{{.Tag}}' | sort -rh sortiert sie.
Siehe auch
- Docker und Kubernetes: Muskelgedächtnis, ersetzt
- df sagt, die Platte ist voll, du sagt, sie ist es nicht
- Alte Logs und Backups mit einem Satz aufräumen
CliAI markiert prune -a als CAUTION und fragt vor der Ausführung nach — denn der Unterschied zwischen den beiden Prunes sind 20 GB erneuter Downloads. In einer Zeile installieren.