Amministratore di Discourse self-hosted da 10 anni chiede: perché non ripulire il launcher come parte della ricostruzione?

Installazione
1

Ciao a tutti. Mi chiamo Lee e ho fatto self-hosting di Discourse in modo intermittente dal 2013. Ricordo di aver dovuto armeggiare con rbenv per iniziare. Ricordo di aver dovuto compilare nginx con Phusion Passenger per far funzionare le cose. Ricordo di aver discusso con @sam probabilmente dieci anni fa che passare a Docker fosse una capitolazione alla debolezza degli sviluppatori “funziona sul mio home directory e sul mio incubo di dotfiles” (e di essermi sbagliato di grosso!). Ricordo la prima volta che ho sentito la frase “bike-shedding”. Per citare l’uomo, ricordo tutto.

Dopo essere stato assente per diversi anni, ho avuto l’occasione di tornare al self-hosting di Discourse come sostituto dei commenti nativi di Wordpress su un sito di previsioni meteo dell’area di Houston che tipicamente gestisce circa 10k PV/giorno, ma durante gli uragani, potrebbe gestire circa 2 milioni di PV/giorno con circa 1 milione di visitatori unici. Abbiamo lottato con i commenti nativi di Wordpress per anni, ma da mercoledì scorso, siamo live su Discourse self-hosted. (E su Graviton3, niente meno! Seriamente, funziona e basta ed è fantastico.)

Ecco il punto a cui sto arrivando: è il 2025 e, come self-hoster, sto ancora gestendo manualmente lo spazio della mia immagine docker. Presento una storia su /dev/root, raccontata in snippet di codice, dopo meno di una settimana in produzione:

[11:49:56] 0 ✓ (1.8ms)
root@discourse:/var/discourse # df -h
Filesystem       Size  Used Avail Use% Mounted on
/dev/root         30G   21G  9.6G  69% /
tmpfs            7.7G     0  7.7G   0% /dev/shm
tmpfs            3.1G  1.1M  3.1G   1% /run
tmpfs            5.0M     0  5.0M   0% /run/lock
efivarfs         128K  3.6K  125K   3% /sys/firmware/efi/efivars
/dev/nvme1n1p16  891M  109M  720M  14% /boot
/dev/nvme1n1p15   98M  6.4M   92M   7% /boot/efi
/dev/nvme0n1      32G  346M   30G   2% /var/discourse
tmpfs            1.6G   12K  1.6G   1% /run/user/1001
overlay           30G   21G  9.6G  69% /var/lib/docker/overlay2/5a649418bbfc064f488e895572eec1ace487a3eaa324fe1d8e3b395e6c5e3645/merged

[11:49:59] 0 ✓ (4.8ms)
root@discourse:/var/discourse # ./launcher cleanup
WARNING! This will remove all stopped containers.
Are you sure you want to continue? [y/N] y
Total reclaimed space: 0B
WARNING! This will remove all images without at least one container associated to them.
Are you sure you want to continue? [y/N] y
Deleted Images:
untagged: discourse/base@sha256:3696bdf18652b5455bd33795ec3b8e0f201c17a04f0e0126fc0317ed821373cd
....

[un'enorme quantità di righe redatte]

....
Total reclaimed space: 12.43GB

[11:50:34] 0 ✓ (27.8s)
root@discourse:/var/discourse # df -h
Filesystem       Size  Used Avail Use% Mounted on
/dev/root         30G  6.9G   24G  23% /
tmpfs            7.7G     0  7.7G   0% /dev/shm
tmpfs            3.1G  1.1M  3.1G   1% /run
tmpfs            5.0M     0  5.0M   0% /run/lock
efivarfs         128K  3.6K  125K   3% /sys/firmware/efi/efivars
/dev/nvme1n1p16  891M  109M  720M  14% /boot
/dev/nvme1n1p15   98M  6.4M   92M   7% /boot/efi
/dev/nvme0n1      32G  346M   30G   2% /var/discourse
tmpfs            1.6G   12K  1.6G   1% /run/user/1001
overlay           30G  6.9G   24G  23% /var/lib/docker/overlay2/5a649418bbfc064f488e895572eec1ace487a3eaa324fe1d8e3b395e6c5e3645/merged

[11:55:28] 0 ✓ (3.3ms)
root@discourse:/var/discourse #

Vi amo. Amo Discourse. Sono legato al prodotto e intendo continuare a usarlo più o meno per sempre.

Ma, tipo… solo, perché. Perché è il 2025 e io, da solo, sto ancora armeggiando con launcher cleanup? Perché la gestione delle immagini non è una funzione intrinseca di launcher?

Di nuovo, vi amo. Ho scelto Discourse per SCW perché credo in quello che avete costruito e amo usarlo. Ma tipo… metà del volume di avvio della mia povera AMI è occupato da roba inutile che potrebbe—almeno se capisco il lato tecnico delle cose—essere gestita automaticamente.

Non intendo lamentarmi, sto solo facendo un check-in dopo qualche anno lontano dalla sedia dell’amministratore. Amo il rilevamento spam con AI e il triage con AI, specialmente in un forum meteo dove i post politicamente carichi riguardo al cambiamento climatico (sia a favore che contro) sono una caratteristica regolare. Grazie di tutto <3

7 Mi Piace
2

Ottimo rivederti, Lee!

Mi è successa la stessa cosa sul mio sito self-hosted questa settimana. I backup fallivano e ho lasciato correre per circa una settimana perché ero via e non avevo accesso al mio laptop. Appena sono tornato ho eseguito la pulizia e ho recuperato molto spazio su disco e i backup sono stati in grado di funzionare di nuovo.

4 Mi Piace
3

Ciao, lieto di rivederti qui!

Una parte è che è stato “abbastanza buono” - non lo usiamo internamente sul nostro hosting poiché ruotiamo frequentemente container e immagini, quindi la nostra cadenza è molto diversa da quella che sarebbe un sito self-hosted.

L’altra spiegazione è che tra launcher e docker, nessun sistema vuole assumersi la piena responsabilità del programma di rimozione dei dati - il programma per l’eliminazione dei dati utente dovrebbe essere sotto il pieno controllo dell’utente.

Ho riscontrato alcuni problemi sui siti self-hosted in cui la pulizia pulisce anche la nuova base di discourse che dovevo creare, portando a un terribile problema dell’uovo e della gallina. Non far sì che ciò venga notato a causa dell’esecuzione automatica sarebbe probabilmente un intoppo da capire.

Un semplice suggerimento qui potrebbe forse essere quello di usare docker system prune o launcher clean tramite cronjob a proprio rischio. Potrebbe funzionare?

6 Mi Piace
4

Perché a volte può eliminare l’unico container funzionante che hai.
Potresti semplicemente eseguirlo ogni volta prima di eseguire una ricostruzione, mentre tutti i tuoi container funzionanti sono ancora in esecuzione.

1 Mi Piace
5

Ottima idea, a volte le risposte semplici sono le migliori. Grazie, e farò in modo che sia così!

6

Come posso/possiamo rispondere sì quando si esegue ./launcher cleanup tramite cron? Intendo dire che per me i container non sono un grosso problema, ma le immagini orfane lo sono.

1 Mi Piace
7

Non c’è motivo di farlo con cron, crei nuove immagini solo quando ne crei una con launcher. Devi farlo solo prima o dopo aver creato un’immagine.

Se vuoi evitare i prompt di launcher, puoi farlo con i comandi docker come suggerito sopra. Eccone uno (ma leggi il manuale per capire cosa fa e assicurarti che sia quello che vuoi):

/usr/bin/docker image prune -a -f
1 Mi Piace
8

Devo dare un’occhiata. Grazie.

Non so nient’altro ma oggi, di nuovo, la ricompilazione è fallita perché avevo meno di 5 GB di spazio libero. Certo, cleanup ha fatto il suo lavoro, e non è stato altro che un po’ fastidioso. Eppure, vorrei non vedere tali situazioni.

Ed ecco quanto poco capisco come funziona docker :joy: Se ho capito bene quelle immagini, che sono state distrutte perché non erano usate da nessun container, non erano immagini nel senso di immagini come ho pensato per tutto il tempo :face_with_peeking_eye: :rofl:

2 Mi Piace
9

La risposta diretta è che potresti usare echo y | launcher cleanup per inviare “y” in anticipo.

La risposta indiretta è che la pulizia effettiva del launcher (dopo che è equivalente) è costituita da questi due comandi:

docker container prune --force --filter until=24h
docker image prune --all --force --filter until=24h

e il prompt a cui penso ti riferisci è per la rimozione delle vecchie directory di dati di postgres:

rm -rf /var/discourse/shared/standalone/postgres_data_old*

Potresti eliminare la dipendenza da launcher e usare direttamente quei comandi.

2 Mi Piace
10

In realtà mi riferisco alle domande che ho ricevuto durante l’esecuzione di ./launcher cleanup. Per prima cosa rimuove tutti i container fermati. Poi offre di eliminare tutte le immagini che non sono utilizzate da almeno un container — ed è quella parte che mi libera spazio, quasi 40 GB l’ultima volta.

Ecco perché ero piuttosto confuso, dato che non riuscivo a capire perché avessi così tante immagini orfane (jpg, png, ecc.). Ma stiamo parlando qui di immagini completamente diverse, giusto.

Sì, ricostruisco almeno due volte alla settimana. O, più di recente, quando stavo dando la caccia a un plugin che si comportava male, ho fatto almeno una dozzina di ricostruzioni.

Farà ogni volta una nuova immagine, non lo so.

11

Ogni rebuild è una nuova immagine, quindi si accumulerebbero se non venissero ripulite.

Il launcher chiede attualmente di ripulire solo quando esegue altri comandi una volta che lo spazio su disco è insufficiente.

1 Mi Piace
12

Il che può essere un problema se lo si esegue con uno script; lo script rimarrà in attesa di una risposta (immagino sia per questo che si utilizza yes con esso). Io eseguo semplicemente una pulizia se il disco ha meno di 10 GB liberi.

1 Mi Piace
13

Ecco forse una potenziale soluzione alternativa che potrebbe funzionare per me. La sollevo qui nel caso sia utile ad altri.

Sto pensando di aggiungere un’impostazione data-root a /etc/docker/daemon.json, per vedere se ciò costringe docker a posizionare le sue immagini — le immagini di Discourse, in questo caso, dato che nient’altro è ospitato sulla macchina — in una posizione meno critica che non faccia esplodere il mio volume di avvio.

Cercando su meta thread passati su questo argomento ottengo un paio di risultati che in realtà non mi dicono molto, e prima di far collassare la mia istanza di produzione di Discourse in un mucchio fumante e fiammeggiante, volevo chiedere per vedere se questo è fattibile :slight_smile:

14

Ho adottato un approccio diverso e montato un filesystem separato su /var/lib/docker

Nel mio caso, per motivi molto specifici del sito, ho scelto filesystem separati per ciascuno di /var/discourse/shared, /var/discourse/shared/data, /var/discourse/shared/app/uploads/default/original e /var/lib/docker — ma se vuoi semplicemente avere /var/discourse come filesystem separato, potresti probabilmente creare la directory /var/discourse/share/docker e montarla su /var/lib/docker (ovviamente facendo ciò con un sistema quiescente e spostando i file secondo necessità).

4 Mi Piace
15

Questa è un’idea ancora migliore che armeggiare con il nucleo di docker. Grazie!!

1 Mi Piace
16

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.