Ich bin gerade dabei, meinen Server von einer bestehenden Bitnami-basierten Bereitstellung (einer ziemlich alten Version) auf die offiziell unterstützte Installation in AWS mit der neuesten Discourse-Version zu migrieren. Diese neue Installation verfügt über eine externe Elasticache- und RDS-Instanz und wird auch S3 für Backups und Uploads verwenden.
Ich habe 2 Fragen:
Der alte Discourse-Server verwendet eine ziemlich alte Version – werden durch die Durchführung des Backup/Restore auf dem neuen Discourse-Server automatisch alle relevanten Upgrade-Befehle ausgeführt?
Wenn ich die Backup-Datei in den neuen Discourse-Docker-Container auf dem neuen Server kopiere und den Restore über die Befehlszeile starte, werden die neuen Bucket-Werte, die ich in meiner Konfiguration festgelegt habe, durch den Restore überschrieben, oder werden meine neuen Werte verwendet? Ich gehe davon aus, dass meine neue DB aus dem Backup befüllt wird und dann, wenn ich den Container verlasse und ./launcher rebuild app ausführe, meine neuen S3-Werte verwendet werden.
Wenn meine Annahmen korrekt sind, sollte ich dann vor dem Starten des Restores den Inhalt der alten S3-Buckets in die neuen kopieren?
Gibt es bei dieser Art der Migration mit einem Backup noch andere Fallstricke?
Vielleicht übersehe ich etwas, aber warum erstellen Sie neue Buckets? Ein neuer Backup-Bucket mit geeigneten Lifecycle-Regeln scheint in Ordnung zu sein, aber wenn Ihre bestehende Discourse-Instanz den S3-Upload-Bucket verwendet, werden Sie einige Probleme haben.
Ich bin mir nicht zu 100 % sicher, dass die Migration von Bitnami reibungslos funktionieren wird, daher möchten wir keine vorhandenen Daten beeinträchtigen, falls wir die Migration abbrechen müssen.
Wir haben unsere Bucket-Benennung geändert, daher dachten wir, es sei einfacher, 2 brandneue Buckets dafür zu haben.
Punkt 1 bereitet mir am meisten Sorgen, daher bin ich besonders vorsichtig.
Welche Probleme sehen Sie mit dem neuen Upload-Bucket? Der alte Discourse-Server wird in den schreibgeschützten Modus versetzt. Der Plan ist, sobald der neue Server hochgefahren und validiert ist, unseren alten Server herunterzufahren, die DNS auf den neuen Server umzustellen und dann den Cache im CDN (Cloudfront) zu leeren und ihn dann für die Öffentlichkeit freizugeben.
Ich habe übersehen, dass Sie die Daten aus den alten Buckets kopieren wollten. Habe mir AWS angesehen, sieht unkompliziert aus. Wenn ich Sie wäre, würde ich nicht mit dem Ändern der Buckets herumfummeln, bevor ich zu AWS oder einem neuen Server an einem anderen Ort wechsle.
[quote=“stevejr, post:1, topic:395948”]zur offiziell unterstützten Installation in AWS mit der neuesten Discourse-Version.
[/quote]
Offiziell unterstützt?? Da bin ich mir nicht so sicher.
Ich empfehle Ihnen dringend, Discourse zu aktualisieren, bevor Sie auf einen neuen Server umziehen.
Auf der alten Instanz empfehle ich, die S3-Konfiguration in die app.yml zu verschieben, falls sie dort noch nicht vorhanden ist, bevor Sie umziehen.
Ich bin sehr neugierig, wie eine solche Installation einen Mehrwert bietet.
Angesichts der zahlreichen Beiträge zu nicht unterstützten Installationen scheint dies mehr Ärger als Nutzen zu bringen, es sei denn, die Leute führen sie zu Lern- oder Experimentierzwecken durch.
Eine solche Einrichtung könnte aus Sicht von Discourse eine nicht unterstützte Installation sein, aber aus der Sicht einer Enterprise-IT-Organisation könnten RDS und Elasticache Standard sein und die Standardinstallation von Discourse die Ausnahme darstellen.
Wie von @RGJ erwähnt, verwendet unsere Unternehmensinfrastruktur externe Dienste für Dinge wie Cache, Datenbank usw., daher Elasticache und RDS. Das bedeutet, dass wir eine vollständige Sicherung und Redundanz für diese Dienste haben und auch bei Sicherheitskontrollen helfen können. Dies ist eine offizielle/unterstützte Installation aus Sicht von Discourse – es werden lediglich andere Vorlagen verwendet – wir verwenden discourse_docker/samples/web_only.yml at main · discourse/discourse_docker · GitHub (vielleicht war die Verwendung des Wortes Standard etwas irreführend, entschuldigen Sie bitte).
Es klingt also so, als sollten wir zuerst die Bucket-Namen für die bestehende Installation aktualisieren und dann den Umzug auf den neuen Server durchführen. Die Aktualisierung der bestehenden Installation auf die neueste Version ist ausgeschlossen – wir hatten zuvor Probleme mit dem Bitnami-Upgrade, weshalb wir auf die offizielle Installationsmethode umgestiegen sind.
Darf ich fragen, welche Probleme wahrscheinlich auftreten, wenn wir die Wiederherstellung mit den bestehenden Buckets durchführen und dann die app.yml aktualisieren, um auf die neuen Buckets zu verweisen – haben nicht alle DISCOURSE_-Umgebungsvariablen Vorrang vor jeglicher Konfiguration in der Datenbank (sofern zutreffend)? Oder könnte etwas anderes ein Problem verursachen?
Denn wenn du es vor der Migration tust und die Dinge schiefgehen, hast du das Problem auf der älteren Bitnami-Instanz anstatt auf deiner frisch installierten Standardinstanz. Und abgesehen von der alten Version lässt dich schon die Erwähnung des Wortes Bitnami viel, viel weniger Unterstützung hier im Meta-Forum erhalten.
Eine weitere Frage, wenn ich darf: Wenn ich die Wiederherstellung über die Befehlszeile innerhalb des Discourse-Containers ausführe, verwendet sie die vorhandene /var/www/discourse/config/discourse.conf-Konfiguration für die Details zur Datenbankverbindung, Redis-Verbindung usw. oder überschreibt sie diese Konfiguration mit dem, was sich in der Sicherungsdatei befindet?
discourse.conf wird aus app.yml generiert und ist nicht in der Sicherungsdatei enthalten.
Im Allgemeinen überschreiben die Einstellungen in discourse.conf die Website-Einstellungen.
Wenn Sie also setting_foo in Ihrer Datenbank haben, können Sie diese überschreiben, indem Sie DISCOURSE_SETTING_FOO in Ihrer app.yml definieren, was dann setting_foo in discourse.conf generiert.
Die Verweisung eines Discourse-Containers auf einen externen PostgreSQL- und Redis-Server mithilfe unseres Container-Images mit unseren Tools ist eine unterstützte Installation.
RDS[1] ist Postgresql, und Elasticache ist Redis, das ist in Ordnung.
Das sollte in Ordnung sein, wir machen das für Leute, die zu unserem Hosting wechseln.
Ich bevorzuge es, den Prozess so einfach wie möglich zu halten. Wenn Sie also ein vollständiges Backup (einschließlich Uploads) auf dem alten Server erstellen und es auf dem neuen wiederherstellen können, können Sie das neue Setup vollständig testen, ohne Auswirkungen auf das alte zu haben.
Ich werde das Backup/Restore durchführen, ohne die Bucket-Namen zu ändern, wie auch von @RGJ vorgeschlagen. Wie ich sagte, bestand meine Sorge darin, die vorhandenen Serverdaten in keiner Weise zu beeinträchtigen, aber wenn ich zuerst die vorhandenen Buckets sichere und sicherstelle, dass der vorhandene Server während der Migration im Lesemodus ist, denke ich, dass die Integrität der hochgeladenen Daten in den Buckets ziemlich gut geschützt ist.
ich wollte nur sagen, dass wir gestern unsere Migration durchgeführt haben und sie fast so reibungslos wie Butter verlief, was sehr, sehr befriedigend war.
