Gestiamo un sito Discourse self-hosted su DigitalOcean e abbiamo un disco da 25 GB. Ho appena provato ad aggiornare la nostra immagine Discourse e ho ricevuto il messaggio “è necessario più spazio per continuare”. Dopo aver pulito l’immagine e i container Docker, ci mancano ancora 0,4 GB.
Qualche consiglio su come risparmiare spazio? Sia per poter aggiornare ora, sia per risparmiare spazio in futuro. So che dovremo ridimensionare presto, ma sarebbe utile riuscire a superare almeno un altro aggiornamento dell’immagine Discourse.
Utilizziamo la funzionalità di backup di DigitalOcean. Non ho visto un’opzione per eliminare manualmente uno dei nostri backup.
Come posso procedere? Sono una persona che non ha esperienza di programmazione ma sono in grado di capire cosa fare e perché lo sto facendo dopo aver ricevuto alcune indicazioni.
È importante capire perché hai immagini intermedie senza tag che appaiono come <none> <none> per evitarle, poiché, come hai visto, non puoi rimuoverle se sono in uso.
Il motivo per cui si verificano le immagini senza tag è che hai creato un’immagine, poi hai modificato il Dockerfile e hai ricreato quell’immagine, riutilizzando alcuni dei layer della build precedente. Ora hai un’immagine senza tag che non può essere eliminata perché alcuni dei suoi layer sono utilizzati da una nuova versione di quell’immagine.
La soluzione è:
Eliminare la nuova versione dell’immagine
Eliminare l’immagine senza tag e
Ricreare la nuova versione dell’immagine in modo che possieda tutti i layer.
Ti rimarrà una singola immagine con tag che contiene tutti i layer delle precedenti immagini senza tag e la nuova immagine.
Non mi aspettavo di trovare 2,64 GB in un’immagine docker , quindi ora sto cercando di capire cosa sta succedendo lì. Se non ho bisogno di questa immagine, allora siamo sicuramente lontani dal dover ridimensionare.
Quanto tempo? Non vedo alcun accenno a ciò - so che sto eseguendo felicemente un forum su 20G e un altro su 25G.
In shared potresti avere molti dati di backup (forse in shared/standalone/backups/default). Potresti anche avere vecchie copie del database o vecchi file di log. Ti consiglio di eseguire du -kx / | sort -n | tail -49
o simile.
È giusto notare che puoi risparmiare tempo, a scapito di denaro, passando a un’istanza più grande. Oppure puoi fare il compromesso opposto.
Questo mi preoccupa un po’. DO potrebbe aiutarti con i backup dell’intero sistema, ma se fossi io, sarei più felice di sapere come eseguire i backup di Discourse e come ottenere una copia locale sicura. E come potare i backup. (Se per qualche sfortuna DO cancellasse la tua istanza e il tuo account, vorresti che i tuoi dati sopravvivessero a questo.)
Usiamo anche la funzionalità di backup di Discourse e mi sono reso conto che non avevamo cancellato i vecchi backup lì.
Bene, ho eliminato tutti i backup tranne l’ultimo utilizzando l’interfaccia di Discourse e ho anche scaricato il backup più recente sul mio disco locale. Questo mi porta a meno di 100 MB di spazio libero.
Ecco cosa ottengo quando eseguo quel comando in var/discourse
Dove {nome_immagine} è il nome dell’immagine che si desidera eliminare. È anche possibile utilizzare l’ID dell’immagine per eliminare l’immagine (ad esempio, docker rmi {id_immagine}). Questo è ciò che dovrai usare per eliminare un’immagine con il nome <none>.
Ad esempio, supponiamo che tu abbia le seguenti immagini:
REPOSITORY TAG IMAGE ID CREATED SIZE
my-new-image latest c18f86ab8daa 12 secondi fa 393MB
<none> <none> b1ee72ab84ae 1 minuto fa 393MB
my-image latest f5a5f24881c3 2 minuti fa 393MB
È possibile che l’immagine <none> non possa essere eliminata perché my-new-image sta utilizzando alcuni strati da essa. Quello che devi fare è:
Ciò rimuove my-new-image:latest che riutilizza gli strati dell’immagine <none>. Quindi elimina l’immagine <none> utilizzando il suo ID immagine b1ee72ab84ae. Infine, ricrea my-new-image creando tutti gli strati necessari.
Assicurati anche di non avere container fermati che utilizzano ancora l’immagine “senza tag” <none>. Usa docker ps -a per vedere tutte le immagini, comprese quelle che sono uscite. In tal caso, usa docker rm {id_container} per rimuovere il container e quindi prova a rimuovere nuovamente l’immagine <none>.
Questo ha risolto il problema e ho anche modificato la policy!
Voglio ancora rintracciare il problema con l’immagine <none> (dato che è ridicolo che occupi più di 2 GB), ma hai risolto il mio problema più immediato di creare spazio sufficiente per l’aggiornamento! Grazie!!