Cosa fa sì che un container riempia il disco di sistema quando i suoi dati si trovano altrove?

Un container può riempire il disco di sistema quando log, cache, file temporanei o scritture accidentali rimangono nello storage locale di Docker.

Spostare una libreria multimediale o un volume di database in un altro pool non sposta l’immagine del container, il layer scrivibile, il log JSON, la cache BuildKit, i metadati o qualsiasi percorso omesso dall’elenco dei mount. Anche un mount esterno non riuscito può lasciare vuota la directory host prevista, facendo sì che l’applicazione scriva nuovi dati sul disco di sistema senza errori evidenti.

Misura la root di Docker prima di esaminare i dati dell’applicazione

Controlla il filesystem che contiene la root dei dati di Docker e confronta le dimensioni delle directory host con i dati relativi a immagini, container, volumi e cache di build di Docker. Registra l’utilizzo prima di eliminare qualsiasi elemento.

Un utente Cloudron ha rilevato che /var/lib/docker/overlay2 occupava più spazio di tutti i dati applicativi visibili, dimostrando perché la root dello storage Docker debba essere misurata separatamente dalle librerie esterne.

Se il disco di sistema è pieno ma il pool esterno ha spazio disponibile, individua se la crescita si trova nei container, nei layer overlay, nei volumi, nelle immagini o nella cache di build. Non eseguire una pulizia generale prima di aver classificato i dati attivi e recuperabili.

Controlla la presenza di log JSON dei container senza limiti

Esamina il driver dei log e le dimensioni dei file di log di ogni container. Un servizio può archiviare i dati principali altrove mentre stdout e stderr crescono indefinitamente nella directory locale dei container Docker.

Code Maven documenta un caso in cui docker system df non mostrava il problema principale perché il file di log predefinito continuava a crescere al di fuori di quel riepilogo. Il responsabile nascosto era un log del container in continua crescita.

Individua e risolvi l’errore rumoroso dell’applicazione prima di ruotare o troncare i log. Configura la rotazione dei log con limiti per i container futuri e verifica che i nuovi file smettano di crescere una volta raggiunto il limite previsto.

Trova i dati scritti nel layer scrivibile del container

Confronta i percorsi persistenti previsti con le directory effettivamente utilizzate dall’applicazione per cache, transcodifica, download, database, miniature, backup e file temporanei. Qualsiasi scrittura non montata rimane nel layer scrivibile del container sul disco di sistema.

Una spiegazione pubblicata su un forum Docker osserva che le scritture e i file modificati dell’immagine vengono archiviati nel layer scrivibile, mentre i log di grandi dimensioni non sottoposti a rotazione risiedono nei metadati del container. Entrambi possono fare sì che un singolo container consumi quasi tutto lo spazio locale nonostante disponga di un volume dati esterno.

Utilizza la visualizzazione delle dimensioni per container e ispeziona i percorsi modificati più grandi all’interno del container. Aggiungi bind mount espliciti o volumi denominati solo per i dati che devono essere persistenti, quindi ricrea il container per eliminare i contenuti obsoleti del layer scrivibile dopo aver eseguito il backup di ciò che è importante.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verifica che il mount esterno fosse presente all’avvio del container

Controlla che l’SSD, la condivisione NAS o il pool di storage fosse montato nel percorso host previsto prima dell’avvio del container Docker. Confronta l’identità del dispositivo e l’output dei mount con la directory visualizzata dal container.

Quando un mount esterno è assente, la directory vuota sottostante del filesystem di sistema può comunque esistere. Il container può scrivervi normalmente, facendo crescere il disco di sistema mentre il pool esterno sembra non essere stato utilizzato.

Arresta il container prima di montare nuovamente lo storage sopra i dati presenti nella directory di fallback. Sposta o riconcilia i file nascosti in sicurezza, aggiungi dipendenze dai mount o controlli all’avvio e impedisci l’avvio dell’applicazione quando il dispositivo previsto è assente.

Esamina i layer delle immagini, la cache di build e gli oggetti abbandonati

Controlla le immagini non utilizzate, i container arrestati, i volumi anonimi e la cache BuildKit. Aggiornamenti frequenti o build locali possono accumulare numerosi layer anche quando i dati persistenti dell’applicazione sono montati correttamente altrove.

Una spiegazione pubblicata sul forum del progetto Moby chiarisce che i mount overlay possono rendere difficili da interpretare le cifre relative al disco e che l’utilizzo del filesystem sottostante deve essere valutato con attenzione. Un caso separato relativo a Home Assistant ha inoltre mostrato la crescita di overlay2 dovuta a log e layer nel tempo.

Rimuovi solo gli oggetti confermati come inutilizzati dai progetti Compose attuali e dai backup. Non eliminare mai manualmente singole directory overlay2, perché i riferimenti nei metadati di Docker potrebbero diventare incoerenti.

Convalida la correzione con una baseline di crescita

Dopo aver corretto il percorso responsabile, registra a intervalli regolari, durante il carico di lavoro che in precedenza causava la crescita, l’utilizzo della root di Docker, le dimensioni dei log, le dimensioni scrivibili dei container e l’utilizzo del pool esterno.

Il flusso di lavoro ZimaSpace per preparare un trasferimento NAS di grandi dimensioni offre un carico ripetibile per confermare che i dati vengano archiviati nel pool previsto.

Il problema è risolto solo quando la crescita del disco di sistema corrisponde al comportamento previsto di immagini e log, i dati applicativi persistenti crescono sul pool esterno e l’assenza di un mount esterno provoca un avvio sicuro interrotto invece di scritture silenziose sul filesystem root.