Ich versuche, Discourse von einem persönlichen Hosting-Anbieter auf einen Amazon LightSail-Server zu migrieren. Ich habe das Forum durchsucht und alle Beiträge zum Migrieren von Servern und zur Einrichtung von Discourse gelesen:
Meines Wissens nach läuft der Prozess wie folgt ab:
Einen neuen Discourse-Server installieren
Ein Backup vom bestehenden Discourse-Server exportieren (derzeit ist das Backup so konfiguriert, dass es auf S3 gespeichert wird, aber ich verstehe, dass hier ein manuelles Dateibacking erforderlich sein wird)
Das Backup auf den neuen Discourse-Server importieren (manuell, da es meiner Einschätzung nach nicht von S3 übernommen werden kann)
Ich stecke gerade bei Schritt 1 fest, da ich einige Einschränkungen habe: Ich verfüge nur über eine einzige Domain und möchte diese für den neuen Server beibehalten. Außerdem möchte ich keine Ausfallzeiten haben (mein Ziel ist es, den neuen Server einzurichten, das Backup wiederherzustellen und dann erst den DNS-Eintrag auf den neuen Server umzustellen, um so Ausfallzeiten zu vermeiden, da beide Server gleichzeitig laufen).
Meines Wissens nach kann ich beim Einrichten des neuen Discourse-Servers die app.yml-Datei vom bestehenden Server auf den neuen Server kopieren und dann discourse-setup ausführen. Das Problem, das ich hier sehe, ist, dass dabei derselbe DNS-Name wie beim bestehenden Server verwendet wird (was ich auch möchte), aber ich sehe zwei Probleme voraus, bei denen ich gerade nach einer Lösung suche:
Das Let’s Encrypt-Zertifikat wird für den neuen Server kein SSL-Zertifikat generieren, da die Domain noch auf den alten Server zeigt.
Ohne das SSL-Zertifikat (die Konfiguration des alten Servers ist so eingestellt, dass nur SSL verwendet wird, was in der app.yml übernommen wird) wird der Server nicht starten.
Ich habe versucht, eine Verbindung zum Discourse-Server über eine DNS-Umleitung herzustellen, aber wenn die eingegebene URL nicht mit der app.yml-Konfiguration übereinstimmt, funktionieren entweder NGINX oder Discourse nicht. Man erhält im Browser einen Fehler beim Versuch, eine Verbindung herzustellen. Ohne eine Weboberfläche kann ich den Wiederherstellungsprozess nicht starten.
Wie kann ich also die Einrichtung des neuen Discourse-Servers mit der app.yml des bestehenden Servers abschließen und dann das Backup wiederherstellen, gefolgt von einem DNS-Umschalten? Oder gibt es eine einfachere Methode, dies zu tun?
Wenn Sie nicht denselben S3-Bucket verwenden, gibt es eine versteckte Einstellung, die den Download der S3-Dateien für das Backup erzwingt. Sie können den Namen dieser Einstellung in der Konfigurationsdatei nachschlagen und sie über die Rails-Konsole setzen. Es gibt ein Thema, das dies diskutiert, aber es ist vielleicht am einfachsten, in der Datei settings.yml nachzusehen.
Sie müssen discourse-setup nicht ausführen; kopieren Sie einfach die app.yml und bauen Sie neu auf.
Sie können die Let’s Encrypt-Zertifikate per rsync übertragen. Tatsächlich können Sie das gesamte Verzeichnis /var/discourse kopieren (vielleicht mit Ausnahme einiger Protokolldateien und ähnlichem).
Das Idealziel wäre ein „Lift-and-Shift“, aber das ist bei Amazon Lightsail nicht möglich, da man kein bestehendes Image importieren kann. Ja, es würde also dasselbe S3-Volume verwenden.
Dein Ansatz scheint dem Lift-and-Shift am nächsten zu kommen. Wenn ich dich richtig verstehe, kann ich einfach den gesamten /var/discourse-Ordner vom ursprünglichen Server tar/gz komprimieren, auf dem neuen Server entpacken, danach discourse start ausführen und lediglich die DNS-Einträge auf den neuen Server umleiten. Ist das alles? Muss ich Discourse auf dem neuen Server neu aufsetzen? Was ist mit Nginx, Docker und anderen Abhängigkeiten außerhalb des Ordners?
Ja, verschieben Sie die Dateien so, wie es für Sie sinnvoll ist. Ja, Sie müssen einen Neuaufbau durchführen, um einen neuen Container zu erstellen und zu starten.
Danke. Offenbar war das ‚Lift and Shift’ nicht so sauber, wie ich dachte. Es müssen einige Checks vor und nach dem Vorgang durchgeführt werden, um einen reibungslosen ‚Lift and Shift’-Prozess zu gewährleisten (Postgres wurde von 12.0 auf 13.0 aktualisiert, was mir einige Lektionen im ‚Lift and Shift’-Prozess beigebracht hat). Hier ist eine schrittweise Anleitung für zukünftige Referenz für alle, die auf einen Amazon LightSail-Server (1 GB RAM) umziehen möchten:
Originalserver
Backup auf S3 erstellen
cd /var/discourse
./launcher rebuild # Neuesten Build für einen einfachen Übergang holen
./launcher cleanup # Aufräumen, um alte Daten zu entfernen und die Paketgröße zu reduzieren
./launcher stop app # Unterlassung führt zu einem Fehler beim späteren Rebuild mit Postgres
tar -zcvf /var/discourse discourse.tar.gz
Neuer Amazon LightSail-Server
Ubuntu 20.20-Image von Amazon installieren (1 GB RAM)
2 GB Swap erstellen # Unterlassung kann zum Scheitern des Rebuilds führen
vm.overcommit_memory=1 konfigurieren # Unterlassung kann zu einem Fehler mit Postgres während des Rebuilds führen
discourse.tar.gz per FTPS/Transfer vom Originalserver übertragen
tar -zxvf discourse.tar.gz -C /
cd /var/discourse
UNICORN_WORKERS in app.yml auf 2 setzen # Erhöhung über 2 hinaus bei 1 GB RAM birgt das Risiko von Swapping und Drosselung aufgrund übermäßiger Festplattenaktivität
./launcher rebuild
DNS so ändern, dass er auf den neuen Amazon-Server zeigt
Gibt es eine einfachere Möglichkeit, Server zu migrieren (Lift and Shift), ohne den kompletten Discourse-Einrichtungsprozess durchlaufen zu müssen?
Meinst du, ohne discourse-setup auszuführen, oder meinst du, ohne den Container zu bauen, der für den Betrieb von Discourse erforderlich ist? Wenn du Letzteres meinst, ist es möglich, das alte Image in ein Repository zu schieben, das der neue Server nutzen könnte, aber das ist nichts, was ein Anfänger leicht bewältigen könnte.
Dein Prozess wurde durch das PG13-Upgrade kompliziert. Es wäre vielleicht etwas einfacher gewesen, auf dem neuen Server ein neues Image von Grund auf zu bauen und das Backup vom alten wiederherzustellen, aber du hättest immer noch einige knifflige Details, um die neuen Let’s Encrypt-Zertifikate auf dem neuen Server zu erhalten.
Genau, das war das einzige Hindernis, das mich davon abgehalten hat, auf dem neuen Server ein ./discourse-setup durchzuführen und dann das S3-Image wiederherzustellen (und wie man das ohne Zugriff auf die Web-Admin-Konsole macht, da der DNS-Eintrag noch auf den alten Server zeigt und AFAIK Discourse im Browser nicht auf eine IP-Adresse reagiert). Da ich ein Live-System hatte und den DNS-Eintrag sofort vom alten auf das neue System umschalten musste, war das Fehlen von Let’s-Encrypt-Zertifikaten das einzige Hindernis für mich.
Wenn es eine Möglichkeit gibt, die Zertifikate vom alten auf das neue System zu übertragen, ./discourse-setup ohne jegliche Let’s-Encrypt-Fehler abzuschließen und das S3-Backup ohne die Web-Konsole wiederherzustellen, wäre das ein einfacherer Weg, dies zu tun.
Wenn Sie die yml-Dateien im Verzeichnis containers kopieren, benötigen Sie discourse-setup nicht (es kann die Speicherparameter anpassen, falls diese auf dem neuen Server anders sind, aber Sie könnten dies auch danach tun). Führen Sie einfach ./launcher rebuild app aus.
Okay, ich glaube, ich habe verstanden, was du meinst. Aber zur Sicherheit fasse ich mein Verständnis noch einmal zusammen.
Im ursprünglichen Server war das Backup von Discourse auf S3 eingerichtet (das betrifft sowohl die Einstellungen als auch den Site-Inhalt).
Durch das Kopieren der yml-Dateien aus den containers wird die gesamte Konfiguration des ursprünglichen Servers auf den neuen Server übertragen. Auf dem neuen Server muss ich also kein discourse-setup mehr durchführen. Stattdessen sorgt ein ./launcher rebuild app dafür, dass die ursprüngliche Serverkonfiguration verwendet wird, um das neueste Image herunterzuladen und Discourse zu konfigurieren.
Aktuell sind noch zwei Dinge offen:
Wie werden die Let’s Encrypt-Zertifikate übertragen? (Da die DNS-Einstellungen noch auf den ursprünglichen Server zeigen, können sie nicht neu erstellt werden. Ich vermute, dies muss vor dem ./launcher rebuild app erledigt werden.)
Wie stelle ich Discourse (Einstellungen + Inhalt) nach dem Rebuild aus dem S3-Backup wieder her? Da die DNS-Einstellungen noch auf den ursprünglichen Server zeigen, gibt es dann eine Möglichkeit, über eine IP-Adresse oder localhost auf die Discourse-Admin-Oberfläche zuzugreifen? Oder kann das S3-Backup über die Konsole wiederhergestellt werden?
Vielen Dank für die detaillierten Schritte. Ich musste etwas Ähnliches tun, als ich zu einem neuen Hoster wechselte.
Da die Website funktionierte, wollte ich nicht die Backups durchgehen, also folgte ich den Schritten hier.
Es hat fast funktioniert, aber der Neuaufbau auf dem neuen Hoster schlug fehl.
Es stellte sich heraus, dass die UID/GID-Zuordnung auf den beiden Hostern nicht ganz dieselbe war, sodass beim Starten von Postgres Probleme wegen des falschen Besitzers des Datenordners auftraten.
Für das Szenario in diesem Beitrag gibt es ein zusätzliches Detail: Der Container wird nicht erstellt, daher funktioniert ./launcher enter app in diesem Stadium nicht. Da der Neuaufbau ziemlich lange dauern würde, konnte ich docker ps verwenden, um den Namen des Containers zu ermitteln, der den Aufbau durchführt, und dann in den Container wechseln:
Der Neuaufbau schlägt dann fehl (oder Sie können ihn nicht mit CTRL+C stoppen). Nachdem er gestoppt wurde, führen Sie ihn einfach erneut aus, und die Berechtigungen sind behoben:
.