Konfigurieren Sie einen S3-kompatiblen Object-Storage-Anbieter für Uploads

[Discourse]

<div data-theme-toc="true"

Dieses Thema behandelt die Konfiguration einiger gängiger S3-kompatibler Object-Storage-Anbieter (S3-Klone). Weitere Details zur Konfiguration von Amazon AWS S3, das offiziell unterstützt und intern von Discourse für unsere Hosting-Dienste verwendet wird, findest du unter Set up file and image uploads to S3.

Anbieter	Dienstname	Funktioniert mit Discourse?
Amazon AWS	S3	Ja
Digital Ocean	Spaces	Ja
Linode	Object Storage	Ja
Google Cloud	Storage	Ja
Scaleway	Object Storage	Ja
Vultr	Object Storage	Ja
BackBlaze	Cloud Storage	Ja*
Selbst gehostet	MinIO	Ja
Azure Blob Storage	Flexify.IO	Ja
Oracle Cloud	Object Storage	Nein [1]
Wasabi	Object Storage	Vielleicht
Cloudflare	R2	Ja
Contabo	Object Storage	Nein

Falls du einen anderen Dienst zum Laufen bekommen hast, füge ihn bitte dieser Wiki-Seite hinzu.

Konfiguration

Um statische Discourse-Assets in deinem Object Storage zu speichern, füge diese Konfiguration in deiner app.yml unter dem Abschnitt hooks hinzu:

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

Bei der Nutzung von Object Storage benötigst du außerdem ein CDN, um die im Bucket gespeicherten Inhalte auszuliefern. Ich habe StackPath CDN bei meinen Tests verwendet; abgesehen davon, dass man dort Dynamic Caching By Header: Accept-Encoding in der Konfiguration setzen muss, funktioniert es gut.

DISCOURSE_CDN_URL ist ein CDN, das auf deinen Discourse-Hostnamen verweist und Anfragen zwischenspeichert. Es wird hauptsächlich für pullbare Assets verwendet: CSS und andere Theme-Assets.

DISCOURSE_S3_CDN_URL ist ein CDN, das auf deinen Object-Storage-Bucket verweist und Anfragen zwischenspeichert. Es wird hauptsächlich für pushbare Assets verwendet: JS, Bilder und Benutzer-Uploads.

Wir empfehlen, dass diese beiden URLs unterschiedlich sind und Administratoren beide setzen.

Die Nicht-Nutzung eines CDN (oder das Eingeben der Bucket-URL als CDN-URL) führt wahrscheinlich zu Problemen und wird nicht unterstützt.

In den folgenden Beispielen ist https://falcoland-files-cdn.falco.dev ein CDN, das so konfiguriert ist, dass es die Dateien unter dem Bucket ausliefert. Der Bucket-Name wurde in meinen Beispielen auf falcoland-files gesetzt.

Das Konfigurieren dieser Einstellungen als Umgebungsvariablen in deiner app.yml wird empfohlen, da dies die Vorgehensweise von CDCK in ihrer Infrastruktur ist und daher gut getestet ist. Außerdem findet der Task zum Hochladen der Assets nach der Kompilierung der Assets statt, was bei einem Rebuild geschieht. Wenn du ein Discourse-Setup starten möchtest, das von Anfang an korrekt mit Object Storage funktioniert, musst du die Umgebungsvariablen setzen, damit die Assets hochgeladen werden, bevor die Seite startet.

Wähle deinen Anbieter aus der untenstehenden Liste und füge diese Einstellungen zum Abschnitt env deiner app.yml-Datei hinzu, wobei du die Werte entsprechend anpasst:

AWS S3

Das ist das, was wir offiziell unterstützen und intern verwenden. Ihr CDN-Angebot Cloudfront funktioniert ebenfalls, um die Bucket-Dateien auszuliefern. Siehe Set up file and image uploads to S3, wie man die Berechtigungen richtig konfiguriert.

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: us-west-1
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backups
  DISCOURSE_BACKUP_LOCATION: s3

Digital Ocean Spaces

Das Angebot von DO ist gut und funktioniert out-of-the-box. Es ist in Ordnung, „Restrict File Listing“ zu aktivieren. Das einzige Problem ist, dass ihr CDN-Angebot schrecklich fehlerhaft ist, sodass du ein anderes CDN für die Dateien verwenden musst. Außerdem solltest du die CORS-Regel nicht installieren lassen, da sie bei jedem Rebuild neu installiert wird.

Beispielkonfiguration:

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: whatever
  DISCOURSE_S3_ENDPOINT: https://nyc3.digitaloceanspaces.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backups
  DISCOURSE_BACKUP_LOCATION: s3
  DISCOURSE_S3_INSTALL_CORS_RULE: false 

Linode Object Storage

Für Linode ist ein zusätzlicher Konfigurationsparameter, HTTP_CONTINUE_TIMEOUT, erforderlich.

Beispielkonfiguration:

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: us-east-1
  DISCOURSE_S3_HTTP_CONTINUE_TIMEOUT: 0
  DISCOURSE_S3_ENDPOINT: https://us-east-1.linodeobjects.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backup
  DISCOURSE_BACKUP_LOCATION: s3

Google Cloud Platform Storage

Das Auflisten von Dateien ist fehlerhaft, daher benötigst du eine zusätzliche ENV-Variable, um dies zu überspringen, damit die Assets funktionieren. Überspringe auch CORS und konfiguriere es manuell.

Da du keine Dateien auflisten kannst, wirst du auch keine Backups auflisten können, und automatische Backups werden fehlschlagen; wir empfehlen daher, es nicht für Backups zu verwenden. Einige schlagen jedoch vor, dass Backups korrekt funktionieren, wenn man die Rolle von Storage Legacy Object Owner zu Storage Legacy Bucket Owner ändert. Siehe dieses Thema für eine Google-Cloud-spezifische Diskussion.

Es gibt ein Drittanbieter-Plugin, um die Integration zu verbessern: Discourse GCS Helper.

Beispielkonfiguration:

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: us-east1
  DISCOURSE_S3_INSTALL_CORS_RULE: false
  FORCE_S3_UPLOADS: 1
  DISCOURSE_S3_ENDPOINT: https://storage.googleapis.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  #DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backup
  #DISCOURSE_BACKUP_LOCATION: s3

Scaleway Object Storage

Das Angebot von Scaleway ist ebenfalls sehr gut, und im Großen und Ganzen funktioniert alles einwandfrei.

Scaleway-Multipart-Uploads unterstützen maximal 1.000 Teile. Dies stimmt nicht mit Amazon S3 überein, das maximal 10.000 Teile unterstützt. Bei größeren Instanzen wird dies dazu führen, dass Discourse-Backups fehlerhaft sind, und der unvollständige Upload muss vor weiteren Versuchen manuell gelöscht werden. Bei kleinen Instanzen ist dies jedoch kein Problem. Scaleway scheint sehr offen für Feedback zu sein, daher solltest du sie kontaktieren, wenn du möchtest, dass dieses Limit geändert wird.

Beachte, dass für den Parameter DISCOURSE_S3_ENDPOINT Discourse den Endpunkt der gesamten Region verwendet: https://s3.{region}.scw.cloud. Der „Bucket-Endpunkt“, den du in deinem Scaleway-Dashboard findest, hat die Form https://{bucketName}.s3.{region}.scw.cloud. Lass den Bucket-Namen als Subdomain weg, um Verbindungsfehler zu vermeiden.

Beispielkonfiguration:

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: fr-par
  DISCOURSE_S3_ENDPOINT: https://s3.fr-par.scw.cloud
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backups
  DISCOURSE_BACKUP_LOCATION: s3

Vultr Object Storage

Für Vultr ist ein zusätzlicher Konfigurationsparameter, HTTP_CONTINUE_TIMEOUT, erforderlich.

Beispielkonfiguration:

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: whatever
  DISCOURSE_S3_HTTP_CONTINUE_TIMEOUT: 0
  DISCOURSE_S3_ENDPOINT: https://ewr1.vultrobjects.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backup
  DISCOURSE_BACKUP_LOCATION: s3

Backblaze B2 Cloud Storage

Du musst CORS überspringen und es manuell konfigurieren.

Es gibt Berichte, dass clean up orphan uploads mit BackBlaze nicht korrekt funktioniert. Du musst die Lebenszyklusregeln für deinen Bucket ändern, damit die Bereinigung von Waisen-Uploads funktioniert.

Beispielkonfiguration:

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: "us-west-002"
  DISCOURSE_S3_INSTALL_CORS_RULE: false
  DISCOURSE_S3_CONFIGURE_TOMBSTONE_POLICY: false
  DISCOURSE_S3_ENDPOINT: https://s3.us-west-002.backblazeb2.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://falcoland-files-cdn.falco.dev
  DISCOURSE_S3_BUCKET: falcoland-files
  DISCOURSE_S3_BACKUP_BUCKET: falcoland-files/backup
  DISCOURSE_BACKUP_LOCATION: s3

Hinweis: Während der ersten Migration zu B2 kannst du das Limit von 2500 kostenlosen Daily Class C Transaktionen erreichen. Du musst eine Zahlungsmethode hinzufügen, um die Limits zu entfernen.

MinIO Storage Server

Es gibt einige Einschränkungen und Anforderungen, die du erfüllen musst, bevor du den MinIO Storage Server als Alternative zu S3 verwenden kannst:

1. Du hast eine vollständig konfigurierte MinIO Server-Instanz.
2. Du hast Domain-Support in der MinIO-Konfiguration aktiviert, für domänenbasierte Bucket-URLs. Dies ist eine obligatorische Einrichtungsvoraussetzung für MinIO und Discourse, da MinIO immer noch die veralteten S3-„Path“-Styles unterstützt, die in Discourse nicht mehr unterstützt werden.
3. Du hast die DNS-Konfiguration für MinIO richtig eingerichtet, sodass Bucket-Subdomains korrekt zum MinIO-Server auflösen und der MinIO-Server mit einer Basis-Domain konfiguriert ist (in diesem Fall minio.example.com).
4. Der Bucket discourse-data existiert auf dem MinIO-Server und hat eine „public“-Richtlinie.
5. Deine S3-CDN-URL verweist auf ein korrekt konfiguriertes CDN, das auf den Bucket verweist und Anfragen zwischenspeichert, wie zuvor in diesem Dokument beschrieben.
6. Deine CDNs sind so konfiguriert, dass sie tatsächlich einen „Host“-Header der Kern-S3-URL verwenden – zum Beispiel discourse-data.minio.example.com, wenn sie Daten abrufen – andernfalls kann es zu CORB-Problemen kommen.

Unter der Annahme, dass die oben genannten Einschränkungen und Voraussetzungen erfüllt sind, könnte eine Beispielkonfiguration so aussehen:

  DISCOURSE_USE_S3: true
  DISCOURSE_S3_REGION: anything
  DISCOURSE_S3_ENDPOINT: https://minio.example.com
  DISCOURSE_S3_ACCESS_KEY_ID: myaccesskey
  DISCOURSE_S3_SECRET_ACCESS_KEY: mysecretkey
  DISCOURSE_S3_CDN_URL: https://discourse-data-cdn.example.com
  DISCOURSE_S3_BUCKET: discourse-data
  DISCOURSE_S3_BACKUP_BUCKET: discourse-backups
  DISCOURSE_BACKUP_LOCATION: s3
  DISCOURSE_S3_INSTALL_CORS_RULE: false

CORS wird auf MinIO weiterhin aktiviert sein, auch wenn die Regel nicht vom App-Rebuilder installiert wird – standardmäßig scheint CORS auf allen HTTP-Verben in MinIO aktiviert zu sein, und MinIO unterstützt BucketCORS (S3-API) infolgedessen nicht.

Azure Blob Storage mit Flexify.IO

Azure Blob Storage ist kein S3-kompatibler Dienst und kann daher nicht mit Discourse verwendet werden. Es gibt ein Plugin, aber es ist fehlerhaft.

Der einfachste Weg, eine S3-kompatible Schnittstelle für Azure Blob Storage freizulegen, ist das Hinzufügen eines Flexify.IO-Servers, der das Azure-Storage-Protokoll in S3 übersetzt.

Zum Zeitpunkt dieses Schreibens ist der Dienst auf Azure kostenlos, und du benötigst nur eine sehr grundlegende (günstige) VM-Ebene, um ihn zum Laufen zu bringen. Er erfordert jedoch etwas Einrichtung.

1. Erstelle im Azure-Portal eine neue Ressource vom Typ Flexify.IO - Amazon S3 API for Azure Blob Storage.
2. Für leichte Nutzung scheint die minimale VM-Konfiguration gut zu funktionieren. Du kannst die meisten Standardeinstellungen akzeptieren. Denk daran, die PEM-Schlüsseldatei zu speichern, wenn du die VM erstellst.
3. Gehe zum Link der Flexify.IO-VM und melde dich im System an. Folge den Anweisungen, indem du den Azure Blob Storage Data Provider und den generierten S3-Endpunkt einrichtest. Stelle sicher, dass die Endpunktkonfigurationseinstellung Public read access to all objects in virtual buckets auf true gesetzt ist. Kopiere die S3-Endpunkt-URL und die Schlüssel.
4. Drücke Neuer virtueller Bucket und erstelle einen virtuellen Bucket. Er kann denselben Namen wie dein Azure Blob Storage-Container haben oder einen anderen Namen. Verknüpfe beliebige Container, die in diesen virtuellen Bucket verschmolzen werden sollen. Dieser virtuelle Bucket wird verwendet, um einen öffentlich lesbaren Bucket über S3 freizulegen.
5. Standardmäßig installiert Flexify.IO ein selbstsigniertes SSL-Zertifikat, während ein S3-Endpunkt HTTPS erfordert. SSH dich in die VM mit der Schlüsseldatei ein (der Benutzername ist standardmäßig azureuser) und ersetze die folgenden Dateien durch die korrekten Dateien:

• /etc/flexify/ssl/cert.pem – ersetze durch Zertifikatsdatei (PEM-Codierung)

• /etc/flexify/ssl/key.pem – ersetze durch privaten Schlüsseldatei (PKCS#8 PEM-Codierung, das ist diejenige, die mit BEGIN PRIVATE KEY und nicht BEGIN RSA PRIVATE KEY beginnt, was PKCS#1 ist)

  Diese Dateien gehören root, also musst du sudo verwenden, um sie zu ersetzen. Es ist am besten, sicherzustellen, dass die Ersatzdateien dieselben Eigentums- und Berechtigungseinstellungen wie die Originaldateien haben, also root:root und 600-Berechtigungen.

6. Standardmäßig erstellt Flexify.IO einen S3-Dienst auf Root-Ebene mit mehreren Buckets. Discourse erfordert Subdomain-Unterstützung für Buckets. Gehe zu: <deine Flexify.IO VM IP>/flexify-io/manage/admin/engines/configs/1, was eine versteckte Konfigurationsseite öffnet!
7. Gib die S3-Basis-Domain (sagen wir s3.mydomain.com) im Feld Endpoint hostname an, das standardmäßig leer sein sollte. Drücke Speichern, um die Einstellung zu speichern.
8. Starte die Flexify.IO-VM im Azure-Portal neu.
9. Mappe in deinem DNS s3.mydomain.com und *.s3.mydomain.com auf die Flexify.IO-VM-IP.
10. Setze in Discourse Folgendes auf der Admin-Seite (ja, es ist nicht erforderlich, dass die Einstellungen in app.yml stehen):

use s3: true
s3 region: anything
s3 endpoint: https://s3.mydomain.com
s3 access key: myaccesskey
s3 secret assess key: mysecret key
s3 cdn url: https://<azure-blob-account>.blob.core.windows.net/<container>
s3 bucket: <virtual bucket>
s3 backup bucket: <backup bucket>  (jeder Container wird ausreichen, da er keinen öffentlichen Lesezugriff erfordert und Flexify.IO sie automatisch freilegt)
backup location: s3

Die Verwendung desselben Buckets für Produktion und Staging wird nicht empfohlen. Wenn du es trotzdem tust, ergreife Maßnahmen, um sicherzustellen, dass deine Staging-Site deine Produktions-Assets nicht löscht (setze mindestens s3 disable cleanup und achte darauf, dass sie keine Produktions-Backups löscht).

Wasabi

@pfaffman hat Wasabi für Backups ausprobiert, aber es schien intermittierend und stillschweigend zu fehlschlagen, ließ Backups auf der Festplatte und füllte diese schließlich auf. Weder Wasabi noch meta hatten irgendwelche Hinweise, daher empfehle ich es nicht, obwohl deine Ergebnisse variieren können. @pfaffman ist jetzt ziemlich sicher, dass dieses Problem dadurch verursacht wurde, dass Backups und automatische Neustarts irgendwie zur gleichen Zeit geplant waren; es wurde nur für Backups verwendet, schien aber gut zu funktionieren. Wenn jemand es ausprobieren und hier berichten möchte, sollte es funktionieren, zumindest für Backups.

Oracle Cloud

Oracle Cloud unterstützt keinen Virtual-Host-Style-Zugriff auf Buckets und wird nicht funktionieren

Cloudflare R2

Cloudflare R2 ist mit S3-Object-Storage kompatibel, wenn man Cloudflare CDN verwendet. Cloudflares kostenloser Plan bietet 10 GB Speicherplatz, was für die Bedürfnisse der meisten Foren mehr als ausreichend sein sollte.

Um Cloudflare R2 zu konfigurieren, musst du die relevanten Einstellungen im Cloudflare-Dashboard unter R2 Object Storage konfigurieren.

Je nach deinen Anforderungen (Uploads oder Backups oder beides) sind dies die relevanten Einstellungen, die du in deine app.yml-Datei oder in deine Admin-All site settings (suche nach S3) einfügen musst:

  DISCOURSE_ENABLE_S3_UPLOADS: true
  DISCOURSE_S3_REGION: auto
  DISCOURSE_S3_ENDPOINT: https://<your-account-id>.r2.cloudflarestorage.com
  DISCOURSE_S3_ACCESS_KEY_ID: "xxx"
  DISCOURSE_S3_SECRET_ACCESS_KEY: "xxx"
  DISCOURSE_S3_UPLOAD_BUCKET: your-upload-bucket-name
  DISCOURSE_S3_CDN_URL: https://uploads.yourdomain.com
# DISCOURSE_S3_USE_CDN_URL_FOR_ALL_UPLOADS: true

  DISCOURSE_ENABLE_DIRECT_S3_UPLOADS: true
  DISCOURSE_S3_USE_ACLS: false
  
  DISCOURSE_BACKUP_LOCATION: s3
  DISCOURSE_S3_BACKUP_BUCKET: your-backup-bucket-name

Wenn du deine app.yml nicht bearbeiten möchtest, kannst du dies in der Admin-UI tun:

„Admin → Alle Site-Einstellungen“ (suche nach S3):

• S3-Uploads aktivieren = true
• Direkte S3-Uploads aktivieren = true
• S3-Zugriffsschlüssel-ID = "xxx"
• S3-geheimer Zugriffsschlüssel = "xxx"
• S3-Region = any
• S3-Upload-Bucket = dein Upload-Bucket-Name
• S3-Endpunkt = https://<your-account-id>.r2.cloudflarestorage.com
• S3-CDN-URL = https://uploads.yourdomain.com
• S3 ACLs verwenden = false (deaktiviere dies!)
• S3-Backup-Bucket = dein Backup-Bucket-Name
• Backup-Standort = S3

Wichtige Hinweise zur Konfiguration von Cloudflare R2:

1. Wenn du deine app.yml oder web_only.yml für Cloudflare R2 konfigurierst, setze nur die DISCOURSE_S3_CDN_URL. Setze NICHT DISCOURSE_CDN_URL. Wenn du deine Hauptdomain über Cloudflare proxyt, werden deine App-Assets bereits automatisch zwischengespeichert und ausgeliefert. Wenn du versuchst, eine separate DISCOURSE_CDN_URL über Cloudflare DNS zu konfigurieren, wird Discourses strikte NGINX-Host-Routing die Anfragen ablehnen, was zu endlosen 301-Umleitungs-Schleifen, CORS-Richtlinien-Blockierungen und einer defekten Site führt.

• Lass DISCOURSE_CDN_URL auskommentiert.
• Setze DISCOURSE_S3_CDN_URL: https://your-r2-custom-domain.com

2. API-Token-Berechtigungen: Da Discourse nur einen Satz von Anmeldeinformationsfeldern hat, muss das API-Token, das du in Cloudflare generierst, Berechtigungen zum Zugriff auf deinen Upload-Bucket und deinen Backup-Bucket haben. Wähle beim Erstellen deines Tokens entweder „Auf alle Buckets anwenden“ oder „Auf bestimmte Buckets anwenden“ und stelle sicher, dass beide ausgewählt sind. Stelle außerdem sicher, dass du Object Read & Write beim Erstellen des API-Schlüssels auswählst (standardmäßig ist nur Object Read only ausgewählt).

3. Wenn du die Endpunkt-URL von Cloudflare kopierst, kann der Bucket-Name an die URL angehängt werden – du solltest den Bucket-Namen vom Ende der Zeichenfolge in deiner .yml-Datei (oder Admin-Einstellungen) löschen, wenn er kopiert wird.

4. Kommentiere # DISCOURSE_S3_USE_CDN_URL_FOR_ALL_UPLOADS: true aus, wenn du deinen R2-Upload-Bucket für alle Uploads, einschließlich PDF- und ZIP-Dateien, verwenden möchtest. (Beachte, dass dies alle hochgeladenen Dateien über direkten Link öffentlich verfügbar macht)

5. Wenn du DISCOURSE_ENABLE_DIRECT_S3_UPLOADS (true) aktivierst, solltest du DISCOURSE_S3_USE_ACLS (false) deaktivieren. Dies liegt daran, dass Cloudflare R2 Bucket-Ebenen-Berechtigungen verwendet; dein Upload-Bucket sollte öffentlich und der Backup-Bucket privat sein. Für Cloudflare R2-Uploads musst du NICHT die CORS-Regeln-Rake-Tasks konfigurieren oder IAM-JSON schreiben, da du es im Cloudflare-Dashboard konfigurierst, wenn du deine Bucket-Berechtigungen einrichtest. Cloudflares „Object Read & Write“-Token gewährt automatisch Multipart-Upload-Berechtigungen, und das Einfügen der folgenden CORS-Regel direkt in die Cloudflare-Dashboard-R2-Upload-Bucket-Einstellungen unter CORS Policy ersetzt die Notwendigkeit für die Rake-Task.

[
  {
    "AllowedOrigins": [
      "https://forum.yourdomain.com"
    ],
    "AllowedMethods": [
      "GET",
      "PUT",
      "POST",
      "DELETE",
      "HEAD"
    ],
    "AllowedHeaders": [
      "*"
    ],
    "ExposeHeaders": [
      "ETag"
    ],
    "MaxAgeSeconds": 3000
  }
]

Siehe auch dieses Thema für weitere Informationen zur Einrichtung von Cloudflare: Using Discourse with Cloudflare: Best Practices

Contabo

@tuxed hat versucht, Contabo Object Storage für S3-kompatible Uploads zum Laufen zu bringen. Es scheint, dass beim Hochladen der Repository-Name in der URL vorangestellt wird, und er konnte es nicht zum Laufen bringen.

Sichere Uploads

Sichere Uploads werden nur für AWS S3 unterstützt. Wenn dein rake uploads:migrate_to_s3 fehlschlägt, solltest du diese Befehle eingeben, um zuerst zu zählen und dann diese Uploads als unsicher zu markieren, vorausgesetzt, du weißt, dass sie nicht sicher sein müssen; in diesem Fall musst du AWS S3 verwenden.

./launcher enter app
rails c
Upload.where(secure: true).count
Upload.where(secure: true).update_all(secure:false)

---

1. Oracle Cloud unterstützt keinen Virtual-Host-Style-Zugriff auf Buckets und wird nicht funktionieren ↩︎