Quando si aggiorna tramite l’aggiornatore dell’interfaccia utente nella sezione di amministrazione, l’operazione fallisce sempre. È fallita da quando ho installato Discourse più di un anno fa. Posso accedere facilmente al mio server tramite SSH e aggiornare manualmente, ma è frustrante avere una funzionalità che non si comporta correttamente.
Dato che Discourse è eseguito con Docker e non ho una forte conoscenza di esso, vorrei sapere se qualcun altro ha riscontrato problemi simili e come posso risolverlo.
In breve: l’aggiornatore dell’interfaccia utente fallisce sempre, la riga di comando funziona al primo tentativo e vorrei risolverlo in modo da non dover accedere al server tramite SSH (così spesso).
Mi rendo conto, dopo aver fatto qualche ricerca, che potrebbe essere che io stia usando la quantità minima di RAM raccomandata, ma questa è per un’installazione privata con meno di 50 utenti, quindi non ho davvero bisogno di superare il minimo per il mio caso d’uso.
Prima riuscivo a fare un aggiornamento con 2G di RAM + 2G di swap, ma credo fosse prima di Ember, che è molto esigente. Se hai spazio su disco per aumentare lo swap a 4G, potrebbe funzionare. Oppure, migra temporaneamente e con attenzione a un’istanza con più RAM, esegui l’aggiornamento e migra di nuovo indietro.
Qualunque cosa tu faccia, fai un backup e scaricalo prima.
Nel mercato statunitense, sia Contabo che IONOS consentono l’inbound sulla porta 25, fondamentale per le configurazioni di mail-receiver, quindi non ci sono limitazioni funzionali in tal senso.
La vera differenza risiede nella reputazione di affidabilità e supporto:
Contabo (Trustpilot 4.2/5, ~6.700 recensioni) offre prezzi aggressivi e specifiche elevate, ma gli utenti statunitensi segnalano spesso latenza elevata, tempi di risposta del supporto più lenti e instabilità delle prestazioni, soprattutto sotto carico. I data center statunitensi di Contabo esistono, ma non sono sempre reattivi come previsto.
IONOS (Trustpilot 4.5/5, ~31.000 recensioni) offre prestazioni negli Stati Uniti migliori di quanto molti presumano. Ha una reputazione di supporto più solida e un’infrastruttura più affidabile, con meno recensioni a 1 stella (~10% rispetto al 16% di Contabo). Gli utenti segnalano costantemente un migliore uptime, supporto live e gestione dell’account rispetto a Contabo.
Conclusione (USA):
Se ti trovi negli Stati Uniti e hai bisogno di stabilità, supporto rapido e basso rischio per carichi di lavoro di produzione, IONOS è la scelta più sicura. Contabo potrebbe ancora valere la pena considerarlo per ambienti di sviluppo/test o deploy sensibili ai costi, ma aspettati compromessi in termini di latenza e qualità del supporto.
Anche il mio ha iniziato a farlo, perfettamente funzionante per oltre 4 anni e ora fallisce. A volte afferma che fallisce, ma quando aggiorno tutto è aggiornato e non c’è più nulla da aggiornare. Ma quasi sempre finisce con
ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL Comando terminato con SIGKILL (Terminazione forzata): ember build -prod /var/www/discourse/script/assemble_ember_build.rb:103:in `system': Comando fallito con uscita 1: pnpm (RuntimeError) from /var/www/discourse/script/assemble_ember_build.rb:103:in `<main>' Docker Manager: AGGIORNAMENTO FALLITO
Nella quasi totalità dei casi, sarebbe molto utile visualizzare le 50-200 righe precedenti dell’output. È un peccato che gli script non lo suggeriscano.
Era quello che mi stavo chiedendo: se fosse collegato a un problema con il codice stesso e non tanto con l’hardware del mio server.
Suppongo che la mia prossima possibilità sia semplicemente scrivere il mio plugin con uno script per aggiornarmi manualmente.
Sono contento che altri abbiano lo stesso problema, così non sono solo io (so che fa schifo). Forse qualcuno che sviluppa attivamente con Discourse può indagare. Vorrei anche che ci fossero informazioni di debug migliori, più che il semplice “fallisce”.
Non sono uno sviluppatore né un esperto di server e cose del genere. Ho scelto Digital Ocean, solo perché era quello menzionato nelle istruzioni ufficiali di installazione, e perché ho visto quel nome menzionato più e più volte nel corso degli anni.
Al momento sono sul secondo piano più basso, che costa $6 al mese per un server che sembra essere molto “più lento” di quelli offerti da Contabo o IONOS. Poiché il minimo per una buona performance di Discourse è almeno 2GB di RAM, dovrei passare al piano da $12. Per il Contabo a $4,95 al mese, otterrei 8GB… è una “piccola” differenza sia nel prezzo che nella RAM, per non parlare dello spazio su disco, ecc.
Quindi, chiedendo a voi e ad altri utenti esperti, ha senso migrare il mio Discourse a Contabo, ad esempio, invece di rimanere con Digital Ocean? Anche se sto ancora costruendo l’intera community e tutto il resto, finora DO è stato ok, a parte il problema dell’aggiornamento di Discourse sul web, anche con uno swapfile di 4GB (perché il mio spazio su disco è solo 25GB), ma non voglio migrare tutto per poi iniziare a notare altri problemi.
Ho trovato questa pagina, ma non sono sicuro di quanto siano affidabili questi test e se siano sufficienti per farmi cambiare?
Qualsiasi feedback sarebbe molto apprezzato!
Grazie!
********************************************************
*** Siate pazienti, i prossimi passaggi potrebbero richiedere tempo ***
********************************************************
Cycling Unicorn, per liberare memoria
Riavvio del pid di Unicorn: 1580
In attesa del ricaricamento di Unicorn.
In attesa del ricaricamento di Unicorn..
In attesa del ricaricamento di Unicorn...
In attesa del ricaricamento di Unicorn....
In attesa del ricaricamento di Unicorn.....
In attesa del ricaricamento di Unicorn......
In attesa del ricaricamento di Unicorn.......
In attesa del ricaricamento di Unicorn........
In attesa del ricaricamento di Unicorn.........
In attesa del ricaricamento di Unicorn..........
In attesa del ricaricamento di Unicorn...........
In attesa del ricaricamento di Unicorn............
In attesa del ricaricamento di Unicorn.............
In attesa del ricaricamento di Unicorn..............
Arresto di 1 worker Unicorn, per liberare memoria
Arresto della coda di lavoro per recuperare memoria, pid master è 1585
$ cd /var/www/discourse && git fetch --tags --prune-tags --prune --force
$ cd /var/www/discourse && git reset --hard HEAD@{upstream}
HEAD è ora a 20ff23ed0 DEV: rimozione traduzioni ridondanti per il pulsante nuovo argomento disabilitato (#33929)
$ bundle install --retry 3 --jobs 4
Bundle completato! 160 dipendenze Gemfile, 207 gemme ora installate.
Le gemme nei gruppi 'test' e 'development' non sono state installate.
Le gemme bundle sono installate in `./vendor/bundle`
3 gemme installate di cui dipendi direttamente stanno cercando finanziamenti.
Esegui `bundle fund` per i dettagli
$ if [ -f yarn.lock ]; then yarn install; else CI=1 pnpm install; fi
Scope: tutti i 16 progetti workspace
Il file di lock è aggiornato, il passaggio di risoluzione è saltato
Già aggiornato
Fatto in 2.9s usando pnpm v9.15.9
$ LOAD_PLUGINS=0 bundle exec rake plugin:pull_compatible_all
discourse-custom-wizard è già alla versione compatibile più recente
docker_manager è già alla versione compatibile più recente
$ SKIP_POST_DEPLOYMENT_MIGRATIONS=1 bundle exec rake multisite:migrate
Il migratore multisite è in esecuzione utilizzando 1 thread
Migrazione predefinita
Popolamento predefinito
*** Bundle delle risorse. Questo richiederà del tempo ***
$ bundle exec rake themes:update assets:precompile
Aggiornamento dei temi con concorrenza: 10
[db:default] 'Air Theme' - controllo...
[db:default] 'Air Theme' - aggiornato
[db:default] 'Modern Category + Group Boxes' - controllo...
[db:default] 'Modern Category + Group Boxes' - aggiornato
[db:default] 'Clickable Topic' - controllo...
[db:default] 'Clickable Topic' - aggiornato
[db:default] 'Search Banner' - controllo...
Il limite di dimensione heap di Node.js è inferiore a 2048MB. Impostazione di --max-old-space-size=2048 e CHEAP_SOURCE_MAPS=1
La build esistente non è riutilizzabile.
- Esistente: {"ember_env"=>"production", "core_tree_hash"=>"cd74e4ac33647244c041061633d6ca67f9166e5c"}
- Corrente: {"ember_env"=>"production", "core_tree_hash"=>"7ac67590cc51e22690a2711b593892cd1d266781"}
Esecuzione della build core completa...
Costruzione
Ambiente: production
L'impostazione 'staticAddonTrees' sarà impostata su true per impostazione predefinita nella prossima versione di Embroider e non potrà essere disattivata. Per prepararti a questo, dovresti impostare 'staticAddonTrees: true' nella tua configurazione di Embroider.
L'impostazione 'staticAddonTestSupportTrees' sarà impostata su true per impostazione predefinita nella prossima versione di Embroider e non potrà essere disattivata. Per prepararti a questo, dovresti impostare 'staticAddonTestSupportTrees: true' nella tua configurazione di Embroider.
costruzione...
...[ConfigLoader]
...[Babel: @embroider/macros > applyPatches]
...[Babel: @ember/legacy-built-in-components > applyPatches]
...[Babel: ember-source > applyPatches]
[BABEL] Nota: Il generatore di codice ha deottimizzato lo styling di /var/www/discourse/app/assets/javascripts/discourse/ember/ember-template-compiler.js poiché supera il massimo di 500KB.
[BABEL] Nota: Il generatore di codice ha deottimizzato lo styling di /var/www/discourse/app/assets/javascripts/discourse/ember/ember.js poiché supera il massimo di 500KB.
...[Babel: @glimmer/component > applyPatches]
...[Babel: @ember/test-waiters > applyPatches]
...[Babel: ember-this-fallback > applyPatches]
...[Babel: ember-cache-primitive-polyfill > applyPatches]
...[Babel: select-kit > applyPatches]
...[@embroider/compat/app]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
...[@embroider/webpack]
undefined
ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL Comando terminato con SIGKILL (Terminazione forzata): ember build -prod
/var/www/discourse/script/assemble_ember_build.rb:103:in `system': Comando fallito con uscita 1: pnpm (RuntimeError)
from /var/www/discourse/script/assemble_ember_build.rb:103:in `<main>'
Docker Manager: AGGIORNAMENTO FALLITO
#<RuntimeError: RuntimeError>
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:211:in `run'
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:112:in `upgrade'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:19:in `block in <main>'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `fork'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `<main>'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands/runner/runner_command.rb:44:in `load'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands/runner/runner_command.rb:44:in `block in perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-8.0.2/lib/active_support/execution_wrapper.rb:91:in `wrap'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands/runner/runner_command.rb:70:in `conditional_executor'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands/runner/runner_command.rb:43:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/thor-1.4.0/lib/thor/command.rb:28:in `run'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/thor-1.4.0/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command/base.rb:178:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/thor-1.4.0/lib/thor.rb:538:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command/base.rb:73:in `perform'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command.rb:65:in `block in invoke'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command.rb:143:in `with_argv'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/command.rb:63:in `invoke'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/railties-8.0.2/lib/rails/commands.rb:18:in `<main>'
/usr/local/lib/ruby/3.3.0/bundled_gems.rb:69:in `require'
/usr/local/lib/ruby/3.3.0/bundled_gems.rb:69:in `block (2 levels) in replace_require'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/bootsnap-1.18.6/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in `require'
bin/rails:18:in `<main>'
Avvio di 1 worker Unicorn che erano stati fermati inizialmente
sia nel prezzo che nella RAM, per non parlare dello spazio su disco, ecc.