Ich bin für eine auf Docker basierende Discourse-Installation auf Ubuntu verantwortlich, die ich im Rahmen eines Open-Source-Projekts übernommen habe. Seit Jahren habe ich sie über git pull && ./launcher rebuild app und anschließend über die Admin-Oberfläche unter /admin/update aktualisiert. Nach einer schmerzhaften Erfahrung während eines brechenden Upgrades aufgrund von docker_manager im Januar 2024 (siehe die Kommentare zum Commit hier und den zurückgenommenen Commit hier) habe ich es aber gelassen, so beiläufig zu aktualisieren.
Es sind nun 2,5 Jahre vergangen, und ich muss wieder in den Takt der Aktualisierungen finden, aber nach dem letzten kaputten Upgrade bin ich noch etwas nervös. Ich bräuchte Hilfe, um zu verstehen, was ich wissen sollte, bevor ich versuche, von v3.4.0 auf v2026.7.2 zu aktualisieren. Unsere Seite verwendet keine zusätzlichen Plugins, und die einzige mir bekannte Sonderkonfiguration ist, dass wir eine Discourse-Connect-URL verwenden, um SSO mit unserer Hauptcommunity-Seite zu haben.
Ist es so einfach wie?
cd /var/discourse
git pull
./launcher rebuild app
Und dann die Aktualisierung über die Admin-Oberfläche? Gibt es bei der Aktualisierung von v3.4.0 auf v2026.7.2 Zwischenstufen, die ich beachten muss?
Oder … (falls du nervös bist) … erstelle ein Backup (das solltest du ohnehin tun) und richte einen komplett neuen Server ein, auf den du das Backup wiederherstellst. Danach kannst du die Domain auf den neuen Server umleiten.
Das eine große Thema, auf das du stoßen wirst, ist der große Postgres-Update auf Version 18. Wenn du einen neuen Server aufbaust, musst du dich nicht mit diesem Update-Prozess herumschlagen.
Darüber hinaus besteht ein kleines Risiko, dass Plugins oder Theme-Komponenten, auf die du dich verlässt, nicht mehr gewartet werden, insbesondere wenn sie von weniger aktiven Drittanbietern stammen.
Genau aus Nervosität nutzen erfahrene Discourse-Systemadministratoren eine Zwei-Container-Konfiguration, damit sie Updates vor dem endgültigen Abschluss testen können (wobei das bei einem großen Postgres-Update weniger hilft, aber solche Updates kommen selten vor).
Ich habe heute die Migration versucht und bin sofort wieder auf eine Breaking Change im Hauptzweig von discourse_docker gestoßen:
Dieser Commit führt zu Build-Fehlern und bricht die Installation bzw. Einrichtung, wurde aber trotzdem in den Hauptzweig übernommen. Genau davor hatte ich mir Sorgen gemacht.
Bei der Ausführung von ./launcher bootstrap app kommt es zu folgendem Fehler:
rake aborted!
Don't know how to build task 'assets:precompile:pretty_text' (See the list of available tasks with `rake --tasks`)
Did you mean? assets:precompile
Wie kann es sein, dass Breaking Changes wie diese in den Hauptzweig übernommen werden, der Teil der offiziellen Installationsanweisungen ist? Werden Build-Fehler ignoriert? Der gleiche Fehler, den ich sehe, steht doch direkt im Fehlerprotokoll:
Ich konnte auf einen früheren Commit zurückwechseln, um die Migrationsschritte fortzusetzen, aber jetzt sind bereits zwei aufeinanderfolgende Upgrades durch ungetestete Commits, die in den Hauptzweig übernommen wurden, kaputtgegangen.
Hey @corywright, sorry for that – Der aktuelle ESR hat den Job nicht, der Patch ist hier in Arbeit.
Wir werden es bald beheben, und ich werde sicherstellen, dass das ESR-Ziel als Smoke-Test-Ziel hinzugefügt wird, um zukünftige Regressionen zu verhindern.
Nochmals vielen Dank, dass du diese Option statt einer In-Place-Aktualisierung vorgeschlagen hast. Das hat sich deutlich besser bewährt und mir ermöglicht, mit einer frischen Kopie eines neuen Betriebssystems zu starten.
