Ich habe eine etwas ältere Version von Discourse-Containern und die Discourse-Docker-Dateien von einer laufenden Instanz exportiert und auf einem anderen Server importiert.
Ich muss den Discourse-Hostnamen ändern, damit er zum neuen Server passt.
Gibt es eine Möglichkeit, den neuen DISCOURSE_HOSTNAME: ohne einen Neubau wirksam zu machen?
Wenn ich neu bauen muss, wird dann die neueste Version aus dem main-Branch abgerufen und die aktuelle Version, die ich habe, überschrieben? Denn ich muss genau die aktuelle Version ausführen.
Sie müssten Dinge in der Let’s Encrypt-Konfiguration ändern, was (zumindest teilweise) der Grund dafür ist, dass Sie neu erstellen müssen.
Warum nicht upgraden? Das ist es, was Sie wirklich tun müssen. Wie alt ist es denn?
Aber Sie könnten versuchen, discourse_docker (auch bekannt als /var/discourse und die Discourse-Version, auf der Sie sich befinden) zu pinnen. Möglicherweise müssen Sie auch alle Plugins pinnen.
Wenn Sie etwas anderes haben, das die HTTPS-Auflösung durchführt, können Sie möglicherweise den Rebuild vermeiden und nur die anderen Dinge in Change the domain name or rename your Discourse tun.
Ich muss dieselbe Version auf dieser Instanz haben, um das Upgrade auf die neueste Version zu testen. Wenn dies erfolgreich ist, werde ich das Upgrade auf der Produktionsumgebung durchführen.
Wenn Sie etwas anderes haben, das die HTTPS-Auflösung durchführt, können Sie möglicherweise den Rebuild vermeiden und die anderen Dinge in Ändern Sie den Domainnamen oder benennen Sie Ihr Discourse um tun.
HTTPS wird auf einem Load Balancer gehandhabt, aber dieser Link besagt, dass ich nach der Änderung von app.yml einen Rebuild durchführen muss.
Wenn ich die Versionen für discourse_docker festlege, sollte ich dann den aktuellen Commit-Hash auschecken?
Und für die Discourse-App im Container sollte ich auch deren aktuellen Commit-Hash mit version: <commit_hash> in app.yml festlegen?
Es ist eine gute Vermutung, dass Sie, wenn Sie die aktuelle Version auf dem Testserver installieren und die Datenbank darauf wiederherstellen, den Produktionsserver aktualisieren können.
Was Sie vorschlagen, ist wahrscheinlich mehrere Stunden Arbeit, hat eine Reihe verwirrender kleiner Details, die in einem Forum sehr schwer zu beschreiben sind, und wird nichts beweisen, was die Wiederherstellung der Produktionsdatenbank auf dem neuen Server nicht tun wird.
Zeigen Sie einfach auf den Staging-Server und den Produktionsserver, die auf denselben S3-Backup-Bucket zeigen, sichern Sie die Produktion und stellen Sie sie auf dem Staging-Server wieder her. Zukünftig werden sie gleichwertig sein und Sie können Staging und Produktion in schneller Folge aktualisieren.
Ich habe einen Neubau ausgelöst, aber das ist, was ich bekommen habe:
I, [2023-04-07T19:17:58.707365 #1] INFO -- : cd /var/www/discourse & gem install bundler --conservative -v $(awk '/BUNDLED WITH/ { getline; gsub(/ /,""); print $0 }' Gemfile.lock)
ERROR: Could not find a valid gem 'bundler' (= 2.3.4), here is why:
Unable to download data from https://rubygems.org/ - Net::OpenTimeout: execution expired (https://rubygems.org/specs.4.8.gz)
Ich kann jedoch rubygems.org vom Host aus curl’en.
Ja, der Befehl zum Neuerstellen und auch das Upgrade über die GUI gaben denselben Fehler.
Fetcher wird aufgrund eines Fehlers erneut versucht (4/4): Bundler::HTTPError Konnte keine Spezifikationen von https://rubygems.org/ abrufen, da ein zugrunde liegender Fehler vorliegt <Net::OpenTimeout: execution expired (https://rubygems.org/specs.4.8.gz)>
Beim Installieren der gesperrten Bundler-Version (2.4.4) ist ein Fehler aufgetreten. Führen Sie den Befehl erneut mit dem Flag `--verbose` aus, um weitere Details zu erhalten. Bundler 2.3.6 wird weiterhin verwendet.
Index von https://rubygems.org/ wird abgerufen
Konnte keine Spezifikationen von https://rubygems.org/ abrufen, da ein zugrunde liegender Fehler vorliegt
<Net::OpenTimeout: execution expired (https://rubygems.org/specs.4.8.gz)>
Docker Manager: UPGRADE FEHLGESCHLAGEN
