Musste das vorerst parken, da es so aussah, als würde es funktionieren, aber dann gibt es etwas Seltsames mit R2 in Bezug auf die Inhaltskodierung mit den Assets, entweder beim Hochladen und Nichtsetzen des Headers oder etwas anderem. Es stürzt mit einem ‘Ungültiges oder unerwartetes Token’ ab, wenn das gz-Asset etwas wie browser-detect-7af298cd000a967d2bdc01b04807eda2924a388584ea38ad84919b726283c2ed.gz.js ist. Der rake s3:upload_assets scheint zu funktionieren, aber die Dateien werden auf der Browserseite nicht richtig gelesen.
Ich verstehe nicht wirklich, warum bei AWS S3 die lokale Server-URL für Assets in Ordnung ist (sie existieren nicht in unserem vorhandenen S3-Bucket für Uploads), aber für R2 die DISCOURSE_S3_CDN_URL nur für Assets verwendet werden soll. Wenn ich die Assets von der Server-URL erzwingen könnte, würde das wahrscheinlich alles funktionieren.
EDIT: Im Chat mit CF scheint dies das Problem zu sein, und ab heute, warum R2 ohne einige Änderungen nicht mit Discourse verwendet werden kann. Ich könnte im Post-Hook-Schritt etwas skripten, um die gz-Assets zu entfernen, aber ich fühle mich für einen Tag schon “weit vom Weg abgekommen”:
Dateien, die Sie zippen, werden derzeit von R2 nicht korrekt behandelt. Sie müssen unkomprimierte Dateien hochladen. Cloudflare hat transparente Komprimierung, sie wählen Identität, Gzip oder Brotli basierend darauf, was der Client verarbeiten kann. Dies ist ein Unterschied zu S3.
Vielen Dank für die Erstellung dieser Anleitung! Ich hatte einige Erfolge mit Minio.
Für alle anderen, die versuchen, es lokal mit Docker Compose einzurichten, können Sie Docker anweisen, einen Hostnamen-Alias hinzuzufügen, damit es als Subdomain funktioniert, wie hier:
In diesem Fall würden Sie DISCOURSE_S3_ENDPOINT=http://minio.mydomain.com:9000, DISCOURSE_S3_CDN_URL=//assets.minio.mydomain.com:9000 festlegen und Ihre lokale /etc/hosts/-Datei so konfigurieren, dass die Subdomain auf localhost verweist.
Hallo @Falco – Bezieht sich das auf die Art und Weise, wie der Header Content-Encoding: gzip mit ihrem Spaces CDN funktioniert? Das klingt ähnlich wie bei Cloudflare R2, da der Asset-Standort dem Upload-CDN entspricht, sodass gzip kaputt geht? Hier ist was heute mit R2 passiert.
Es könnte sich lohnen, einen Schalter für dieses Verhalten in Betracht zu ziehen, d. h. Assets vom Ursprung zu servieren, anstatt immer DISCOURSE_S3_CDN_URL? Ich werde gerne nachsehen, wie das geht, wenn dies als mögliche Konfigurationsänderung in Betracht gezogen würde.
Das ist es, was passieren sollte, wenn Sie DISCOURSE_S3_CDN_URL weglassen, aber da es sich um einen seltsamen Grenzfall und einen potenziell teuren Fehler handelt, ist es keine gängige Konfiguration.
Ja, das verstehe ich. Ein neuer GlobalSetting-Boolescher Wert S3_ORIGIN_ASSETS (oder S3_BROKEN_PROXY_FUDGE ) ungefähr hier, so ähnlich wie die Testskripte nicht komprimiert sind würde es Digital Ocean Spaces und Cloudflare R2 Speicher und CDN ermöglichen, mit Discourse sofort zu funktionieren, was eine nette Funktionserweiterung für wenig Aufwand ist? Vielleicht für zukünftige Überlegungen.
Oh, ich habe in den Release Notes für 3.0.beta gesehen, dass etwas hinzugefügt wurde. Ich werde es ausprobieren, es sei denn, ich missverstehe, wofür es ist? Es könnte Cloudflare R2 und Digital Ocean Spaces ermöglichen, mit ihren CDNs verwendet zu werden, die diese seltsamen Dinge mit gzip machen.
Die Einstellung ermöglichte es mir, den lokalen Standort als Ursprung anzugeben, um die Notwendigkeit zu umgehen, dass die JS-Assets auf der S3-Site liegen (in diesem Fall Cloudflare oder Digital Ocean Spaces mit aktiviertem CDN). Danke an @david für die Änderung, auch wenn das nicht die Absicht war.
Danke, ich habe noch einmal nachgeprüft und es scheint mit der automatischen Konfiguration zu funktionieren, aber nicht mit der Verwaltung meiner eigenen Schlüssel aus der S3-Verwaltung.
Wissen Sie, ob dies innerhalb von Discourse möglich ist?
Dies scheint kürzlich behoben worden zu sein.
In der Änderungsprotokoll vom 16.03.2023 wird eine Fehlerbehebung für die Handhabung von Gzip-Dateien aufgeführt.
Wir betreiben unser Discourse-Forum unter discourse.aosus.org mit R2 (haben migrate_to_s3 noch nicht ausgeführt), und es scheint in Ordnung zu sein! Bisher sind keine nennenswerten Probleme aufgetreten.
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: "us-east-1" #Alias zu Auto
#DISCOURSE_S3_INSTALL_CORS_RULE: true #Es sollte unterstützt werden
DISCOURSE_S3_ENDPOINT: S3_API_URL
DISCOURSE_S3_ACCESS_KEY_ID: xxx
DISCOURSE_S3_SECRET_ACCESS_KEY: xxxx
DISCOURSE_S3_CDN_URL: Ihre CDN-URL
DISCOURSE_S3_BUCKET: BUCKET_NAME
Gibt es eine Möglichkeit, einen separaten Host für Backups anzugeben? Es wäre großartig, wenn es möglich wäre, R2 nur für CDN-Zwecke zu verwenden.
Es ist seltsam, dass die Einstellungen in ENV nicht in der Admin-Benutzeroberfläche angezeigt werden. Findet eine Überschreibung statt? Überschreiben neue Einstellungen von S3 in der Admin-Benutzeroberfläche diejenigen in der Umgebung?
) ungefähr hier, so ähnlich wie die 