Beim Aktualisieren über den UI-Updater im Admin-Bereich schlägt es immer fehl. Es schlägt fehl, seit ich Discourse vor über einem Jahr installiert habe. Ich kann mich problemlos per SSH auf meinen Server einloggen und manuell aktualisieren, aber es ist frustrierend, eine Funktion zu haben, die nicht richtig funktioniert.
Da Discourse mit Docker läuft und ich mich damit nicht gut auskenne, möchte ich wissen, ob andere ähnliche Probleme haben und wie ich es beheben kann.
Kurz gesagt: UI-Updater schlägt immer fehl, Kommandozeile funktioniert auf Anhieb und ich möchte es so beheben, dass ich mich nicht (so oft) per SSH auf den Server einloggen muss.
Ich stelle fest, dass ich nach einiger Recherche möglicherweise die minimale RAM-Menge verwende, aber dies ist für eine private Installation mit weniger als 50 Benutzern, daher muss ich für meinen Anwendungsfall wirklich nicht über das Minimum hinausgehen.
Ich konnte früher ein Update mit 2G RAM + 2G Swap durchführen, aber das war, glaube ich, vor Ember, das sehr anspruchsvoll ist. Wenn Sie genügend Festplattenspeicher haben, um auf 4G Swap zu gehen, könnte das helfen. Oder migrieren Sie vorübergehend und vorsichtig zu einer Instanz mit mehr RAM, führen Sie das Update durch und migrieren Sie zurück.
Was auch immer Sie tun, machen Sie ein Backup und laden Sie es zuerst herunter.
Ich hatte früher 2 GB RAM und 40 GB Festplattenspeicher und habe mich darauf verlassen, dass .\discourse-setup den Swap konfiguriert. Web-UI-Updates waren langsam.
Im US-Markt erlauben sowohl Contabo als auch IONOS den eingehenden Port 25, was für #mail-receiver-Konfigurationen entscheidend ist – es gibt also keine funktionale Einschränkung.
Der eigentliche Unterschied liegt in der Zuverlässigkeit und dem Ruf des Supports:
Contabo (Trustpilot 4,2/5, ~6.700 Bewertungen) bietet aggressive Preise und hohe Spezifikationen, aber US-Nutzer berichten häufig von hoher Latenz, langsamerer Reaktionszeit des Supports und Leistungsschwankungen, insbesondere unter Last. Contabos US-Rechenzentren existieren, sind aber nicht immer so reaktionsschnell wie erwartet.
IONOS (Trustpilot 4,5/5, ~31.000 Bewertungen) schneidet in den USA besser ab, als viele annehmen. Es hat einen besseren Ruf für den Support und eine zuverlässigere Infrastruktur mit weniger 1-Sterne-Bewertungen (~10 % gegenüber Contabos 16 %). Nutzer berichten durchweg von besserer Verfügbarkeit, Live-Support und Kontoverwaltung im Vergleich zu Contabo.
Fazit (USA):
Wenn Sie in den USA ansässig sind und Stabilität, schnellen Support und geringes Risiko für Produktions-Workloads benötigen, ist IONOS die sicherere Wahl. Contabo kann immer noch für Entwicklungs-/Testumgebungen oder kostensensitive Bereitstellungen in Betracht gezogen werden, aber rechnen Sie mit Kompromissen bei Latenz und Supportqualität.
Meiner fing auch damit an, über 4 Jahre lang völlig in Ordnung, jetzt schlägt es fehl. Manchmal behauptet es zwar, dass es fehlschlägt, aber wenn ich aktualisiere, ist alles auf dem neuesten Stand und es gibt nichts mehr zu aktualisieren. Aber es endet fast immer mit
ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL Befehl wurde mit SIGKILL (Erzwungene Beendigung) beendet: ember build -prod /var/www/discourse/script/assemble_ember_build.rb:103:in `system': Befehl fehlgeschlagen mit Exit 1: pnpm (RuntimeError) vom /var/www/discourse/script/assemble_ember_build.rb:103:in `<main>' Docker Manager: UPGRADE FEHLGESCHLAGEN
In fast allen Fällen wäre es sehr hilfreich, die vorherigen 50 bis 200 Zeilen der Ausgabe zu sehen. Es ist schade, dass die Skripte dies nicht empfehlen.
Das habe ich mich auch gefragt – ob es mit einem Problem im Code selbst zusammenhängt und nicht so sehr mit der Hardware meines Servers.
Ich schätze, meine nächste Möglichkeit ist, mein eigenes Plugin mit einem Skript zu schreiben, um mich selbst manuell zu aktualisieren.
Ich bin froh, dass andere das gleiche Problem haben, sodass ich nicht der Einzige bin (ich weiß, es ist ätzend). Vielleicht kann sich jemand, der aktiv mit Discourse entwickelt, darum kümmern. Ich wünschte auch, es gäbe bessere Debugging-Informationen, mehr als nur, dass es „fehlschlägt“.
Ich bin kein Entwickler oder Experte, wenn es um Server und all das geht. Ich habe mich für Digital Ocean entschieden, einfach weil es dasjenige war, das in den offiziellen Installationsanleitungen erwähnt wurde, und weil ich diesen Namen im Laufe der Jahre immer wieder gehört habe.
Im Moment bin ich auf dem zweitniedrigsten Plan, der 6 US-Dollar pro Monat für einen Server kostet, der viel „langsamer“ zu sein scheint als die von Contabo oder IONOS angebotenen. Da das Minimum für eine gute Discourse-Leistung mindestens 2 GB RAM beträgt, müsste ich auf den 12-Dollar-Plan upgraden. Für die Contabo $4,95 pro Monat würde ich 8 GB bekommen… das ist ein „kleiner“ Unterschied sowohl beim Preis als auch beim RAM, ganz zu schweigen vom Speicherplatz usw.
Macht es also Sinn, dass ich meine Discourse-Installation zu Contabo migriere, anstatt bei Digital Ocean zu bleiben? Auch wenn ich noch die ganze Community aufbaue und so weiter, war DO bisher in Ordnung, abgesehen von dem Problem beim Aktualisieren von Discourse im Web, selbst mit einer Swap-Datei von 4 GB (weil mein Speicherplatz nur 25 GB beträgt), aber ich möchte nicht alles migrieren, um dann andere Probleme zu bemerken.
Ich habe diese Seite gefunden, aber ich bin mir nicht sicher, wie zuverlässig diese Tests wirklich sind und ob sie ausreichen, um mich zum Wechsel zu bewegen?
********************************************************
*** Bitte haben Sie Geduld, die nächsten Schritte können eine Weile dauern ***
********************************************************
Cycling Unicorn, um Speicher freizugeben
Starte Unicorn-Prozess neu: 1580
Warte auf das Neuladen von Unicorn.
Warte auf das Neuladen von Unicorn..
Warte auf das Neuladen von Unicorn...
Warte auf das Neuladen von Unicorn....
Warte auf das Neuladen von Unicorn.....
Warte auf das Neuladen von Unicorn......
Warte auf das Neuladen von Unicorn.......
Warte auf das Neuladen von Unicorn........
Warte auf das Neuladen von Unicorn.........
Warte auf das Neuladen von Unicorn..........
Warte auf das Neuladen von Unicorn...........
Warte auf das Neuladen von Unicorn............
Warte auf das Neuladen von Unicorn.............
Warte auf das Neuladen von Unicorn..............
Stoppe 1 Unicorn-Worker, um Speicher freizugeben
Stoppe die Job-Warteschlange, um Speicher freizugeben, Master-Prozess ist 1585
$ cd /var/www/discourse && git fetch --tags --prune-tags --prune --force
$ cd /var/www/discourse && git reset --hard HEAD@{upstream}
HEAD ist jetzt bei 20ff23ed0 DEV: Entferne redundante Übersetzungen für deaktivierten neuen Themen-Button (#33929)
$ bundle install --retry 3 --jobs 4
Bundle abgeschlossen! 160 Gemfile-Abhängigkeiten, 207 Gems jetzt installiert.
Gems in den Gruppen 'test' und 'development' wurden nicht installiert.
Gebündelte Gems sind in `./vendor/bundle` installiert
3 direkt von Ihnen abhängige installierte Gems suchen nach Finanzierung.
Führen Sie `bundle fund` für Details aus
$ if [ -f yarn.lock ]; then yarn install; else CI=1 pnpm install; fi
Scope: alle 16 Workspace-Projekte
Lockfile ist aktuell, der Auflösungsschritt wird übersprungen
Bereits aktuell
Fertig in 2,9s mit pnpm v9.15.9
$ LOAD_PLUGINS=0 bundle exec rake plugin:pull_compatible_all
discourse-custom-wizard ist bereits in der neuesten kompatiblen Version
docker_manager ist bereits in der neuesten kompatiblen Version
$ SKIP_POST_DEPLOYMENT_MIGRATIONS=1 bundle exec rake multisite:migrate
Multisite-Migrator läuft mit 1 Threads
Migriere Standard
Standard-Seeding
*** Assets werden gebündelt. Dies dauert eine Weile ***
$ bundle exec rake themes:update assets:precompile
Themes werden mit Konkurrenz: 10 aktualisiert
[db:default] 'Air Theme' - wird geprüft...
[db:default] 'Air Theme' - aktuell
[db:default] 'Modern Category + Group Boxes' - wird geprüft...
[db:default] 'Modern Category + Group Boxes' - aktuell
[db:default] 'Clickable Topic' - wird geprüft...
[db:default] 'Clickable Topic' - aktuell
[db:default] 'Search Banner' - wird geprüft...
Node.js heap_size_limit ist kleiner als 2048MB. Setze --max-old-space-size=2048 und CHEAP_SOURCE_MAPS=1
Vorhandener Build ist nicht wiederverwendbar.
- Vorhanden: {"ember_env"=>"production", "core_tree_hash"=>"cd74e4ac33647244c041061633d6ca67f9166e5c"}
- Aktuell: {"ember_env"=>"production", "core_tree_hash"=>"7ac67590cc51e22690a2711b593892cd1d266781"}
Führe vollständigen Kern-Build aus...
Bauen
Umgebung: production
Die Einstellung 'staticAddonTrees' wird in der nächsten Version von Embroider standardmäßig auf true gesetzt und kann nicht deaktiviert werden. Um sich darauf vorzubereiten, sollten Sie 'staticAddonTrees: true' in Ihrer Embroider-Konfiguration festlegen.
Die Einstellung 'staticAddonTestSupportTrees' wird in der nächsten Version von Embroider standardmäßig auf true gesetzt und kann nicht deaktiviert werden. Um sich darauf vorzubereiten, sollten Sie 'staticAddonTestSupportTrees: true' in Ihrer Embroider-Konfiguration festlegen.
bauen...
...[ConfigLoader]
...[Babel: @embroider/macros > applyPatches]
...[Babel: @ember/legacy-built-in-components > applyPatches]
...[Babel: ember-source > applyPatches]
[BABEL] Hinweis: Der Code-Generator hat das Styling von /var/www/discourse/app/assets/javascripts/discourse/ember/ember-template-compiler.js deoptimiert, da es das Maximum von 500KB überschreitet.
[BABEL] Hinweis: Der Code-Generator hat das Styling von /var/www/discourse/app/assets/javascripts/discourse/ember/ember.js deoptimiert, da es das Maximum von 500KB überschreitet.
...[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 Befehl wurde mit SIGKILL (erzwungene Beendigung) beendet: ember build -prod
/var/www/discourse/script/assemble_ember_build.rb:103:in `system': Befehl fehlgeschlagen mit Exit 1: pnpm (RuntimeError)
from /var/www/discourse/script/assemble_ember_build.rb:103:in `<main>'
Docker Manager: UPGRADE FEHLGESCHLAGEN
#<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>'
Starte 1 Unicorn-Worker, die anfangs gestoppt wurden
sowohl beim Preis als auch beim RAM, ganz zu schweigen vom Speicherplatz usw.