ich stehe kurz vor dem Upgrade unseres Discourse-Produktionsservers (wir betreiben ihn selbst auf EC2 gemäß den offiziellen Installationsanweisungen) und möchte das empfohlene Vorgehen bestätigen.
Der Upgrade-Button ist in der Benutzeroberfläche nicht aktiviert, daher wird das Upgrade auf der EC2-Instanz durchgeführt. Ich gehe davon aus, dass es zwei Hauptmethoden dafür gibt:
Neuaufbau unseres EC2-Servers, der eine frische Kopie des discourse_docker GitHub-Repositories zieht und die dortigen Vorlagen verwendet. Beispielsweise verweist web.template.yml derzeit auf das Basis-Image discourse/base:2.0.20260209-1300. Dieser Ansatz würde den aktuell laufenden Server entfernen und den neuen starten.
Anmeldung auf dem bestehenden EC2-Server und Ausführung der folgenden Befehle zum Neuaufbau des aktuellen Images und Neustart des Containers:
./launcher rebuild app
Ich habe zwei Fragen:
Welcher Ansatz sollte für die normale Wartung verwendet werden?
Wenn wir den Befehl rebuild app ausführen, wird dann immer noch der main-Branch für das discourse_docker-Repository gezogen?
Ich habe die Seite https://releases.discourse.org gelesen und kann sehen, dass Version 2026.3.0 noch nicht veröffentlicht ist. Mein Verständnis ist, dass wir in der Produktion nicht die neuesten main-Versionen einer Release-Zweiglinie verwenden sollten, da diese sich noch in der aktiven Entwicklung befinden.
Wenn Sie auf die neueste Version aktualisieren möchten, reicht ein manuelles Update über das Admin-Backend aus.
Wenn Sie auf die esr-Version aktualisieren möchten, geben Sie einfach esr am Ende der Datei containers/app.yml an:
params:
version: esr
Anschließend neu bauen.
Stellen Sie sicher, dass das Netzwerk einwandfrei funktioniert.
Bedeutet das Setzen der Version auf esr, dass das in den Vorlagen verwendete Basis-Image überschrieben wird?
Wir möchten, dass das Upgrade in der Admin-Oberfläche nicht aktiviert ist, und benötigen daher eine Möglichkeit, dies entweder in der Instanz zu steuern oder die Instanz einfach neu zu erstellen und unser AutoScaler dies verwalten zu lassen.
Wenn wir esr verwenden, wie erfolgt dann das Update, wenn ein kritischer Fix bereitgestellt wird? Müssen wir auch hier einfach monatlich über den Launcher eine neue EC2-Instanz erstellen, um alle Updates für die esr-Version zu integrieren?
Haben Sie Understanding Discourse release channels und Configure a supported tracking branch to get Discourse software updates gelesen? Ich würde den Unterschied eher so beschreiben: Entweder haben Sie sofort Zugriff auf die neuesten Änderungen oder Sie erhalten sie etwas später. Letzteres kann bei benutzerdefinierten Entwicklungen, die zunächst angepasst werden müssen, sehr hilfreich sein. Ansonsten würde ich den Zugriff auf die neuesten Funktionen und Fehlerbehebungen bevorzugen. Natürlich birgt dies das Risiko neuer Fehler, aber auch die Version, die vor drei Wochen eingefroren wurde, enthält Fehler, die möglicherweise bereits in der neuesten Version behoben wurden, jedoch in der Regel nicht schwerwiegend genug, um eine Zurückportierung auf die letzte Veröffentlichung zu rechtfertigen.
Denken Sie auch daran, dass ein Downgrade nicht unterstützt wird. Wenn Sie sich also auf einer Version nach dem aktuellen ESR befinden, müssen Sie warten, bis der nächste ESR veröffentlicht wird.