Wird die Contabo S3-Unterstützung/Kompatibilität hinzugefügt? Oder hat jemand eine Problemumgehung gefunden, um sie zum Laufen zu bringen?
2 „Gefällt mir“
Wir, die Discourse-Maintainer, unterstützen nur AWS S3. Die hier aufgeführten Anbieter wurden entweder von uns oder von der Community getestet, um zu sehen, ob sie genügend von der S3-API implementieren, um mit Discourse kompatibel zu sein.
Laut dem OP hat @tuxed Contabo getestet und festgestellt, dass es mangelhaft ist. Es liegt an Contabo, seine Implementierungskonformität mit S3 weiterzuentwickeln, wenn sie dies im Einklang mit seinen Geschäftsinteressen erachten, nicht etwas, das wir tun können.
4 „Gefällt mir“
Ist das immer noch fehlerhaft? Warum ist Digitalocean CDN nicht gut?
1 „Gefällt mir“
Haben Sie die Links verfolgt?
Es sieht so aus, als ob das CDN nichts über Metadaten weiß. Aber Sie könnten es ausprobieren und sehen, ob es funktioniert! Lassen Sie uns wissen, wenn Sie es tun. Ich habe mich gefragt, ob es gerade erst kürzlich behoben wurde. Nach der Dokumentation werde ich es selbst bald nicht mehr versuchen.
2 „Gefällt mir“
Ich suche nach einer einfachen Möglichkeit, CDN-Unterstützung für mein Forum auf DigitalOcean hinzuzufügen. Wenn S3 einfacher ist, würde ich diese Option wählen.
Ich möchte kein Risiko mit einer Einrichtung eingehen, die nicht gut funktioniert hat.
2 „Gefällt mir“
Die empfohlene Lösung ist einfach, deren CDN nicht zu verwenden. Sie können Spaces verwenden, wenn Sie die obigen Anweisungen befolgen, und etwas wie bunny.net für das CDN. Es ist billig und einfach.
Aws S3 ist das, was cdck verwendet, daher ist es etwas besser getestet und unterstützt, aber es sei denn, Sie sind bereits mit AWS vertraut, ist der Spaces-Bucket eine gute Lösung. Verwenden Sie einfach nicht das Digital Ocean CDN.
2 „Gefällt mir“
Ich habe das gerade hinter mir – CDN-Einrichtung, vorerst werden Bilder lokal gehalten – zuerst mit Fastly, dann mit einem anderen, an das ich mich nicht mehr erinnere. Habe mich für Bunny.net entschieden. Sehr einfach einzurichten. Sie haben Anleitungen speziell für Discourse. Wir sind selbst gehostet in DO mit über 100 GB an Bildern. 65 % Cache-Trefferquote und steigend.
2 „Gefällt mir“
s3 konfiguriere Tombstone-Richtlinie funktioniert nur auf aws.amazon?
1 „Gefällt mir“
Nein. Es ist ein Problem nur bei Backblaze.
2 „Gefällt mir“
3 Beiträge wurden in ein neues Thema aufgeteilt: Exploring Solutions for User Profile Picture Upload Problems
Puh, wo soll ich anfangen? Ich verwende Cloudflare für Caching und DNS und Backblaze B2 für die Speicherung. Ich konnte es zum Laufen bringen, aber nur teilweise. Während eines ./launcher rebuild app sah ich, dass Assets hochgeladen wurden, also war ich super aufgeregt, dass es anscheinend funktionierte. Nachdem der Rebuild erfolgreich abgeschlossen war, konnte ich die Seite nicht aufrufen. Ich sehe nur einige sich bewegende Punkte in der Mitte der Seite.
Basierend auf dem Backblaze-Artikel Deliver Public Backblaze B2 Content Through Cloudflare CDN habe ich einen Proxied CNAME-Eintrag eingerichtet, der auf den Friendly URL-Ursprung f000.backblazeb2.com mit dem Namen gtech-cdn zeigt.
CNAME gtech-cdn → f000.backblazeb2.com
Der Artikel spricht auch über Page Rules; ich habe versucht, sie ein- und auszuschalten, aber ohne Erfolg.
Hier sind die relevanten Konfigurationspunkte:
DISCOURSE_HOSTNAME: mmhmm.com
DISCOURSE_CDN_URL: https://mmhmm.com
DISCOURSE_USE_S3: true
DISCOURSE_S3_REGION: us-west-000
DISCOURSE_S3_ENDPOINT: https://s3.us-west-000.backblazeb2.com
DISCOURSE_S3_ACCESS_KEY_ID: <secret>
DISCOURSE_S3_SECRET_ACCESS_KEY: <secret>
DISCOURSE_S3_CDN_URL: https://gtech-cdn.mmhmm.com
DISCOURSE_S3_BUCKET: gtech-uploads
DISCOURSE_S3_BACKUP_BUCKET: gtech-uploads/backups
DISCOURSE_BACKUP_LOCATION: s3
Unter dem Abschnitt **hooks:**...
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
Eines der Dinge, die mich verwirren, ist, was ich in die beiden Variablen DISCOURSE_S3_CDN_URL und DISCOURSE_CDN_URL eintragen soll. Habe ich sie basierend auf den von mir bereitgestellten Informationen richtig eingestellt?
Wenn ich mir die Browser-Entwicklertools-Konsole ansehe, erhalte ich 404-Fehler bei .js-Skripten. Die URL scheint nicht richtig aufgebaut zu werden. Sollte dort nicht /file/ vor /assets stehen? Wenn ich das manuell hinzufüge, um eine richtige URL zu erstellen, funktioniert es:
https://gtech-cdn.mmhmm.com/file/gtech-uploads/assets/google-universal-analytics-v4-e154af4adb3c483a3aba7f9a7229b8881cdc5cf369290923d965a2ad30163ae8.br.js
Vielen Dank für jede Hilfe, sie wird sehr geschätzt!!!
1 „Gefällt mir“
https://gtech-cdn.mmhmm.com wird nicht aufgelöst, das ist also das Erste, was behoben werden muss.
Ich bin mir nicht sicher, ob Sie Cloudflare auf diese Weise als CDN verwenden können, aber vielleicht irre ich mich.
1 „Gefällt mir“
Entschuldigung, ich hätte erwähnen sollen, dass mmhmm.com eine gefälschte Domain ist. Sie antwortet auf einen Ping.
Was die Tatsache betrifft, dass Cloudflare nicht als CDN verwendet werden kann, verstehe ich das wohl nicht. Der Artikel, den ich verlinkt habe, ist eindeutig für die Verwendung als CDN gedacht. Wenn das nicht stimmt, dann frage ich mich wieder, welche Werte für die beiden Variablen DISCOURSE_S3_CDN_URL und DISCOURSE_CDN_URL verwendet werden sollen.
Viele Grüße,
Wenn Sie gefälschte URLs angeben, können Sie nur gefälschte Antworten erhalten.
Dient die URL den erwarteten Daten? Können Sie sie von der Foren-URL abrufen?
Ich denke, das S3 CDN sollte funktionieren. Es verwendet die Foren-URL für das Forum-CDN, bei dem ich mir nicht sicher bin.
Ein normales CDN hat eine andere URL als das Forum, und das CDN kann sich darauf verlassen, dass die Daten statisch sind, anstatt raten zu müssen, was dynamisch ist.
1 „Gefällt mir“
Ich gebe mein Bestes, meine Informationen nicht in verschiedenen Foren zu verbreiten, also entschuldigen Sie bitte meine Geheimhaltung in dieser Angelegenheit.
Das Forum befindet sich unter „https://mmhmm.com“, einem Cloudflare-DNS-Eintrag, der weitergeleitet (gecacht) wird. Bevor Discourse für die Verwendung von Backblaze konfiguriert wurde, funktionierte alles ordnungsgemäß.
„https://gtech-cdn.mmhmm.com“ löst, wie bereits erwähnt, auf und antwortet auch auf einen Ping. Das Ziel des CNAME-Eintrags, f000.backblazeb2.com, wird ebenfalls aufgelöst. Dieser B2 Friendly URL-Ursprung ist das, was der Artikel zur Verwendung vorgibt. Das ist jedoch nicht das Problem. Das Problem ist, dass Discourse URLs für die .js-Dateien über eine ungültige URL bereitstellt, die niemals funktionieren wird, da der Teil „/file/gtech-cdn“ des Pfades fehlt. Wenn Sie eine dieser unvollständigen .js-URLs nehmen und die fehlenden Informationen manuell hinzufügen, wird der Text der .js-Datei problemlos geladen.
Natürlich versuche ich immer noch zu verstehen, wie das alles mit diesen beiden Variablen funktionieren soll. Ich bin eher ein visueller Lerner und könnte wirklich ein Flussdiagramm oder etwas Ähnliches gebrauchen, um zu verstehen, was mit den Interaktionen zwischen Cloudflare CDN, Discourse und Backblaze B2 geschehen soll.
Vielen Dank für Ihre Hilfe.
Und, ich werde versuchen, auf Ihren letzten Satz über ein normales CDN einzugehen…
Der Artikel von Backblaze lässt Sie zwei Seitenregeln pro Bucket erstellen (in meinem Fall wird 1 Bucket verwendet), was, wenn ich es richtig verstehe, in gewisser Weise wie eine Firewall-Regel funktioniert, was die Verarbeitung angeht.
Regel 1 besagt, dass https://gtech-cdn.mmhmm.com/file/*/* die Standard-Zwischenspeicherung verwenden soll (die anderswo in Cloudflare auf 1 Monat eingestellt ist).
Regel 2 leitet alles (302 - temporäre Weiterleitung) um, was nicht dem Muster von Regel 1 entspricht.
Das bedeutet also nicht, dass alles durch den Aufruf von mmhmm.com zwischengespeichert wird… zumindest ist das mein Verständnis.
EDIT: Das hat nicht funktioniert.
Als ich mich damit etwas mehr beschäftigt habe, habe ich aus offensichtlichen Gründen beschlossen, die S3-URL als CNAME-Ziel zu verwenden und nicht die Friendly URL, die der Backblaze-Artikel vorgeschlagen hat. Ich warte jetzt nur noch darauf, dass die TTL des DNS-Eintrags abläuft.
Bezüglich dieses Hooks:
Ich sehe nichts mit S3 in der rake --tasks-Ausgabe. Ist das noch relevant oder fehlt mir ein Plugin?
Außerdem sehe ich Folgendes, wenn ich manuell ausführe:
uploads:migrate_to_s3
rake aborted!
FileStore::ToS3MigrationError: Einige Uploads konnten nicht zum neuen Schema migriert werden. Sie müssen dies manuell beheben. (FileStore::ToS3MigrationError)
/var/www/discourse/lib/file_store/to_s3_migration.rb:156:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:59:in `migrate'
/var/www/discourse/lib/tasks/uploads.rake:126:in `migrate_to_s3'
/var/www/discourse/lib/tasks/uploads.rake:106:in `block in migrate_to_s3_all_sites'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rails_multisite-6.0.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rails_multisite-6.0.0/lib/rails_multisite/connection_management/null_instance.rb:36:in `each_connection'
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/rails_multisite-6.0.0/lib/rails_multisite/connection_management.rb:21:in `each_connection'
/var/www/discourse/lib/tasks/uploads.rake:104:in `migrate_to_s3_all_sites'
/var/www/discourse/lib/tasks/uploads.rake:100:in `block in <main>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
Tasks: TOP => uploads:migrate_to_s3
(Vollständigen Trace anzeigen, indem Sie die Aufgabe mit --trace ausführen)
root@ubuntu-s-2vcpu-4gb-nyc2-01-app:/var/www/discourse#
root@ubuntu-s-2vcpu-4gb-nyc2-01-app:/var/www/discourse# rake uploads:migrate_to_s3
Bitte beachten Sie, dass die Migration zu S3 derzeit nicht rückgängig gemacht werden kann!
6 Beiträge wurden in ein neues Thema aufgeteilt: Cloudflare R2: Einrichtung und Fehlerbehandlung bei Konfigurationsfehlern
Sieht so aus, als würde Cloudflare jetzt funktionieren:
Siehe Cloudflare R2: Navigating Setup and Handling Configuration Errors - #13 by pfaffman
2 „Gefällt mir“