Konfigurieren Sie einen S3-kompatiblen Objektspeicheranbieter für Uploads

Dokumentation Selbst-Hosting
, , ,
372

Danke für das Dankeschön! Ich habe es zur Moderation markiert, weil ich zu diesem Zeitpunkt keine Bearbeitungsrechte hatte, aber dank des Beitrags, den ich erstellt habe, habe ich sie jetzt. Ironisch, wie das funktioniert, oder?

Aber bevor ich eine globale Notiz außerhalb des MinIO-Abschnitts erstelle, können wir bestätigen, dass Discourse als Ganzes keine Pfade mehr unterstützt, die nicht auf Domänen basieren, wie in diesem Beitrag begonnen meine Bearbeitungsjagd?

Wenn wir wissen, dass Discourse als Ganzes den Pfadmodus (d. h. minio.server.com/BUCKET/foo/bar/...-Pfade) nicht unterstützt und stattdessen nur Domänenpfade (d. h. BUCKET.minio.server.com/foo/bar/...-Pfade) unterstützt, dann können wir dies als globale Notiz im Wiki machen und ich werde dies gerne tun – jedoch muss ich es von jemandem hören, der weit höher in der Kette steht als ich (als einfache Community-Person), dass dies tatsächlich die Anforderung für Discourse ist. Wenn ja, kann ich es bearbeiten, ansonsten… nun, dann lasse ich es einfach als Notiz in den MinIO-Voraussetzungen.

2 „Gefällt mir“
373

MinIO ist der einzige beliebte S3-Klon mit einer Vergangenheit in der Verwendung des nun veralteten S3-Pfadstils. Daher glaube ich nicht, dass eine globale Warnung erforderlich ist, sondern nur im MinIO-Abschnitt ausreicht.

4 „Gefällt mir“
374

Danke, Falco, ich habe es in die MinIO-Anforderungen aufgenommen, aber diesem Haftungsausschlussbereich auch eine starke Betonung gegeben, da der obige verknüpfte Thread darauf verweist, warum ich erneut nachhake.

2 „Gefällt mir“
375

Scheint ein Problem zu geben:

Eingegeben

  after_assets_precompile:
    - exec:
        cd: $home
        cmd:
          - sudo -E -u discourse bundle exec rake s3:upload_assets

Wiederaufgebaut:

FEHLGESCHLAGEN
--------------------
Pups::ExecError: cd /var/www/discourse & sudo -E -u discourse bundle exec rake s3:upload_assets fehlgeschlagen mit Rückgabe #<Process::Status: pid 2064 exit 1>
Ort des Fehlers: /usr/local/lib/ruby/gems/2.7.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec fehlgeschlagen mit den Parametern {"cd"=>"$home", "cmd"=>["sudo -E -u discourse bundle exec rake s3:upload_assets"]}
bootstrap fehlgeschlagen mit Exit-Code 1
** BOOTSTRAP FEHLGESCHLAGEN ** Bitte scrollen Sie nach oben und suchen Sie nach früheren Fehlermeldungen, es kann mehr als eine geben.
./discourse-doctor kann bei der Diagnose des Problems helfen.
1 „Gefällt mir“
376

Können Sie die Anleitung befolgen und

3 „Gefällt mir“
377

Einen Schritt zum Bereinigen alter Assets auf S3 zur OP hinzugefügt. Sollte überall außer bei GCP funktionieren.

3 „Gefällt mir“
378

Die meisten der 170.000 Dateien wurden mit rake s3:migrate_to_s3 hochgeladen, aber ich glaube, 12 hatten dies:

: Unsupported value for canned acl 'private' (Aws::S3::Errors::InvalidArgument)

Vielleicht waren diese in PMs? Gibt es etwas, das ich tun kann, um diese zu beheben?

2 „Gefällt mir“
379

Hallo @Falco. Macht das Sinn? Ich gehe die Antworten durch, um zu sehen, ob sie bearbeitet wurden, damit wir die Funktion „nach 30 Tagen löschen“ für dieses Thema aktivieren können.

Ich habe einige der als privat markierten Uploads überprüft, und sie befanden sich in normalen Themen, sodass ich nicht herausfinden konnte, warum sie als sicher markiert waren. (Sichere Uploads waren nicht aktiviert?)

Siehe oben

2 „Gefällt mir“
380

Sichere Uploads sind nur für AWS S3 verfügbar, daher funktionieren sie tatsächlich nicht mit Klonen.

2 „Gefällt mir“
381

Ergibt Sinn. Ich habe den oberen Teil des OP mit diesen Informationen aktualisiert. Irgendeine Idee, warum lokale Uploads als sicher markiert wurden auf einer Seite, die weder S3 noch sichere Uploads aktiviert hatte?

1 „Gefällt mir“
382

Hat jemand das für eine Weile aktiviert und es dann zurückgenommen, als er sah, dass es nicht funktionierte?

2 „Gefällt mir“
383

Ich denke, dass dieses Problem beim Hochladen auf Cloudflare R2 mit Upload.where(secure: true).update_all(secure: false) gelöst werden kann. Ich werde versuchen, mich darum zu kümmern, bevor diese Nachricht gelöscht wird (aber ich habe dem OP eine Notiz hinzugefügt).

2 „Gefällt mir“
384

Hmm, wir haben keine sicheren Uploads. Ich denke, ich werde Cloudflare R2 ausprobieren, da die kostenlosen Limits ziemlich großzügig sind und sie einen (Beta-)S3-Migrator haben. Ich werde es wohl herausfinden, aber hast du gesehen, ob R2 am Ende in Ordnung war, @pfaffman?

1 „Gefällt mir“
385

Ich kann mich nicht mehr erinnern, ob das Problem auftrat, als ich versuchte, Bilder hochzuladen, oder als ich gerade ein neues hochgeladen hatte. Wenn ich noch einmal darüber nachdenke, würde ich denken, dass ich es auf einer brandneuen Website getestet habe.

Die Migration zu einer anderen S3-Plattform ist ziemlich knifflig. Es gibt einige Themen dazu, aber wenn Sie Cloudflare R2 verwenden möchten, würde ich es zuerst auf einer Testwebsite ausprobieren; es besteht eine sehr gute Chance, dass es nicht funktioniert.

1 „Gefällt mir“
386

Es funktioniert irgendwie, ist aber noch nicht für den Produktionseinsatz bereit.

Ich hatte eine ältere lokale Entwicklungsinstallation von Discourse 2.7 herumliegen, und sie funktionierte einwandfrei, d. h. Bild-Uploads, Nutzung von CDN und Backups in einen privaten Bucket, wenn sie für Cloudflare R2 eingerichtet war. Ich habe auf die neueste Version 2.9 aktualisiert (wie unser Forum sie verwendet), und es scheint bei der Aufholverarbeitung von Jobs::UpdateGravatar fehzuschlagen, wo der Bucket-Notation für Cloudflare falsch verwendet wird, da versucht wird, ein Gravatar-Remote-Bild in R2 zu cachen. Beispiel (wobei mein Bucket-Name auf R2 ‘uploads’ lautet):

Upload Update (0.3ms) UPDATE "uploads" SET "url" = '//uploads.123123redact.r2.cloudflarestorage.com/original/1X/123123example.jpeg', "updated_at" = '2022-12-12 20:44:02.929494', "etag" = '9c02b086b2aa5e2088ed44e1017fa63e' WHERE "uploads"."id" = 3

Also würde ich die Benutzeroberfläche starten, und die Avatare in meiner lokalen Test-/Entwicklungsumgebung würden auf Folgendes verweisen:

//uploads.123123redact.r2.cloudflarestorage.com/original/1X/123123example.jpeg

Meine beste Vermutung ist also, dass S3 mit der Bucket-Punktnotation einverstanden ist und Cloudflare R2 nicht, oder vielleicht muss der Gravatar-Cache stattdessen den S3-CDN-Wert verwenden? Es ist schade, da es ziemlich nah dran zu sein scheint.

2 „Gefällt mir“
387

Ich habe eine Antwort von Cloudflare erhalten, dass sie für R2, bis sie die Objekt-ACL korrekt implementieren, es so geändert haben, dass sie eine 200 zurückgeben, wenn sie Werte in dieser Eigenschaft erhalten, die sie noch nicht unterstützen. Dieses geänderte Verhalten bei R2 erfolgte angeblich Ende November. Offensichtlich nicht ideal (es ist in einem öffentlichen Bucket, wobei die API verlangt, dass er privat ist), aber es bedeutet, dass es für dieses Problem jetzt „funktioniert“.

3 „Gefällt mir“
388

Oh! Das klingt vielversprechend. Ich denke, Sie bräuchten wahrscheinlich einen separaten Bucket für Uploads, obwohl es ein ziemliches Rätselraten wäre, den Dateinamen eines Backups zu ermitteln.

Ich werde versuchen, mir das bald anzusehen.

2 „Gefällt mir“
389

Ich verwende separate Upload- und Backup-Buckets, und es schien gut zu funktionieren, da der R2-Bucket für Backups nicht öffentlich ist und Discourse über die Admin-Oberfläche dort erfolgreich ein komprimiertes Backup geschrieben hat. Ich habe es heruntergeladen und mir angesehen, und es schien in Ordnung zu sein (nicht dasselbe wie eine tatsächliche Wiederherstellung, aber gut genug für einen Montag). Mein Upload-Bucket habe ich mit einer benutzerdefinierten Domain für S3_CDN getestet, und das scheint gut zu funktionieren.

Ehrlich gesagt, kann ich nicht wirklich sagen, was mit meiner 2.9 los ist, die keine Benutzeroberfläche im Ember-CLI rendert (sie wird bei mir leer, nachdem ich den Admin-Benutzer erstellt habe), aber es ist wahrscheinlich etwas, das Sie schnell als falsch erkennen werden.

EDIT: Oh, es scheint, als würde versucht, die Plugin-JavaScript-Assets von Pseudo-S3/R2 zu laden, z. B. viele 404er bei Dingen wie assets/locales/en.br.js.

Ich habe mit bundle exec rake s3:upload_assets keinen Erfolg, daher ist das mein bester aktueller Hinweis.

EDIT2: Ja, es hat mit Assets zu tun, denn wenn ich meine DISCOURSE_S3_CDN_URL lösche, wird die Benutzeroberfläche geladen. Ich werde vorerst versuchen, die Assets manuell an Ort und Stelle hochzuladen.

EDIT3: Das Problem scheint einfach darin zu bestehen, dass die App die Assets vorkompiliert benötigt und wo DISCOURSE_S3_CDN_URL darauf verweist, und für eine lokale Entwicklungsumgebung ist das nicht üblich. Ich bin gespannt, was @pfaffman herausfindet, da ich denke, dass dies in einer ordnungsgemäß mit Docker bereitgestellten selbst gehosteten Instanz funktionieren würde, indem der Hook after_assets_precompile für R2 verwendet wird.

2 „Gefällt mir“
390

Ja. Ein CDN für eine lokale Entwicklungsumgebung? Ich kann mir nicht vorstellen, dass das funktionieren könnte. Es klingt, als ob es für eine Produktionsbereitstellung funktionieren sollte.

1 „Gefällt mir“
391

Ja, im Nachhinein nicht überraschend in einer Dev-Umgebung. Ich glaube, was ich nicht erwartet hatte, war, dass mit DISCOURSE_S3_CDN_URL auf den Cloudflare CDN für R2 gesetzt, aber dann DISCOURSE_CDN_URL leer (oder lokal oder ngrok) gesetzt wurde, aber dann trotzdem die Cloudflare-Pull-URL für die vorkompilierten Assets usw. verwendet wurde und nicht nur für die Uploads/Bilder allein. Ich denke, es wird in der Produktion in einem richtigen Container in Ordnung funktionieren, also werde ich es vielleicht kurz ausprobieren. Mein Plan wird etwa so aussehen: Medien-Uploads vorübergehend auf TL4 setzen, die IDs usw. in der app.yaml auf Cloudflare umstellen, es testen und, wenn es gut ist, es bei R2 belassen und dann alle vorhandenen S3-Objekte per rclone übertragen - danach werde ich die Beiträge neu backen und hoffentlich ist alles in Ordnung :crossed_fingers:.

2 „Gefällt mir“