Waardoor vult een container de systeemschijf wanneer zijn gegevens elders staan?

Een container kan de systeemschijf vullen wanneer logboeken, caches, tijdelijke bestanden of onbedoelde schrijfbewerkingen in de lokale opslag van Docker blijven staan.

Het verplaatsen van een medial bibliotheek of databasevolume naar een andere pool verplaatst niet de containerimage, de schrijfbare laag, het JSON-logboek, de BuildKit-cache, metagegevens of een pad dat niet in de lijst met mounts is opgenomen. Een mislukte externe mount kan er ook voor zorgen dat de verwachte hostmap leeg blijft, waardoor de toepassing zonder duidelijke fout nieuwe gegevens naar de systeemschijf schrijft.

Meet de Docker-hoofdmap voordat je toepassingsgegevens inspecteert

Controleer het bestandssysteem waarop de gegevenshoofdmap van Docker staat en vergelijk de grootten van hostmappen met de registratie van Docker voor images, containers, volumes en de buildcache. Leg het gebruik vast voordat je iets verwijdert.

Een Cloudron-gebruiker ontdekte dat /var/lib/docker/overlay2 meer ruimte in beslag nam dan alle zichtbare toepassingsgegevens, wat laat zien waarom de Docker-opslaghoofdmap afzonderlijk van externe bibliotheken moet worden gemeten.

Als de systeemschijf vol is maar de externe pool nog ruimte heeft, bepaal dan of de groei zich onder containers, overlaylagen, volumes, images of de buildcache bevindt. Voer geen algemene opschoning uit voordat actieve en herstelbare gegevens zijn geclassificeerd.

Controleer op onbeperkt groeiende JSON-logboeken van containers

Inspecteer het logstuurprogramma en de grootte van elk containerlogboek. Een service kan de primaire gegevens elders opslaan, terwijl stdout en stderr onbeperkt groeien in de lokale containermap van Docker.

Code Maven beschrijft een geval waarin docker system df het hoofdprobleem niet zichtbaar maakte, omdat het standaardlogboek buiten dat overzicht bleef groeien. De verborgen verbruiker was een steeds groter wordend containerlogboek.

Zoek de fout in de luidruchtige toepassing en los die op voordat je logboeken roteert of afkapt. Configureer voor toekomstige containers een begrensde logrotatie en controleer of de nieuwe bestanden bij de verwachte limiet stoppen met groeien.

Vind gegevens die naar de schrijfbare laag van de container zijn geschreven

Vergelijk de bedoelde persistente paden met de werkelijke cache-, transcodeer-, download-, database-, miniatuur-, back-up- en tijdelijke mappen van de toepassing. Elke niet-gemounte schrijfbewerking blijft in de schrijfbare laag van de container op de systeemschijf staan.

Een uitleg op een Docker-forum vermeldt dat schrijfbewerkingen en gewijzigde imagebestanden in de schrijfbare laag worden opgeslagen, terwijl grote niet-geroteerde logboeken in de containermetagegevens staan. Beide kunnen ervoor zorgen dat één container vrijwel alle lokale ruimte verbruikt, ondanks een extern gegevensvolume.

Gebruik rapportage van de grootte per container en inspecteer de grootste gewijzigde paden in de container. Voeg expliciete bind mounts of benoemde volumes toe voor gegevens die persistent moeten blijven en maak de container daarna opnieuw aan om verouderde inhoud van de schrijfbare laag te verwijderen, nadat je waardevolle gegevens hebt geback-upt.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Controleer of de externe mount aanwezig was toen de container startte

Controleer of de SSD, NAS-share of opslagpool op het verwachte hostpad was gemount voordat Docker de container startte. Vergelijk de apparaatidentiteit en de mountuitvoer met de map die de container ziet.

Wanneer een externe mount ontbreekt, kan de onderliggende lege map op het bestandssysteem van de systeemschijf nog steeds bestaan. De container kan normaal naar die terugvalmap schrijven, waardoor de systeemschijf voller wordt terwijl de externe pool onaangeroerd lijkt.

Stop de container voordat je opslag opnieuw mount over gegevens die in de terugvalmap staan. Verplaats of verwerk de verborgen bestanden veilig, voeg mountafhankelijkheden of opstartcontroles toe en voorkom dat de toepassing start wanneer het verwachte apparaat ontbreekt.

Inspecteer imagelagen, de buildcache en achtergelaten objecten

Controleer ongebruikte images, gestopte containers, anonieme volumes en de BuildKit-cache. Door frequente updates of lokale builds kunnen veel lagen zich opstapelen, zelfs wanneer de persistente gegevens van de toepassing correct elders zijn gemount.

Een uitleg op een forum van het Moby-project verduidelijkt dat overlay-mounts schijfmetingen verwarrend kunnen maken en dat het gebruik van het onderliggende bestandssysteem zorgvuldig moet worden geïnterpreteerd. Een afzonderlijk Home Assistant-geval liet na verloop van tijd ook groei van overlay2 door logboeken en lagen zien.

Verwijder alleen objecten waarvan door de huidige Compose-projecten en back-ups is bevestigd dat ze ongebruikt zijn. Verwijder nooit afzonderlijke overlay2-mappen handmatig, omdat de verwijzingen in de metagegevens van Docker inconsistent kunnen raken.

Valideer de oplossing met een groeibaseline

Leg na het corrigeren van het verantwoordelijke pad regelmatig het gebruik van de Docker-hoofdmap, de logboekgroottes, de schrijfbare grootten van containers en het gebruik van de externe pool vast tijdens de werklast die eerder groei veroorzaakte.

De ZimaSpace-werkwijze voor het stagen van een grote NAS-overdracht biedt een herhaalbare belasting om te bevestigen dat gegevens op de bedoelde pool terechtkomen.

Het probleem is pas opgelost wanneer de groei van de systeemschijf overeenkomt met het verwachte gedrag van images en logboeken, persistente toepassingsgegevens op de externe pool groeien en een ontbrekende externe mount leidt tot een veilige mislukte start in plaats van stilzwijgende schrijfbewerkingen naar het rootbestandssysteem.