Konfigurieren Sie einen S3-kompatiblen Objektspeicheranbieter für Uploads

@Falco - Es könnte gut sein, eine Warnung für Scaleway hinzuzufügen, dass es nur 1.000 Teile für Multipart-Uploads unterstützt, während AWS 10.000 unterstützt. Dies ist kein Problem für reguläre Uploads, aber es ist ein Problem für Backup-Uploads über eine bestimmte Größe hinaus, da das S3 SDK standardmäßig 10.000 Teile verwendet, es sei denn, es wird manuell geändert, und dann fehlschlägt.

4 „Gefällt mir“

Toller Fund! Bitte füge ihn dem OP-Wiki hinzu, wenn du kannst.

4 „Gefällt mir“

Vielen Dank, ich möchte auch hinzufügen, dass Sie alle diese Tools verwenden können, um von Cloud zu Cloud zu kopieren, insbesondere zu/von S3-kompatiblem Objektspeicher, zum Beispiel Rclone, Shargate, Gs Richcopy360 und GoodSync. Alle diese sind mit ähnlichen Clouds kompatibel.

1 „Gefällt mir“

Wir haben gerade ein Problem entdeckt: Cloudflare R2 erlaubt keinen öffentlichen Lesezugriff über die S3-Endpunkt-URL, sondern nur über die benutzerdefinierte Domain oder eine zufällige r2.dev-Domain.
(Vorgenerierte Downloads funktionieren, aber kein direkter öffentlicher Zugriff wird unterstützt.)
Discourse verwendet jedoch nur die CDN-URL für eingebettete Bilder und nicht für direkte Downloads, die die S3-Endpunkt-URL verwenden.
Gibt es eine Möglichkeit, die CDN-URL für alle Dateien zu verwenden oder die Verwendung einer vorgenerierten URL zu erzwingen?

Verwandt:

Der in diesem Beitrag erwähnte Workaround funktioniert: das Hinzufügen von ?dl=1 behebt das Problem, da es Discourse zwingt, eine vorgenerierte S3-URL zu verwenden.

1 „Gefällt mir“

Behoben in 2023-03-16, jetzt funktioniert R2 mit Discourse wie erwartet mit dem kostenlosen Plan.

3 „Gefällt mir“

Das sehe ich auch mit einiger Häufigkeit (alle paar Monate), obwohl mein Discourse auf AWS Lightsail läuft und ich nach AWS S3 hochlade. Ich bin mir also nicht sicher, ob es Wasabis Schuld ist.

Wäre es möglich, diesen Fehler abzufangen und den Administrator zu benachrichtigen? Ich überprüfe den Festplattenspeicher und entferne alte Backups, wenn ich ein Upgrade durchführe, aber manchmal ist es zu spät und das Forum geht wegen fehlenden Festplattenspeichers offline.

1 „Gefällt mir“

Ich bin ziemlich sicher, dass das Problem darin bestand, dass automatische OS-Neustarts für Sicherheitsupdates liefen, während das Backup lief. Stellen Sie sicher, dass Sie Ihre OS-Neustarts und Ihre Backups zu unterschiedlichen Zeiten planen. Es war, nachdem ich diese Website von Wasabi weggezogen hatte, dass ich zu dieser Erklärung kam, aber ich bin mir ziemlich sicher, dass es das war.

2 „Gefällt mir“

uptime sagt, es läuft seit 300 Tagen, also glaube ich nicht, dass das das Problem ist. Aber in ähnlicher Weise hatte ich Discourse-Backups für 2:00 Uhr morgens und Lightsail-Snapshots für 2:30 Uhr morgens geplant, also ist der Upload vielleicht manchmal nicht vollständig und der Snapshot stört ihn. Ich habe die beiden Vorgänge um eine Stunde getrennt – wir werden sehen, ob das einen Unterschied macht.

Unabhängig davon halte ich es für angemessen, Administratoren zu warnen, wenn der Upload aus irgendeinem Grund fehlschlägt.

2 „Gefällt mir“

Ich denke, es ist an der Zeit, Kernel-Upgrades durchzuführen und neu zu starten. :slight_smile:

Könnte Ihnen der Arbeitsspeicher ausgehen?

Nachdem ich Remote-Backblaze-Backups implementiert habe, sehe ich diese Fehlermeldung in meinem Dashboard:

Der Server ist so konfiguriert, dass Dateien nach S3 hochgeladen werden, aber es ist kein S3-CDN konfiguriert. Dies kann zu teuren S3-Kosten und einer langsameren Website-Leistung führen. Weitere Informationen finden Sie unter „Verwendung von Objektspeicher für Uploads“.

Ich habe keinen Dateiupload konfiguriert, sondern nur Backups über diese Konfiguration:

DISCOURSE_S3_REGION: "s3.us-west-00X"
DISCOURSE_S3_INSTALL_CORS_RULE: false
DISCOURSE_S3_ENDPOINT: https://s3.us-west-00X.backblazeb2.com
DISCOURSE_S3_ACCESS_KEY_ID: mykeyid
DISCOURSE_S3_SECRET_ACCESS_KEY: myaccesskey
DISCOURSE_S3_BUCKET: community-forum
DISCOURSE_S3_BACKUP_BUCKET: community-forum/backups
DISCOURSE_BACKUP_LOCATION: s3

Habe ich etwas falsch gemacht?

Etwas scheint falsch konfiguriert zu sein. Ich bemerke, dass ich diese Fehlermeldung erhalte, wenn ich versuche, eine Datei in einen Beitrag hochzuladen:

Nicht unterstützter Wert für canned acl ‘public-read’

Jede Hilfe wäre willkommen.

2 „Gefällt mir“

Entfernen Sie dies, wenn Sie nicht möchten, dass Uploads nach S3 übertragen werden.

4 „Gefällt mir“

Du hast den Tag gerettet, Bruder. :+1:t3: Vielen Dank!

2 „Gefällt mir“

Hat das funktioniert?

1 „Gefällt mir“

Es ist im letzten Monat einmal passiert, seit ich die beiden Prozesse um eine Stunde getrennt habe, daher hat es es nicht „behoben“, und es passiert nicht oft genug, um sagen zu können, ob es geholfen hat.

Auf der positiven Seite habe ich festgestellt, dass es im Admin-Bereich einen Abschnitt für den Sicherungsstatus gibt, der den verfügbaren Speicherplatz anzeigt. Das erspart mir, ständig ein Terminal zu öffnen und ein df auszuführen, nur um nach hängenden Sicherungen zu suchen. Ich habe den Text angepasst, um mich daran zu erinnern, dass ich etwa 80 GB freien Speicherplatz erwarte.

1 „Gefällt mir“

Das ist eine gute Idee.

Ich sah das Bild, bevor ich las, dass Sie den Text angepasst hatten, und fragte mich, welche Logik dahintersteckte, um zu bestimmen, dass dies “gut” sei!

1 „Gefällt mir“

Ich konnte das mit Scaleway und dem Bitnami Discourse-Image einfach nicht zum Laufen bringen.
Die Umgebungsvariablen waren gesetzt, wurden aber offensichtlich nicht richtig (oder gar nicht?) gelesen/angewendet.

Daher habe ich die S3-Variablen im Admin-Panel gesetzt und die Region direkt in der Rails-Konsole festgelegt (in der Hoffnung, dass dies einfach ein Textfeld wird):
SiteSetting.s3_region="fr-par"

Dies gab mir einen Validierungsfehler, aber ich habe die Validierungsprüfung auskommentiert, bevor ich die Einstellung geändert habe, und sie dann wieder eingefügt.

1 „Gefällt mir“

Das Bitnami-Image wird nicht von uns gepackt und folgt nicht unseren Empfehlungen. Alles, was hier dokumentiert ist, wurde nur gegen die offizielle Installation getestet.

4 „Gefällt mir“

Dies wurde durch die Aktivierung von „s3 use cdn url for all uploads“ gelöst, einer Option, die kürzlich von Discourse hinzugefügt wurde.
Da wir zuvor R2 verwendet haben, mussten wir discourse remap verwenden, um die defekten Links manuell zu ersetzen, und die S3-Dateien vorsichtshalber synchronisieren, und dann haben wir alle Beiträge neu gebacken.

1 „Gefällt mir“

Ich versuche, dies mit idrive e2 einzurichten, das S3-kompatibel ist. Ich erhalte jedoch eine nicht sehr hilfreiche Fehlermeldung/Stack-Trace am Ende von ./launcher rebuild app:

I, [2023-10-14T15:08:08.026184 #1]  INFO -- : cd /var/www/discourse & sudo -E -u discourse bundle exec rake s3:upload_assets
rake aborted!
Aws::S3::Errors::InternalError: We encountered an internal error, please try again.
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/raise_response_errors.rb:17:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/sse_cpk.rb:24:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/dualstack.rb:27:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/plugins/accelerate.rb:56:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/checksum_algorithm.rb:111:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:22:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/idempotency_token.rb:19:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/param_converter.rb:26:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/request_callback.rb:71:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/aws-sdk-core/plugins/response_paging.rb:12:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/plugins/response_target.rb:24:in `call'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-core-3.130.2/lib/seahorse/client/request.rb:72:in `send_request'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/client.rb:12369:in `put_object'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/aws-sdk-s3-1.114.0/lib/aws-sdk-s3/object.rb:1472:in `put'
/var/www/discourse/lib/s3_helper.rb:78:in `upload'
/var/www/discourse/lib/tasks/s3.rake:41:in `block in upload'
/var/www/discourse/lib/tasks/s3.rake:41:in `open'
/var/www/discourse/lib/tasks/s3.rake:41:in `upload'
/var/www/discourse/lib/tasks/s3.rake:197:in `block (2 levels) in <main>'
/var/www/discourse/lib/tasks/s3.rake:197:in `each'
/var/www/discourse/lib/tasks/s3.rake:197:in `block in <main>'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rake-13.0.6/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Tasks: TOP => s3:upload_assets
(See full trace by running task with --trace)
I, [2023-10-14T15:08:16.413098 #1]  INFO -- : Installing CORS rules...
skipping
Uploading: assets/admin-2ebebf57104b0beb47a1c82fe5a8c6decd07f60a706640345fed296a094d1536.js

Dies ist die Konfiguration, die ich verwendet habe, aber ich habe sie auch mit DISCOURSE_S3_CONFIGURE_TOMBSTONE_POLICY und DISCOURSE_S3_HTTP_CONTINUE_TIMEOUT ausprobiert.

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: Dallas
  DISCOURSE_S3_ENDPOINT: https://y0o9.tx21.idrivee2-4.com
  DISCOURSE_S3_ACCESS_KEY_ID: <snip>
  DISCOURSE_S3_SECRET_ACCESS_KEY: <snip>
  DISCOURSE_S3_BUCKET: discourse
  DISCOURSE_S3_INSTALL_CORS_RULE: false

Beachten Sie, dass ich es nicht für Backups verwende (das ist bereits in der Benutzeroberfläche mit Backblaze eingerichtet) noch für DISCOURSE_CDN_URL, da ich nicht sicher bin, ob idrive dies unterstützt – ich hatte vor, damit zu experimentieren, sobald ich einige tatsächliche Dateien im Bucket habe.

1 „Gefällt mir“

Es scheint, dass es für die Bedürfnisse von Discourse nicht kompatibel genug mit S3 ist.

Wenn Sie weiter graben möchten, wäre der nächste Schritt, dies in einer Entwicklungsumgebung zu reproduzieren und den genauen API-Aufruf zu erhalten, der fehlschlägt.

2 „Gefällt mir“