Dieses Thema behandelt die Konfiguration einiger gängiger S3-kompatibler Object Storage-Anbieter (S3-Klone). Weitere Einzelheiten zur Konfiguration von Amazon AWS S3, die offiziell unterstützt wird und von Discourse intern für unsere Hosting-Dienste verwendet wird, finden Sie 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* |
| Self-hosted | 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 |
Wenn Sie einen anderen Dienst zum Laufen gebracht haben, fügen Sie ihn bitte diesem Wiki hinzu.
Konfiguration
Um statische Discourse-Assets in Ihrem Object Storage zu speichern, fügen Sie diese Konfiguration in Ihrer 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 Verwendung von Object Storage benötigen Sie zudem ein CDN, um die im Bucket gespeicherten Inhalte auszuliefern. Ich habe bei meinen Tests StackPath CDN verwendet; abgesehen davon, dass ich in deren Konfiguration Dynamic Caching By Header: Accept-Encoding einstellen musste, funktioniert es einwandfrei.
DISCOURSE_CDN_URL ist ein CDN, das auf Ihren Discourse-Hostnamen zeigt und Anfragen zwischenspeichert. Es wird hauptsächlich für herunterladbare Assets verwendet: CSS und andere Theme-Assets.
DISCOURSE_S3_CDN_URL ist ein CDN, das auf Ihren Object Storage-Bucket zeigt und Anfragen zwischenspeichert. Es wird hauptsächlich für hochladbare Assets verwendet: JS, Bilder und Benutzer-Uploads.
Wir empfehlen, dass diese unterschiedlich sind, und dass Administratoren beide einstellen.
Die Nichtverwendung eines CDNs (oder die Eingabe 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.
Es wird empfohlen, diese Einstellungen als Umgebungsvariablen in Ihrer app.yml zu konfigurieren, da dies die Methode ist, die CDCK in ihrer Infrastruktur verwendet, und daher gut getestet ist. Außerdem erfolgt die Aufgabe zum Hochladen von Assets nach der Kompilierung der Assets, was bei einem Rebuild geschieht. Wenn Sie ein Discourse-System starten möchten, das von Anfang an ordnungsgemäß mit Object Storage funktioniert, müssen Sie die Umgebungsvariablen so setzen, dass die Assets vor dem Start der Site hochgeladen werden.
Wählen Sie Ihren Anbieter aus der folgenden Liste aus und fügen Sie diese Einstellungen dem Abschnitt env Ihrer app.yml-Datei hinzu, wobei Sie die Werte entsprechend anpassen:
AWS S3
Das, was wir offiziell unterstützen und intern verwenden. Ihr CDN-Angebot Cloudfront funktioniert ebenfalls, um die Bucket-Dateien zu fronten. Siehe Set up file and image uploads to S3, wie Sie die Berechtigungen korrekt konfigurieren.
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 DO-Angebot ist gut und funktioniert out-of-the-box. Es ist in Ordnung, die Einschränkung der Dateiauflistung zu aktivieren. Das einzige Problem ist, dass ihr CDN-Angebot schrecklich fehlerhaft ist, sodass Sie ein anderes CDN für die Dateien verwenden müssen. Außerdem müssen Sie die CORS-Regel nicht installieren, da sie bei jedem Rebuild erneut 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
Die Auflistung von Dateien ist fehlerhaft, sodass Sie eine zusätzliche ENV benötigen, um dies zu überspringen, damit Assets funktionieren können. Überspringen Sie auch CORS und konfigurieren Sie es manuell.
Da Sie keine Dateien auflisten können, können Sie auch keine Backups auflisten, und automatische Backups werden fehlschlagen. Wir empfehlen daher nicht, sie für Backups zu verwenden. Einige schlagen jedoch vor, dass Backups korrekt funktionieren, wenn Sie die Rolle von „Storage Legacy Object Owner“ in „Storage Legacy Bucket Owner“ ändern. Siehe dieses Thema für eine Google Cloud-spezifische Diskussion.
Es gibt ein Drittanbieter-Plugin, um die Integration unter Discourse GCS Helper zu verbessern.
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 Scaleway-Angebot ist ebenfalls sehr gut, und alles funktioniert größtenteils einwandfrei.
Scaleway-Multipart-Uploads unterstützen nur ein Maximum von 1.000 Teilen. Dies entspricht nicht Amazon S3, das ein Maximum von 10.000 Teilen unterstützt. Bei größeren Instanzen führt dies dazu, dass Discourse Backups fehlschlagen, und der unvollständige Upload muss möglicherweise manuell gelöscht werden, bevor weitere Versuche unternommen werden. Für kleine Instanzen ist dies jedoch kein Problem. Scaleway scheint sehr offen für Feedback zu sein, also wenn Sie diese Grenze geändert haben möchten, sollten Sie sie kontaktieren.
Beachten Sie, dass Discourse für den Parameter DISCOURSE_S3_ENDPOINT den Endpunkt der gesamten Region verwendet: https://s3.{region}.scw.cloud. Der im Scaleway-Dashboard gefundene „Bucket-Endpunkt“ hat das Format https://{bucketName}.s3.{region}.scw.cloud. Lassen Sie das Bucket-Name-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
Sie müssen CORS überspringen und es manuell konfigurieren.
Es gibt Berichte, dass „clean up orphan uploads“ bei BackBlaze nicht korrekt funktioniert. Sie müssen die Lebenszyklusregeln für Ihren Bucket ändern, damit die Bereinigung von Waisen 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 initialen Migration zu B2 können Sie auf das Limit von 2.500 kostenlosen täglichen Class-C-Transaktionen stoßen. Sie müssen eine Zahlungsmethode hinzufügen, um die Limits zu entfernen.
MinIO Storage Server
Es gibt einige Fallstricke und Anforderungen, die erfüllt sein müssen, bevor Sie den MinIO-Storage-Server als Alternative zu S3 verwenden können:
- Sie verfügen über eine vollständig konfigurierte MinIO-Serverinstanz.
- Die Domain-Unterstützung ist in der MinIO-Konfiguration für domainspezifische Bucket-URLs aktiviert. Dies ist eine zwingende Einrichtungsvoraussetzung für MinIO und Discourse, da MinIO immer noch die veralteten S3-„Path“-Stile unterstützt, die in Discourse nicht mehr unterstützt werden.
- Sie haben die DNS-Konfiguration ordnungsgemäß für MinIO eingerichtet, sodass Bucket-Subdomains ordnungsgemäß auf den MinIO-Server aufgelöst werden und der MinIO-Server mit einer Basisdomain konfiguriert ist (in diesem Fall
minio.example.com). - Der Bucket
discourse-dataexistiert auf dem MinIO-Server und hat eine „public“-Richtlinie darauf gesetzt. - Ihre S3-CDN-URL zeigt auf ein ordnungsgemäß konfiguriertes CDN, das auf den Bucket zeigt und Anfragen zwischenspeichert, wie zuvor in diesem Dokument angegeben.
- Ihre 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 dies zu CORB-Problemen führen.
Unter der Annahme, dass die oben genannten Fallstricke und Voraussetzungen erfüllt sind, würde eine Beispielkonfiguration wie folgt 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 ist auf MinIO weiterhin aktiviert, 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 daher kein BucketCORS (S3-API).
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 bereitzustellen, besteht darin, einen Flexify.IO-Server hinzuzufügen, der das Azure Storage-Protokoll in S3 übersetzt.
Zum Zeitpunkt dieses Schreibens ist der Dienst auf Azure kostenlos, und Sie benötigen nur eine sehr grundlegende (günstige) VM-Tier, um ihn zu starten. Es erfordert jedoch etwas Einrichtung.
- Erstellen Sie im Azure-Portal eine neue Ressource von
Flexify.IO - Amazon S3 API for Azure Blob Storage. - Für eine leichte Nutzung scheint die minimale VM-Konfiguration gut zu funktionieren. Sie können die meisten Standardkonfigurationen akzeptieren. Vergessen Sie nicht, die PEM-Schlüsseldatei zu speichern, wenn Sie die VM erstellen.
- Navigieren Sie zum Flexify.IO-VM-Link und betreten Sie das System. Folgen Sie den Anweisungen, um den Azure Blob Storage-Datenanbieter und den generierten S3-Endpunkt einzurichten. Stellen Sie sicher, dass die Endpunkt-Konfigurationseinstellung „Öffentlicher Lesezugriff auf alle Objekte in virtuellen Buckets“ auf true gesetzt ist. Kopieren Sie die S3-Endpunkt-URL und die Schlüssel.
- Drücken Sie New Virtual Bucket und erstellen Sie einen virtuellen Bucket. Er kann denselben Namen wie Ihr Azure Blob Storage-Container haben oder ein anderer Name sein. Verknüpfen Sie beliebige Container, um sie in diesen virtuellen Bucket zu mergen. Dieser virtuelle Bucket wird verwendet, um einen öffentlich lesbaren Bucket über S3 bereitzustellen.
- Standardmäßig installiert Flexify.IO ein selbstsigniertes SSL-Zertifikat, während ein S3-Endpunkt HTTPS erfordert. Verbinden Sie sich per SSH mit der VM unter Verwendung der Schlüsseldatei (der Benutzername ist standardmäßig
azureuser) und ersetzen Sie die folgenden Dateien durch die korrekten Dateien:
-
/etc/flexify/ssl/cert.pem– ersetzen Sie durch die Zertifikatsdatei (PEM-Kodierung) -
/etc/flexify/ssl/key.pem– ersetzen Sie durch die private Schlüsseldatei (PKCS#8 PEM-Kodierung, das ist die, die mitBEGIN PRIVATE KEYbeginnt und nicht mitBEGIN RSA PRIVATE KEY, was PKCS#1 ist)Diese Dateien gehören root, sodass Sie
sudoverwenden müssen, um sie zu ersetzen. Am besten stellen Sie sicher, dass die Ersatzdateien denselben Besitz und dieselben Berechtigungen wie die Originaldateien haben, wasroot:rootund600bedeutet.
- Standardmäßig erstellt Flexify.IO einen S3-Dienst auf Root-Ebene mit mehreren Buckets. Discourse erfordert die Unterstützung von Subdomains für Buckets. Gehen Sie zu:
Ihre Flexify.IO-VM-IP/flexify-io/manage/admin/engines/configs/1, was eine versteckte Konfigurationsseite öffnet! - Geben Sie die S3-Basisdomain (sagen wir
s3.mydomain.com) im Feld „Endpoint hostname“ ein, das standardmäßig leer sein sollte. Drücken Sie Save, um die Einstellung zu speichern. - Starten Sie die Flexify.IO-VM im Azure-Portal neu.
- Ordnen Sie in Ihrem DNS
s3.mydomain.comund*.s3.mydomain.comder Flexify.IO-VM-IP zu. - Setzen Sie in Discourse Folgendes auf der Admin-Seite (ja, die Einstellungen müssen nicht in
app.ymlsein):
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> (beliebiger Container ist in Ordnung, da er keinen öffentlichen Lesezugriff erfordert und Flexify.IO sie automatisch bereitstellt)
backup location: s3
Die Verwendung desselben Buckets für Produktion und Staging wird nicht empfohlen. Wenn Sie es trotzdem tun, treffen Sie Maßnahmen, um sicherzustellen, dass Ihre Staging-Site Ihre Produktions-Assets nicht löscht (setzen Sie mindestens s3 disable cleanup und achten Sie darauf, dass sie nicht die Backups der Produktion löscht).
Wasabi
@pfaffman hat Wasabi für Backups ausprobiert, aber es schien intermittierend und stillschweigend zu fehlschlagen, wodurch Backups auf der Festplatte verblieben und schließlich die Festplatte voll liefen. Weder Wasabi noch Meta hatten Hinweise, daher empfehle ich es nicht, obwohl Ihre Erfahrungen abweichen können. @pfaffman ist sich nun ziemlich sicher, dass dieses Problem darauf zurückzuführen war, dass Backups und automatische Neustarts irgendwie gleichzeitig 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 virtuellen Host-Zugriff auf Buckets und funktioniert nicht.
Cloudflare R2
Um Cloudflare R2 zu konfigurieren, müssen Sie die relevanten Einstellungen im Cloudflare-Dashboard unter R2 Object Storage konfigurieren.
Je nach Ihren Anforderungen (Uploads oder Backups oder beides) sind dies die relevanten Einstellungen, die Sie in Ihre app.yml-Datei einfügen oder in Ihren Admin-All site settings nach S3 suchen können:
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 Sie Ihre app.yml nicht bearbeiten möchten, können Sie dies in der Admin-UI tun:
„Admin → All site settings“ (nach S3 suchen):
- Enable S3 uploads =
true - Enable direct S3 uploads =
true - S3 access key ID =
"xxx" - S3 secret access key =
"xxx" - S3 region =
any - S3 upload bucket =
your upload bucket name - S3 endpoint =
https://<your-account-id>.r2.cloudflarestorage.com - S3 CDN URL =
https://uploads.yourdomain.com - S3 use ACLs =
false(dies deaktivieren!) - S3 backup bucket =
your backup bucket name - Backup location =
S3
Hinweise:
-
API-Token-Berechtigungen: Da Discourse nur ein Satz von Anmeldeinformationsfeldern hat, muss das API-Token, das Sie in Cloudflare generieren, Berechtigungen haben, um sowohl auf Ihren Upload-Bucket als auch auf Ihren Backup-Bucket zuzugreifen. Wenn Sie Ihr Token erstellen, wählen Sie entweder „Auf alle Buckets anwenden“ oder verwenden Sie „Auf bestimmte Buckets anwenden“ und stellen Sie sicher, dass beide angehakt sind. Stellen Sie außerdem sicher, dass Sie beim Erstellen des API-Schlüssels
Object Read & Writeauswählen (standardmäßig ist nurObject Read onlyaktiviert). -
Beim Kopieren der Endpunkt-URL von Cloudflare kann der Bucket-Name an die URL angehängt werden – Sie sollten den Bucket-Namen am Ende der Zeichenfolge in Ihrer
.yml-Datei löschen, wenn er eingefügt wird. -
Kommentieren Sie
# DISCOURSE_S3_USE_CDN_URL_FOR_ALL_UPLOADS: trueaus, wenn Sie Ihren R2-Upload-Bucket für alle Uploads verwenden möchten, einschließlichPDF- undZIP-Dateien. (Beachten Sie, dass dies alle hochgeladenen Dateien über einen direkten Link öffentlich verfügbar macht.) -
Wenn Sie
DISCOURSE_ENABLE_DIRECT_S3_UPLOADS(true) aktivieren, sollten SieDISCOURSE_S3_USE_ACLS(false) deaktivieren. Dies liegt daran, dass Cloudflare R2 Bucketebene-Berechtigungen verwendet; Ihr Upload-Bucket sollte öffentlich und Ihr Backup-Bucket privat sein. Für Cloudflare R2-Uploads müssen Sie die CORS-Regel-Rake-Aufgaben nicht konfigurieren oder IAM-JSON schreiben, da Sie dies im Cloudflare-Dashboard konfigurieren, wenn Sie Ihre Bucket-Berechtigungen einrichten. Das Cloudflare-„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 unterCORS Policyersetzt die Notwendigkeit der Rake-Aufgabe.
[
{
"AllowedOrigins": [
"https://forum.yourdomain.com"
],
"AllowedMethods": [
"GET",
"PUT",
"POST",
"DELETE",
"HEAD"
],
"AllowedHeaders": [
"*"
],
"ExposeHeaders": [
"ETag"
],
"MaxAgeSeconds": 3000
}
]
Contabo
@tuxed hat versucht, Contabo Object Storage für S3-kompatible Uploads zu verwenden. 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 Ihr rake uploads:migrate_to_s3 fehlschlägt, sollten Sie diese Befehle eingeben, um zuerst zu zählen und dann als nicht-sicher zu markieren, welche Uploads dies sind, vorausgesetzt, Sie wissen, dass sie nicht sicher sein müssen, in welchem Fall Sie AWS S3 verwenden müssen.
./launcher enter app
rails c
Upload.where(secure: true).count
Upload.where(secure: true).update_all(secure:false)
Oracle Cloud unterstützt keinen virtuellen Host-Zugriff auf Buckets und funktioniert nicht. ↩︎
