Docker-schijfgebruik op Mac: wat er echt ruimte vreet

Docker op Mac ziet er zelden ineens enorm uit. Het groeit in layers.

Eerst is het één image, één project, één database-volume, één gestopte container, één build cache die je nog wilde opruimen. Dan wordt de machine krapper, begint Docker Desktop verdacht te lijken, en is de gebruikelijke conclusie vaag maar emotioneel bevredigend: “Docker vreet mijn schijf.”

Die conclusie is richtingsgewijs juist, maar te onnauwkeurig om nuttig te zijn. Het echte probleem is meestal niet “Docker in het algemeen.” Het is accumulatie over images, layers, build cache, gestopte containers, volumes en runtime-data die niemand als één systeem heeft beoordeeld.

Snelantwoord

Waarom Docker stilletjes zo groot wordt op Mac

Docker is ontworpen om nuttige status vast te houden totdat je het expliciet anders zegt. Docker’s eigen documentatie beschrijft opruiming als conservatief: ongebruikte images, containers, volumes en netwerken worden over het algemeen niet verwijderd tenzij je Docker vraagt het te doen.

Dat is handig voor ontwikkelaarsworkflows en precies de reden waarom schijfgebruik ongemerkt stijgt.

Op Mac voelt het beeld nog minder voor de hand liggend omdat Docker Desktop Linux-containers en images opslaat in één enkel groot schijfkopiebestand. Dat betekent dat de host één grote Docker-voetafdruk kan tonen terwijl de echte oorzaken begraven liggen onder meerdere lagen runtime-data.

Het groeipatroon is meestal een combinatie van:

• gepullde en herbouwde images over meerdere projecten;
• gedeelde layers die hergebruikt worden over tags en versies;
• gestopte containers die nog steeds beschrijfbare layers behouden;
• volumes die databases, geüploade bestanden of lokale servicestatus bevatten;
• build cache dat builds snel houdt totdat het duur wordt;
• dangling-objecten die achterblijven na herbouwingen en retags.

Het resultaat is een voetafdruk die stilletjes uitbreidt omdat elke individuele toevoeging normaal aanvoelt.

Wat er werkelijk Docker-schijfruimte inneemt op Mac

Als je een nuttig opruimplan wilt, splits de Docker-voetafdruk dan op in categorieën in plaats van het als één gigantische black box te behandelen.

Dit is waarom een generieke “grootste map”-workflow zwak is voor Docker. Dezelfde totale grootte kan heel verschillende opruimbeslissingen betekenen, afhankelijk van of de ruimte voornamelijk build cache is of voornamelijk echte volume-data.

Docker-images en gedeelde layers

Images zijn vaak het eerste waar ontwikkelaars aan denken, maar het diepere verhaal gaat over layers. Een machine met meerdere language runtimes, CI-achtige lokale builds en meerdere microservices kan snel veel gedeelde en unieke layers accumuleren.

Daarom mapped schijfgebruik niet altijd netjes naar de image-lijst die je je herinnert te hebben gepulled.

Docker-build cache

Build cache is een van de meest voorkomende verborgen oorzaken op actieve ontwikkelaarsmachines. Het bestaat om toekomstige builds sneller te maken, wat betekent dat het blijft tot je het opruimt. Dat betekent ook dat verwijderen meestal een performance-afweging is, geen gratis winst.

Gestopte Docker-containers

Ontwikkelaars onderschatten dit constant. Een container die niet draait, is nog steeds een opslagobject. Als het nog bestaat, kan het nog steeds schijfruimte innemen.

Docker-volumes

Volumes zijn waar het risico stijgt. Ze kunnen de data bevatten die je echt belangrijk vindt: databases, package-mirrors, uploads, zoekindexen, lokale registry-inhoud of servicestatus.

Dat is het verschil tussen Docker-opruiming en gewone cache-opruiming. Sommige Docker-opslag is herbouwbaar. Sommige is je omgeving.

Dangling Docker-images en -objecten

Dangling-objecten zijn vaak de veiligste opruimkandidaten. Docker’s prune-documentatie definieert dangling images als images die niet getagd zijn en niet door enige container worden gereferenceerd. Ze zijn precies het soort accumulatie dat groeit door normale iteratie.

Docker-schijfgebruik controleren op Mac

De beste eerste stap is niet Finder. Het is een Docker-niveau weergave van wat de daemon denkt dat ruimte verbruikt.

Docker’s eigen aanbeveling op Mac begint met docker system df -v, dat gebruik toont voor images, containers, lokale volumes en terugwinbare ruimte. Dat is de snelste manier om te stoppen met gissen.

Gebruik deze beoordelingsvolgorde:

1. Begin met docker system df -v

Dit is de beste eerste samenvatting omdat het laat zien:

• totaal en terugwinbaar image-gebruik;
• containergebruik;
• lokaal volume-gebruik;
• een meer gedetailleerde uitsplitsing als je de verbose flag gebruikt.

Als de terugwinbare ruimte klein is, zal brede opruiming waarschijnlijk niet veel helpen.

2. Bekijk gestopte containers vóór het prunen

Controleer of er veel gestopte containers zijn die niemand meer nodig heeft. Dit zijn vaak veiligere opruimkandidaten vergeleken met volumes of actieve runtime-status.

3. Bekijk images apart van build cache

Images en build cache lossen verschillende problemen op. Als de cache de grootste boosdoener is, is cache-gerichte opruiming meestal beter dan een brede reset van alles wat Docker beheert.

4. Bekijk volumes vóór alles dat --volumes gebruikt

Dit is het deel dat mensen overslaan en waar ze spijt van krijgen. Een volume kan losgekoppeld lijken van een momenteel draaiende container, maar nog steeds echte lokale data vertegenwoordigen voor een project dat je morgen weer wilt starten.

5. Bekijk Docker Desktop’s Mac-zijde schijfbeeld

Docker’s Mac-FAQ merkt op dat Docker Desktop Linux-containers en images opslaat in één schijfkopiebestand en dat sommige tools de maximale bestandsgrootte tonen in plaats van de werkelijk verbruikte grootte. Dat is belangrijk omdat een eng klinkend host-zijde getal niet altijd hetzelfde is als direct terugwinbare afval.

Voordat je iets prune

Snelle Docker-beoordelingscommando’s

Deze inspectiecommando’s zijn nuttig voordat je iets verwijdert:

docker system df -v
docker ps -a --size
docker images --format 'table {{.Repository}}\t{{.Tag}}\t{{.Size}}'
docker volume ls

Gebruik ze om te bevestigen wat er werkelijk terugwinbaar is voordat je een prune-scope kiest.

Waarom het direct verwijderen van Docker-mappen riskant is

Directe verwijdering voelt aantrekkelijk omdat het besluitvaardig lijkt. Het is ook hoe je Docker-opruiming verandert in runtime-opruimroulette.

Er zijn twee redenen.

Ten eerste houdt Docker runtime-status en metadata bij. Als je Docker-beheerde bestanden verwijdert buiten Docker’s eigen workflow om, riskeer je de relatie te breken tussen wat de runtime denkt dat bestaat en wat er werkelijk op schijf staat.

Ten tweede is op Mac de Docker-voetafdruk gekoppeld aan Docker Desktop’s beheerde schijfkopie en runtime-opslag. Docker’s eigen Mac-documentatie waarschuwt expliciet om het schijfkopiebestand niet direct in Finder te verplaatsen omdat Docker Desktop het uit het oog kan verliezen. Dezelfde algemene les geldt voor brute-force verwijdering binnen Docker-beheerde opslag: Docker-bewuste acties zijn veiliger dan gissingen op bestandssysteemniveau.

Dit is ook waarom het verwijderen van bestanden binnen een draaiende container niet hetzelfde is als het vrijmaken van host-schijfruimte. Docker’s Mac-documentatie merkt op dat host-ruimte wordt vrijgemaakt wanneer images worden verwijderd, niet automatisch wanneer bestanden verdwijnen binnen draaiende containers.

Wanneer prune helpt

prune is nuttig als je de voetafdruk al begrijpt en wilt dat Docker objecten verwijdert die het als ongebruikt beschouwt.

De belangrijkste gevallen waarin het helpt zijn eenvoudig:

• docker system prune wanneer gestopte containers, ongebruikte netwerken, dangling images en ongebruikte build cache zich hebben opgehoopt;
• docker builder prune wanneer build cache het echte probleem is;
• docker volume prune wanneer je hebt geverifieerd dat ongebruikte volumes werkelijk wegwerpbaar zijn;
• tijd- of label-gefilterde opruiming wanneer je de scope wilt verkleinen in plaats van alles weg te vegen.

Hier is Docker-bewuste opruiming duidelijk beter dan raw bestandsverwijdering. De runtime begrijpt objecttypen. Finder niet.

Wanneer docker system prune gevaarlijk is

Het gevaar is niet dat prune slecht is. Het gevaar is dat “ongebruikt” in Docker nog steeds “belangrijk voor mijn workflow” kan betekenen.

Wees voorzichtig als:

• een gestopte container deel uitmaakt van een lokale omgeving die je verwacht te hervatten;
• de volgende build de cache nodig heeft die je op het punt staat te wissen;
• lokale volumes database- of servicedata bevatten die je nog belangrijk vindt;
• docker system prune -a images zou verwijderen die nu niet draaien maar nog steeds deel zijn van actief werk;
• je op het punt staat volume-opruiming toe te voegen zonder eerst te bevestigen wat die volumes vertegenwoordigen.

Docker’s documentatie is expliciet dat volumes niet automatisch worden verwijderd omdat dat data zou kunnen vernietigen. Dat is het juiste mentale model voor volume-opruiming in het algemeen: volumes verdienen meer wantrouwen dan images of dangling cache.

De consequenties begrijpen vóór opruiming

Voordat je iets opruimt, beantwoord de consequentievraag in gewone taal:

Wat moet ik herbouwen, herpullen, herstellen of opnieuw creëren hierna?

Die vraag is nuttiger dan “Hoeveel kan ik verwijderen?”

Voor Docker ziet de praktische beoordeling er meestal zo uit:

1. Is de belangrijkste voetafdruk images, build cache, gestopte containers of volumes?
2. Zijn er draaiende containers die deel uitmaken van het plan, of vereist opruiming dat je ze eerst stopt?
3. Als ik cache prune, ben ik dan comfortabel met tragere builds of herpulls achteraf?
4. Als ik volumes prune, welke servicestatus of data verdwijnt daarmee?
5. Gebruik ik Docker-opruiming om een echt terugwinbaar-ruimteprobleem op te lossen, of reageer ik op één grote ondoorzichtige schijfkopie?

Dat is het verschil tussen gecontroleerde ontwikkelaarsopruiming en willekeurige opslagpaniek.

Waarom ontwikkelaarsopruiming anders is dan gewone bestandsopruiming

Gewone bestandsopruiming vraagt: “Welke map is groot?”

Docker-opruiming heeft andere vragen nodig:

• is dit herbouwbare cache of persistente servicedata;
• rapporteert de runtime het als terugwinbaar;
• moet opruiming via Docker-commando’s gebeuren in plaats van bestandssysteemverwijdering;
• zijn draaiende containers, gestopte containers of volumes deel van het consequentiemodel;
• heb ik een begeleide beoordeling nodig voordat ik een riskant opruimpad toepas?

Daarom hoort Docker in een container-bewuste workflow, niet in dezelfde mentale bucket als het verwijderen van downloads of het legen van een generieke cachemap.

Waar StorageRadar past

Dat is belangrijk omdat Docker niet gewoon “één grote map” is. Het is een ecosysteem van objecttypen met verschillende opruimconsequenties.

Als build cache het probleem is, is je actie anders dan op een volume-zware machine. Als draaiende containers eerst gestopt moeten worden, moet dat zichtbaar zijn vóór opruiming. Als het profiel riskant is, moet de workflow je opzettelijk vertragen.

Wat je niet moet doen

Vermijd deze veelvoorkomende fouten:

• behandel niet elke grote Docker-voetafdruk als één probleem met één commando;
• voer geen direct rm -rf uit binnen Docker-beheerde directories omdat de paden groot lijken;
• ga er niet vanuit dat een grote Docker Desktop-schijfkopie betekent dat al die ruimte nu veilig terugwinbaar is;
• voeg niet achteloos volume-opruiming toe als je niet hebt gecontroleerd wat die volumes bevatten;
• gebruik geen brede prune vlak vóór een demo, release of lokale omgevingsherbouw die je je niet kunt veroorloven.

Als Docker slechts een deel is van een groter ontwikkelaars-machineprobleem, is de companiongids over Xcode DerivedData die te veel ruimte inneemt op Mac een nuttige volgende lezing.

Conclusie

Docker-schijfgebruik op Mac is meestal niet mysterieus als je het in de juiste buckets splitst. De grootste bijdragers zijn typisch images, layers, build cache, gestopte containers, volumes, dangling-objecten en Docker Desktop-runtime-opslag.

De veilige zet is om eerst de voetafdruk te inspecteren, herbouwbare artefacten te scheiden van persistente data, en Docker-bewuste opruiming pas te gebruiken nadat je de consequenties begrijpt.