Poradnik miejsca dla programistów

Docker zajmuje miejsce na moim Macu

Docker Desktop trzyma wszystko w jednym pliku. Rośnie przy każdej kompilacji, a usuwanie obrazów nie czyni go mniejszym. Oto dlaczego i co naprawdę odzyskuje miejsce.

14 dni za darmo, bez karty. Potem 15 $ jednorazowo na 3 komputery, macOS i Linux.

Mapa drzewa Bytesweep, na której obraz dysku Dockera dominuje folder domowy Maca

Gdzie jest miejsce

Na macOS Docker Desktop uruchamia maszynę wirtualną z Linuksem, a cały system plików tej maszyny to jeden rzadki plik na twoim Macu:

~/Library/Containers/com.docker.docker/Data/vms/0/data/Docker.raw

Sprawdź jego prawdziwy rozmiar na dysku — nie logiczny, który zawsze jest maksimum, na jakie pozwoliłeś Dockerowi:

du -h -d0 ~/Library/Containers/com.docker.docker/Data/vms/0/data/

Dlaczego usuwanie obrazów go nie zmniejsza

Usunięcie obrazu zwalnia bloki wewnątrz systemu plików maszyny wirtualnej, ale plik na twoim Macu zachowuje rozmiar — już wziął tyle od macOS. Nowsze wersje Docker Desktop wysyłają TRIM z wnętrza maszyny, dzięki czemu macOS może odzyskać zwolnione bloki, ale dzieje się to według harmonogramu Dockera, a nie w chwili, gdy robisz prune. Do tego czasu docker system df zgłasza gigabajty zwolnionego miejsca, podczas gdy Finder nie pokazuje żadnej zmiany.

Odzyskiwanie miejsca

Po kolei: najpierw to, co najmniej niszczące.

1. Zobacz, co Docker uważa, że zajmuje

Zawsze zacznij tutaj. Rozdziela obrazy, kontenery, woluminy i pamięć podręczną kompilacji i mówi, ile z każdego da się odzyskać.

docker system df -v

2. Wyczyść pamięć podręczną kompilacji

Na maszynie, która regularnie buduje obrazy, to zwykle największa pojedyncza pozycja i najbezpieczniejsza do usunięcia — jedynie spowalnia kolejną kompilację.

docker builder prune -a

3. Usuń to, co naprawdę nieużywane

Zatrzymane kontenery, osierocone obrazy i nieużywane sieci:

docker system prune

Dodaj -a aby usunąć także każdy obraz nieużywany przez działający kontener — to znaczy, że pobierzesz je później ponownie. Poniższe dodaj --volumes tylko jeśli masz pewność: w woluminach bazy danych trzymają swoje dane, i to jedyne polecenie na tej stronie, które niszczy coś, czego nie pobierzesz ponownie.

4. Wypisz woluminy, zanim ich dotkniesz

Zobacz, co naprawdę by zniknęło:

docker volume ls
docker volume ls -f dangling=true

Docker rzadko jest jedyny

Możesz wykonać każde polecenie z tej strony, a na tym samym Macu DerivedData Xcode i kilka zapomnianych wag modeli są zwykle równie duże. Bytesweep mierzy prawdziwy rozmiar Dockera na dysku obok nich wszystkich w jednym dziesięciosekundowym przebiegu, żebyś naprawił dysk raz, zamiast gonić go narzędzie po narzędziu.

5. Spraw, by macOS odzyskał plik

Po prune Docker Desktop ma przewidziany sposób na zwrócenie zwolnionych bloków: Ustawienia → Zasoby → Zaawansowane → Wykorzystanie dysku, albo zamknięcie i ponowne otwarcie Docker Desktop, co przy starcie wyzwala TRIM. Daj mu minutę i sprawdź rozmiar pliku ponownie, zanim uznasz, że nie zadziałało.

6. Obniż limit dysku

W Ustawienia → Zasobylimit dysku wirtualnego określa, jak duży może urosnąć Docker.raw. Obniżenie go samo w sobie niczego nie zwalnia, ale zakłada problemowi sufit. To, że podniosłeś go „na wszelki wypadek”, jest powodem, dla którego plik doszedł do 64 GB.

7. Ostateczność

Ustawienia → Rozwiązywanie problemów → Clean / Purge data całkowicie resetuje dysk maszyny wirtualnej i sprowadza plik prawie do zera. Usuwa każdy obraz, kontener i wolumin, jaki masz. Użyj, gdy nic innego nie pomogło i wiesz, co jest w twoich woluminach.

Nie usuwaj Docker.raw w Finderze. To nie jest plik pamięci podręcznej — to dane całej instalacji Dockera, a usunięcie go przy działającym Dockerze może zostawić maszynę wirtualną w stanie, który i tak będzie wymagał resetu.

Warto też sprawdzić

Docker rzadko bywa sam

Na Macu, na którym Docker doszedł do 50 GB, DerivedData Xcode i lokalne modele AI są zwykle tuż za nim. Jeśli odzyskujesz miejsce, warto zmierzyć cały dysk raz, zamiast naprawiać po jednej rzeczy naraz. Pełna lista →

Na Linuksie nie ma pliku obrazu

Na Linuksie Docker zapisuje wprost do /var/lib/docker, więc prune zwalnia miejsce natychmiast i nic z powyższego problemu z TRIM nie ma zastosowania. Sprzątanie dysku na Linuksie →

Zobacz Dockera obok całej reszty

Bytesweep mierzy prawdziwy rozmiar Dockera na dysku, pokazuje go obok Xcode, symulatorów, node_modules i wag modeli, i zaznacza, co można bezpiecznie usunąć — nie ruszając twoich woluminów.

Pytania

Czy bezpiecznie jest usunąć Docker.raw?

Nie z Findera i nie przy działającym Dockerze. Ten jeden plik to każdy obraz, kontener i wolumin, jaki masz. Jeśli naprawdę chcesz zacząć od zera, użyj w Docker Desktop Rozwiązywanie problemów → Clean / Purge data, co robi to samo w sposób, o którym Docker wie.

Dlaczego docker system prune mówi, że zwolnił 20 GB, a nic się nie zmieniło?

Bo zwolnił 20 GB wewnątrz systemu plików maszyny wirtualnej, a nie na twoim Macu. Plik zachowuje rozmiar, dopóki nie wykona się TRIM i macOS nie odzyska bloków. Zamknięcie i ponowne otwarcie Docker Desktop zwykle to wyzwala.

Czy docker system prune usunie moje bazy danych?

Tylko jeśli dodasz --volumes. Bez tej flagi zostawia woluminy w spokoju. Z nią znika każdy wolumin niepodłączony do kontenera, a wolumin zatrzymanej bazy liczy się jako niepodłączony.

Jak duży powinien być Docker.raw?

Nie ma dobrej odpowiedzi, ale na maszynie z kilkoma aktywnymi projektami 15 do 25 GB jest normą, a 60 GB oznacza, że pamięć podręczna kompilacji nigdy nie była czyszczona. Sprawdź poleceniem docker system df -v zanim uznasz, że chodzi o obrazy.