Come rimuovere container, immagini e volumi Docker

Rimuovere senza rompere: la regola base

Quando Docker inizia a saturare disco, la tentazione è lanciare un comando “pulente” e basta. È la strada più rapida per liberare spazio, ma anche quella più facile per cancellare dati persistenti, rompere ambienti di test o far sparire immagini che servono ancora a un deploy. La sequenza corretta è sempre la stessa: capire cosa occupa spazio, distinguere tra oggetti volatili e dati persistenti, poi rimuovere con un perimetro preciso.

La distinzione pratica è semplice: i container sono istanze eseguite da immagini; le immagini sono il template; i volumi sono il punto critico perché spesso contengono dati reali. Se cancelli un container, perdi il runtime e i suoi layer scrivibili. Se cancelli un’immagine, perdi la base per avviare nuovi container da quel tag o digest. Se cancelli un volume, perdi i dati che il container aveva delegato all’esterno. In produzione, il volume è la parte da trattare con più disciplina.

Prima verifica: dove sta finendo il disco

Il punto di partenza non è il comando di rimozione, ma la fotografia dello stato attuale. Docker offre un riepilogo molto utile con docker system df, che separa container, immagini, volumi e cache di build.

Comando utile:

docker system df

Se vuoi il dettaglio per tipo di oggetto:

docker system df -v

Qui devi guardare soprattutto tre cose: quanti container sono in stato Exited, quante immagini sono dangling o vecchie, e quanti volumi risultano non utilizzati. Se il disco è quasi pieno e i log sono su filesystem locale, controlla anche la directory di Docker, spesso sotto /var/lib/docker, e la presenza di file di log giganteschi per container attivi.

Un controllo rapido del filesystem aiuta a capire se il problema è davvero Docker o se il collo di bottiglia è altrove:

df -h /var/lib/docker

Se il dato non torna, il gap da chiudere è questo: identifica il path effettivo del data-root prima di fare pulizia. Il valore può essere diverso da default se in /etc/docker/daemon.json è stato configurato data-root.

Container: rimuovere quelli spenti, non quelli vivi

Il caso più sicuro è la rimozione dei container fermati. Questi oggetti non consumano CPU, ma occupano spazio in metadata, writable layer e talvolta in log. Se sono container di test, di build o di vecchie release, eliminarli è in genere il primo guadagno immediato.

Per vedere quali container sono fermi:

docker ps -a --filter status=exited

Rimozione selettiva di un container specifico:

docker rm <container_id_o_nome>

Se il container è ancora in esecuzione, il comando fallisce. È un bene: evita cancellazioni accidentali. Non usare -f in automatico se non hai verificato che il servizio sia realmente sostituibile o già migrato. Il rischio qui è interrompere un’applicazione attiva e perdere sessioni o job in corso.

Per una pulizia dei soli container fermati, il comando più diretto è:

docker container prune

Prima della conferma, Docker mostra il perimetro dell’operazione. È il punto giusto per fermarsi e verificare che non ci siano container fermi che vuoi conservare per debug. Il rollback, in questo caso, non esiste per il container eliminato: puoi solo ricrearlo da immagine e configurazione, quindi conviene esportare prima eventuali parametri o usare compose/versioning.

Se usi Docker Compose, controlla anche i container generati dal progetto specifico prima di fare pruning globale. Il fatto che un container sia Exited non significa che sia inutile: può essere un ambiente di staging da tenere per confronto o un job batch che vuoi preservare per audit.

Immagini: distinguere tra dangling, vecchie e ancora referenziate

Le immagini sono il secondo bersaglio naturale, ma anche qui serve disciplina. Una immagine dangling è spesso un layer intermedio o un tag rimasto orfano dopo un rebuild. È in genere sicura da rimuovere. Le immagini non più usate da nessun container sono un altro candidato, ma vanno trattate con più attenzione se nel tuo flusso di lavoro fai rollback su tag precedenti.

Per vedere le immagini presenti:

docker images

Per isolare quelle senza tag:

docker images -f dangling=true

Rimozione di una singola immagine:

docker rmi <image_id>

Se l’immagine è ancora referenziata da un container, Docker ti avvisa. Anche qui è utile: significa che la rimozione non è sicura senza prima fermare o ricreare i container dipendenti. Se vuoi liberare spazio con un perimetro prudente, usa la rimozione delle sole immagini dangling:

docker image prune

Per una pulizia più ampia, limitata alle immagini non usate da container esistenti:

docker image prune -a

Questa opzione è quella che richiede più attenzione. È utile su host di build o ambienti dove le immagini vengono ricreate spesso, ma può eliminare cache di deploy comode per rollback rapido. Prima di usarla, verifica se il nodo fa parte di un processo CI/CD che si appoggia alla cache locale o se è un server applicativo che deve mantenere immagini di versioni precedenti per un ripristino veloce.

Se il tuo obiettivo è ridurre il peso senza toccare le immagini più recenti, puoi combinare criteri temporali. Per esempio, eliminare immagini non usate da più di 30 giorni è una strategia sensata in ambienti con release frequenti, ma va sempre validata rispetto alla politica di rollback del team.

Volumi: il punto dove si fanno i danni veri

I volumi sono il motivo per cui la pulizia Docker va trattata come operazione amministrativa, non come housekeeping banale. Un volume può contenere database, file caricati dagli utenti, cache applicative o stato di servizi stateful. La rimozione indiscriminata può equivalere a una perdita dati irreversibile.

Prima di toccarli, elenca i volumi:

docker volume ls

Per capire quali non sono più usati da nessun container, puoi ispezionare i riferimenti oppure partire da una vista dettagliata con:

docker volume inspect <volume_name>

Se un volume è chiaramente dedicato a un database o a file persistenti, non va rimosso a meno che tu non abbia un backup verificato e un piano di ripristino. Il comando più aggressivo da conoscere, ma da usare con cautela, è:

docker volume prune

Questo elimina i volumi non usati da alcun container. Sulla carta è sicuro, nella pratica dipende dal tuo ecosistema: se hai container temporaneamente fermati ma destinati a essere riavviati con lo stesso volume, oppure stack Compose che non sono attivi in quel momento, rischi di cancellare dati che ti servono ancora. Per questo la verifica deve includere lo stato reale dello stack, non solo l’output di un singolo host.

Un controllo utile per ridurre l’ambiguità è correlare volumi e container con docker ps -a e, se serve, con la configurazione Compose o il file di orchestrazione. Il rollback per un volume cancellato dipende solo dai backup: snapshot filesystem, dump applicativo o replica. Senza quello, non c’è recupero pratico.

La pulizia completa: quando ha senso e quando no

Docker mette a disposizione un comando unico per la manutenzione generale:

docker system prune

Questo rimuove risorse inutilizzate, ma il suo significato reale dipende dalle opzioni usate. Senza parametri, elimina container fermi, reti non usate, immagini dangling e cache di build. È spesso sufficiente per recuperare spazio in modo ragionevole senza entrare nel territorio dei dati persistenti.

Se aggiungi -a, il perimetro si allarga alle immagini non usate da alcun container. Se aggiungi --volumes, il rischio sale perché coinvolgi anche i volumi non referenziati. La combinazione completa è comoda, ma va trattata come operazione con blast radius alto.

docker system prune -a --volumes

In un server di produzione questa variante non dovrebbe essere eseguita “a occhi chiusi”. Prima devi sapere se il nodo ospita servizi stateful, se i volumi sono gestiti fuori banda, se esistono ambienti fermati ma da tenere, e se il team ha un metodo di rollback. L’azione minima reversibile, in genere, è partire da docker container prune o docker image prune senza estensioni pericolose, poi misurare lo spazio recuperato con docker system df.

In pratica: prima prendi il guadagno facile, poi valuti il resto. Il pruning globale è l’ultima mossa, non la prima.

Sequenza operativa consigliata su host con spazio quasi finito

Se il server sta andando in saturazione disco, conviene seguire una catena semplice e verificabile. Questa sequenza riduce il rischio di cancellare dati utili e ti dà un riscontro immediato su quanto spazio hai recuperato.

1. Verifica il consumo Docker con docker system df -v e il filesystem con df -h.

2. Rimuovi i container fermati con docker container prune e ricontrolla il delta spazio.

3. Rimuovi le immagini dangling con docker image prune.

4. Se il nodo non ospita workload stateful e hai confermato i rollback, valuta docker image prune -a.

5. Solo se hai certezza che i volumi non contengano dati utili e hai backup validi, considera docker volume prune o docker system prune --volumes.

Dopo ogni passaggio, ricontrolla lo spazio disponibile. Non aspettare di fare tutto in blocco: il miglior modo per capire quanto stai rischiando è misurare il beneficio di ogni step. Se il problema rientra dopo il primo o il secondo comando, fermati lì.

Log Docker: spesso il vero colpevole non sono immagini e volumi

Su host con molti container, lo spazio può finire per colpa dei log in formato JSON generati da Docker. Il file cresce dentro la directory di runtime del container e può diventare enorme se non c’è rotazione. In questi casi, eliminare immagini e volumi non basta: il guadagno è altrove.

Per individuare i file più grandi sotto il data-root, puoi partire da:

du -sh /var/lib/docker/*

Se il problema è nei log, li trovi spesso sotto una struttura simile a /var/lib/docker/containers/<id>/<id>-json.log. La correzione strutturale è abilitare la rotazione nel daemon Docker, ad esempio con una configurazione come questa:

{