Verwendung von Scaleway s3-kompatiblem Objektspeicher

Unterstützung
1

Hallo,

ich versuche, Discourse mit dem S3-kompatiblen Objektspeicher von Scaleway zu konfigurieren, komme aber nicht weiter und weiß nicht, wo das Problem liegt.

Ich habe überprüft, dass beide Buckets mit aws-cli funktionieren, und dass die CORS-Einstellungen korrekt konfiguriert sind, indem ich die offiziellen Dokumentationen von Scaleway befolgt habe. Daher gehe ich davon aus, dass die Buckets selbst nicht das Problem sind.

Hier sind meine Discourse-S3-Einstellungen (ein Teil des Bucket-Namens ist redigiert):

discourse-admin-s3
discourse-admin-s31355×1654 348 KB

Wenn ich den Reiter „Backups“ öffne, erhalte ich die Meldung: „Fehler beim Auflisten der Backups von S3: Aws::S3::Errors::BadRequest“.
Beim Versuch, ein Bild hochzuladen, erscheint im Log folgender Eintrag: „Job exception: Failed to open TCP connection to [redacted]-discourse-files.s3.fr-par.amazonaws.com:443 (getaddrinfo: Name or service not known)“.

Ich verwende die neueste Version von Discourse – 2.4.0.beta10 (14ae574bc5).

2

Meine Vermutung ist, dass sie weniger S3-kompatibel sind, als sie glauben?

Die S3-Region-Einstellung scheint hier ebenfalls einen Einfluss zu haben.

3

Das ist möglich, aber die URL sollte amazonaws.com nicht enthalten, wenn ich den Endpunkt eingegeben habe – oder?

4

Genau, das ist seltsam. Vielleicht liegt es an der Hipster-TLD? Lass mich das mal ansehen.

@dino, versuche, https:// vom S3-Endpoint zu entfernen.

5

Die Validierung lässt mir das nicht zu: ‘s3_endpoint: Der Wert entspricht nicht dem erforderlichen Format.’

6

Ja, das war eine schlechte Vermutung.

Ich kann keinen Weg finden, um mit einer URL wie deiner zu enden, indem ich den dafür verantwortlichen Code lese:

Betrifft dies nur Backups? Funktionieren Uploads?

7

Nun, das ist anders als das Problem, das ich mit GCP-Buckets hatte, aber du könntest einen Blick auf Trouble with Google Bucket for backup - #4 by pfaffman werfen.

Ich konnte herausfinden, welches Upgrade des aws-sdk-s3-Gems dazu führte, dass die Nutzung von GCP-Buckets nicht mehr funktionierte, obwohl sich mein Kunde dafür entschied, auf einen AWS-Bucket umzusteigen.

8

@Falco ja, ich stehe auch auf dem Schlauch.
Der Fehler mit der URL, die amazonaws enthält, bezieht sich speziell auf den Datei-Upload, nicht auf Backups. Bei Backups erhalte ich nur die generische Fehlermeldung, also gehe ich davon aus, dass beides wegen des URL-Problems nicht funktioniert.

Kommst du auf etwas anderes?

@pfaffman danke für den Tipp – ich schaue mal, ob ein Wechsel der gem-Version hilft.

9

Hey @dino, hat das am Ende geholfen? Ich habe hier das gleiche Problem und bin kurz davor, aufzugeben und zu Amazon S3 zu wechseln.

10

Hey @FroggyC,
Ich hatte leider keine Zeit mehr, das zu debuggen, und habe es daher nicht versucht, die Gem-Versionen zu ändern. Ich bin stattdessen auf Amazon S3 umgestiegen, wie in der offiziellen Dokumentation beschrieben, und alles hat sofort funktioniert.
Tut mir leid, dass es keine besseren Neuigkeiten sind…

11

Vielen Dank. Ich schätze, wir müssen dasselbe tun. Danke!

12

Das gleiche Problem hier. Gibt es etwas, womit wir beim Debuggen helfen können?

Zum Beispiel durch Zugriff auf den Bucket über die CLI und das Senden von Protokolldateien?

s3_region wird ignoriert, oder? Da Scaleway andere Werte als AWS verwendet.

13

Du könntest versuchen, Scaleway zu fragen – die Verantwortung für die Kompatibilität liegt bei ihnen. Wenn sie nicht vollständig mit AWS S3 kompatibel sind, sollten sie das beheben.

14

Du unterstellst, dass es ihre Schuld ist, obwohl du bisher den Kommentar von @dino ignoriert hast:

Solange die (unveränderte) s3_endpoint-URL nicht so wie sie ist verwendet wird, wird es schwer sein, Scaleway davon zu überzeugen, dass der Fehler auf ihrer Seite liegt. Besonders da andere S3-Clients eine Verbindung herstellen können.

15

OK, beweisen Sie es. Zeigen Sie mir die Dokumentation und Log-Trace-Dateien, die dies belegen. Wenn Sie konkrete Beweise für das Problem auf unserer Seite liefern können, werde ich mir das ansehen.

16

Klar, das habe ich mit folgendem gemeint:

Also, wie kann ich Discourse anweisen, seine S3-Verbindungsversuche zu protokollieren? Sobald wir sicher wissen, welche URL es verbinden möchte, kann ich den Verkehr abfangen und die Ergebnisse teilen.

17

Der Grund, warum der S3-Upload/das S3-Backup nicht funktioniert, liegt an der Region, die auf fr-par (oder nl-ams) gesetzt werden muss. Dies kann nur erreicht werden, indem die SiteSetting-Validierung von Discourse umgangen wird:

(via ./launcher enter app und dann rails c)

SiteSetting.find_by(name: 's3_region').update_attribute(:value, 'fr-par')

Nach dieser Änderung funktionieren Uploads und Backups für den Scaleway Object Storage.

Scaleway-Dokumentation zum Object Storage

Natürlich ist dies nur eine Workaround-Lösung. Sobald Sie diese Site-Einstellung über das Web-Admin-Interface zurücksetzen oder ändern, können Sie sie nicht mehr in einen funktionierenden Zustand versetzen (es sei denn, Sie nutzen erneut die Rails-Konsole).

Ich vermute, dass der AWS/S3-Client explizit das Setzen eines Regions-Strings erlaubt (im Gegensatz zum aktuellen Zustand im Web-Admin).

Außerdem ist es etwas irreführend, wenn im Dropdown-Menü „EU (Paris)

18

Aha. Benötigen wir ein spezielles Site-Einstellungsfeld für „s3-kompatible Regionen

19

Das ist nicht nötig.

Benutzer von S3-Klonen müssen die Umgebungsvariable S3_ENDPOINT setzen, wodurch die S3-Region überschrieben wird.

Ich habe eine vollständige Anleitung dazu erstellt, wie man das mit einem Digital Ocean S3-Klon macht, warte aber darauf, dass Digital Ocean einen Fehler in ihrem S3-CDN behebt, bevor ich sie veröffentlichte.

Wenn Scaleway in einem besseren Zustand ist als Digital Ocean, werde ich es wahrscheinlich ausprobieren und meine Anleitung darauf aufbauen.

20

Richtig, aber wie wissen sie das? Wird dies in der Beschreibung der bestehenden Site-Einstellung erwähnt? Ich denke, das sollte sie. Kannst du das ändern?