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.