Umzug von einem S3-Bucket zu einem anderen

Unterstützung
1

Fortsetzung der Diskussion aus Wie verschiebe ich meinen S3-Upload-Bucket von einem Anbieter zu einem anderen?:

Ich versuche, von einem GCP-Bucket zu einem AWS S3-Bucket zu wechseln. Das alte System verwendet keinen S3-CDN (derjenige, der es eingerichtet hat, scheint nicht wirklich zu wissen, was er tut).

Ich habe s3cmd verwendet, um den alten GCP-Bucket mit einem lokalen Dateisystem zu synchronisieren, und dann erneut, um die Assets in den neuen S3-Bucket zu übertragen. Das System ist nun korrekt mit S3 und Site-CDNs konfiguriert, wie in Verwendung von Objektspeicher für Uploads (S3 & Klone) beschrieben.

Das oben verlinkte Thema schlug vor, rake posts:remap zu verwenden, um die Beiträge zu aktualisieren (ich nehme an, ich sollte auch alle Beiträge neu backen? Oder zumindest diejenigen, die mit dem alten Bucket übereinstimmen?).

Bei der Ausführung von posts:remap wurde nur ein Beitrag remapped.

 Upload.order(Arel.sql('RANDOM()')).limit(10).pluck(:id, :url)

zeigt, dass alle diese den alten Bucket haben … Ah, das ist das Problem. Wir brauchen nicht rake posts:remap, sondern discourse remap, wie unter Change the domain name or rename your Discourse beschrieben.

Ja, das denke ich auch.

Ich werde versuchen, das in Kürze umzusetzen. @Falco, im Großen und Ganzen ist es so etwas wie:

  • neuen Bucket und CDN dafür erstellen, Container neu aufbauen, um den neuen Bucket/CDN zu verwenden und sicherstellen, dass es funktioniert
  • s3cmd für den alten Bucket konfigurieren und die Daten lokal synchronisieren
  • s3cmd für den neuen Bucket konfigurieren und die Daten in den neuen Bucket hochladen
  • discourse remap ALT-BUCKET-DOMAIN-NAME NEUER-BUCKET-DOMAIN-NAME ausführen
  • neu backen

Klingt das richtig?

Wenn Sie dasselbe CDN für den alten und den neuen Bucket verwenden, könnten Sie sich das erneute Backen sparen, aber den richtigen Zeitpunkt dafür zu treffen, scheint etwas knifflig (man kann den CDN-Ursprung nicht ändern, bis die Daten im neuen Bucket sind, aber man müsste sicherstellen, dass während des Synchronisationsvorgangs nichts in den alten Bucket hochgeladen wird?) – vielleicht einfach sagen, dass es möglich ist.

2 „Gefällt mir“
2

Vielleicht ist die Verwendung der offiziellen AWS CLI für eine Anleitung besser geeignet?

Verwende hier DbHelper.remap.

Nicht erforderlich.

Verwende dasselbe CDN und ändere einfach die CDN-Quelle im CDN-Panel, oder verwende ein neues CDN und führe ein Remap mit DbHelper.remap durch. In beiden Fällen ist kein Rebake erforderlich.

2 „Gefällt mir“
3

Ah, okay. Ich werde mir das ansehen. . . Ist es möglich, die AWS CLI mit nicht-AWS-Buckets zu verwenden?

4

Hey Rafael, ich bin fast fertig. Meine aktuelle Version dieses Howtos verweist auf aws cli und gsutil, um von alt nach lokal und von lokal nach neu zu synchronisieren (ich verlinke einfach auf diese Tools und gebe einen Befehl in der Kommandozeile an, bei dem die Bucket-Namen durch Platzhalter ersetzt sind). Anschließend wird DbHelper verwendet, um die Tabellen zu aktualisieren. Für meine mittelgroße Seite läuft das ziemlich schnell. Toll.

Das einzige Problem, das ich jetzt habe, ist, dass die alte Konfiguration kein s3_cdn_url hatte, sodass diese Bilder in den Beiträgen immer noch direkt mit dem Bucket verknüpft sind (nicht mit dem CDN). Ein Neuaufbacken (Rebaking) hilft nicht. Neue Uploads sind korrekt mit dem CDN verknüpft. Man kann das nicht beheben, indem man DISCOURSE_S3_ENDPOINT: '' setzt, da dies keine Wirkung hat. Nach der Wiederherstellung der Datenbank musste ich also die SiteSetting löschen. Das ist nicht so schlimm, aber es hat mich einige Neuaufback-Versuche gekostet, das herauszufinden.

Die alte Konfiguration hatte kein definiertes S3-CDN. Ich könnte das beheben, indem ich alle 1250 Beiträge, die die Bucket-URL/den Bucket-Hostnamen enthalten, neu aufbacke. Das führt jedoch dazu, dass alle diese Bilder heruntergeladen und optimiert werden (der alte Server läuft mit 2.7.0.beta5, also dachte ich, es gäbe bereits einige kürzlich durchgeführte Neuoptymierungen?). Das bringt meinen armen 2-GB-Server (mit Postgres und Redis auf RDS und Elasticache) für eine Weile an seine Grenzen (Lastdurchschnitt 10–20). Ich vermute, ich brauche ohnehin einen größeren EC2-Instanz für diese Seite, aber ich bin immer noch etwas überrascht, dass dieses Neuaufbacken den Server lahmlegt (500-Fehler in der Benutzeroberfläche).

Sollte ich stattdessen versuchen, in den cooked-Inhalten dieser Beiträge den Bucket-Hostnamen durch die CDN-URL zu ersetzen?

5

@pfaffman Danke, dass du mich hierher geführt hast.
Aber mein Problem wird in den letzten beiden Schritten noch komplizierter.

Aktuelles Problem: Einige meiner Bilder fehlen und werden durch kleine Icons ersetzt. Wenn ich mit dem Mauszeiger darüber fahre, wird die Adresse ‘olds3bucket’ angezeigt. Wenn ich jedoch darauf klicke, werden sie korrekt in voller Größe angezeigt, und nun wird der Pfad ‘news3bucket’ in der Adressleiste angezeigt.

  1. Du hast hauptsächlich empfohlen, die Daten des alten Buckets mit dem neuen Bucket zu synchronisieren, was ich bereits erfolgreich erledigt habe.
  2. Dann die Einstellungen des neuen Buckets in der Discourse-Web-Oberfläche hinterlegen, die ich seit einem Jahr verwende.
  3. Jetzt sagst du, die URL des alten Buckets mit der des neuen zu ‘remappen’ und danach neu zu backen. Hier liegt das Problem. Wenn ich dies tue (oder auch nur ‘rebake’ ausführe, oder ‘HTML neu erstellen’ aus dem Menü der Beitragseinstellungen, unabhängig davon, ob ich zuerst den ‘remap’-Schritt durchgeführt habe oder nicht), verschwinden die Bilder, die bisher nur als Icon angezeigt wurden, vollständig. An ihrer Stelle wird nur ein ‘weißer Bereich’ angezeigt. Daher muss ich sofort wiederherstellen.

Nochmals vielen Dank.
(Ich habe eine sehr kleine Website und ähnlich wie du auch…).

6

rclone ist ein gutes Tool, das mit mehreren Backends synchronisieren kann. Wir verwenden es derzeit für Backups.

7

Hey Jay,

Entschuldige, dass ich das nochmal aufgreife, aber hast du beim Leitfaden schon weitere Fortschritte gemacht? Danke!