Apprezzo questo, ma ricostruire l’app richiede circa 3 ore!
E questo su un VPS enorme.
Non sarebbe una cosa fantastica poter rimuovere i plugin proprio come possiamo aggiungere e rimuovere temi?
Forse qualcosa da considerare come funzionalità in futuro?
Grazie!!
Scusa?! Dovrebbe richiedere circa 20 minuti?!
non qui
L’installazione originale ha richiesto 2 ore.
Ora, il ./launcher rebuild app è fermo qui:
Ensuring launcher is up to date
Fetching origin
Updating Launcher...
Updating eeefdde..30be122
Fast-forward
image/base/install-imagemagick | 5 ++++-
launcher | 2 +-
templates/web.letsencrypt.ssl.template.yml | 2 +-
templates/web.template.yml | 6 +++---
4 files changed, 9 insertions(+), 6 deletions(-)
Launcher updated, restarting...
Ensuring launcher is up to date
Fetching origin
Launcher is up-to-date
Stopping old container
+ /usr/bin/docker stop -t 60 app
app
Unable to find image 'discourse/base:2.0.20220818-0047' locally
2.0.20220818-0047: Pulling from discourse/base
1efc276f4ff9: Pulling fs layer
1b880e64942b: Pulling fs layer
794f6dc9a2ff: Pulling fs layer
1efc276f4ff9: Verifying Checksum
1efc276f4ff9: Download complete
1efc276f4ff9: Pull complete
794f6dc9a2ff: Verifying Checksum
794f6dc9a2ff: Download complete
1b880e64942b: Verifying Checksum
1b880e64942b: Download complete
1b880e64942b: Pull complete
794f6dc9a2ff: Pull complete
Digest: sha256:7734701087766821ffb2ddcef423754798bd345c2ac0d550131c6e6905c268e8
Status: Downloaded newer image for discourse/base:2.0.20220818-0047
E dopo l’ultima riga, continua solo a lampeggiare (il processo è in corso)
È così da circa 30 minuti.
L’ultima volta che l’ho fatto, ci sono voluti ben 160 minuti.
Memoria totale del server: 4.657GiB, Versione del kernel: 5.15.0-43-generic, Sistema operativo: Ubuntu 22.04 LTS, disco SSD da 50GB, 2.5 Core, 5 Thread Intel® Xeon® CPU
…
Non sono sicuro di cosa possa esserci di sbagliato, a parte il fatto che richiede molto tempo 
3 ore sembrano decisamente sbagliate. Devi indagare su questo problema e risolverlo come prima priorità.
Ci sono ‘pause visive’ nel log di build, questo è normale, ma quel ritardo no.
La mia ipotesi è che in qualche modo tu stia iniziando a usare lo swap durante la build, ma non sono un SA. Stai eseguendo qualcos’altro su quella macchina?
I download richiedono la decompressione, e questo è computazionalmente costoso, ma sono le stesse immagini per tutti.
Come riferimento, ho appena ricostruito un sito proprio ora e ci sono voluti 13 minuti e 46 secondi su una macchina da 2 GB 2vCPU su https://scaleway.com
No, questo è un VPS esclusivamente per questa istanza di Discourse. E gestisco molti altri VPS con la stessa azienda, che funzionano tutti in modo impeccabile (ma non sono istanze di Discourse, sono altre app come istanze CMS PHP personalizzate o WP/CP, ecc.).
Non sono a conoscenza di alcun utilizzo di swap e non riesco a vedere picchi nell’utilizzo delle risorse che potrebbero giustificarlo.
Ora è su building.... - sembra un po’ più veloce dell’ultima volta, tuttavia, sono ancora chiaramente più di 20 minuti.
Chiederò ai fornitori del server se possono individuare qualcosa di insolito da parte loro, tuttavia, ricordo che mi hanno detto personalmente che la loro istanza Discourse ha impiegato circa 2 ore per essere creata. (PS Questi VPS sono su macchine Hetzner noleggiate tramite terzi, dubito di poter ottenere qualcosa di meglio.)
In ogni caso, il mio suggerimento rimane che sarebbe fantastico poter aggiungere e rimuovere plugin come possiamo fare con i temi. Forse è qualcosa da considerare?
Non ne so molto, ma per quanto ne so non è possibile, perché Discourse è composto da molti javascript compilati. Quando c’è bisogno di aggiungere o rimuovere qualcosa che cambia il modo in cui il core agisce e funziona, è necessario ricostruire.
Situazione molto simile a quella di Varnish, ad esempio.
Ok…
A proposito, ho verificato con il personale del server e in effetti abbiamo raggiunto il 100% di memoria
5 GB ??? 5 GB di RAM sono un po’ troppi da consumare per qualsiasi cosa.
I requisiti di Discourse dicono che necessita di 1 GB di RAM!
Ed ora è bloccato su quanto segue:
104:M 04 Oct 2022 07:19:27.251 # Redis è ora pronto per uscire, arrivederci...
sha256:662695076506add39a630c2169b8b618f0121386951e93c6ffd2a6473107ae55
f4a95a1e69d5375e6ea30dfb22576209d249e5bc67b04a6fa09df289b1441888
Rimozione del vecchio container
+ /usr/bin/docker rm app
app
Pertanto non posso nemmeno aggiornare il server poiché il processo verrebbe interrotto.
Davvero, non penso che questo sia affatto un problema del server. Se abbiamo bisogno di 1 GB, allora 5 GB dovrebbero essere più che sufficienti.
C’è qualcosa che non va in questo, enormemente sbagliato.
Capisco che altri debbano avere un’esperienza migliore (guardando @merefield che ha detto di aggiornare su un 2 GB…) eppure non sta funzionando per noi come dovrebbe.
Comunque, credo che questo sia fuori tema per questo thread.
Ho appena ricostruito un altro sito, 4 GB, 3 vCPU, di nuovo \u003c 15 minuti (cioè la memoria/CPU extra non ha aiutato molto nel mio caso, ma ancora lontano da ore!).
L’unica cosa che ho notato è che il mio VPS utilizza vfs invece dei suggeriti aufs o overlay.
Tuttavia, secondo questo Can't run ./launcher rebuild app - Docker storage driver is unsupported - #45 by david, non dovrebbe essere nulla di importante, e quindi eseguiamo il launcher con --skip-prereqs, perché altrimenti non possiamo nemmeno eseguire Discourse.
Mi chiedo se ci sia di più riguardo a questo requisito del driver di archiviazione.
Questo è un po’… troppo ottimista. A scopo di test può essere sufficiente, e anche in quel caso può essere un po’ limitato. 2 GB è molto più vicino alla realtà.
4 GB sono sufficienti per istanze più grandi, comunque. Ma anche il numero e la potenza dei core giocano un ruolo importante.
E comunque… se hai 5 GB e la ricostruzione richiede così tanto tempo, ci deve essere qualcosa che non va.
Io sono su DigitalOcean/4 GB/2 vCPU Intel e la ricostruzione richiede circa 25 minuti.
Qual è esattamente il tuo sistema, più app.yml — c’è qualcosa di personalizzato?
Ciao, l’unica personalizzazione è quella che ho menzionato prima (vfs invece di aufs/overlay)
Il resto è vanilla.
Server:
Memoria totale del server: 4.657GiB, Versione del kernel: 5.15.0-43-generic, Sistema operativo: Ubuntu 22.04 LTS, disco SSD da 50 GB, 2,5 core, 5 thread Intel® Xeon® CPUs
yaml è originale a parte questi plugin aggiuntivi:
discourse-assign
discourse-chat
discourse-checklist
discourse-docs
discourse-reactions
discourse-solved
discourse-surveys
discourse-voting
docker_manager
styleguide
Non vedo da quei dati perché la ricostruzione richiederebbe così tanto tempo.
Mi verrebbe da fare un’istanza su un VPS Ubuntu di pari dimensioni da qualche altra parte. Giusto per scoprire se il problema proviene dalla società di hosting. Ti costa pochi euro e un’ora o due di lavoro.
È necessaria molta memoria per precompilare javascript. Prova ad aggiungere lo swap.
Il layer
Penso che quel test possa esserci per un motivo. Questo potrebbe essere il tuo problema.
Perché 5 GB di RAM con Discourse vanilla avrebbero bisogno di più swap se quelli più piccoli sono totalmente soddisfatti di ciò che hanno ottenuto automaticamente?
Perché è più facile che fare ciò che devi veramente fare.
L’aggiunta di swap potrebbe aiutare, ma non è il tuo problema più grande.
Presumo che avrei dovuto provare questo prima di distribuire il container discourse: How to change the Docker storage driver – Webdock
Apparentemente è possibile cambiare il driver di archiviazione - contrariamente a quanto mi ha indicato l’host quando abbiamo distribuito il container (che era di modificare il file del loader o ignorare il controllo)
Duh, ora è troppo tardi, immagino.
Grazie comunque, se questa è la causa dei problemi, suppongo sia colpa dell’utente. Mea culpa 
Non lo penserei.
Inoltre, la configurazione a due container ha ridotto i tempi di inattività poiché ricostruisci il nuovo container web mentre quello vecchio continua a funzionare.
Quanto è grande il tuo sito? Aggiungerei comunque lo swap per risolvere il problema della memoria.
Un’istanza vuota da 1 GB con 1 GB di swap funziona bene per una piccola community di test, ma non appena cresce non sarà sufficiente. Lo swap fa assolutamente la differenza.
Se ricostruire su un VPS “enorme”, situato in un data center con una connessione internet veloce, richiede 3 ore, e ricostruire la mia installazione su https://discourse-on-a-pi.falco.dev che gira su una scheda delle dimensioni di una carta di credito sulla mia scrivania, collegata a internet tramite un piano domestico standard in un paese del terzo mondo richiede solo 14 minuti (+4 minuti quando c’è una nuova immagine del container) c’è qualcosa che non va nel prodotto che ti stanno vendendo…
Come è l’utilizzo della memoria sul server? Se sei al limite o vicino alla capacità prima di iniziare la ricostruzione, avrai molto swapping e ciò renderà sicuramente tutto eccessivamente lungo.
Se questo è il caso, ti suggerirei di disabilitare temporaneamente qualsiasi altra cosa che potrebbe essere in esecuzione sul server, se possibile.