Vollständige CDN-Beschleunigung für Discourse

I have a question concerning CDN technology.

Am I right that cdn can only cache the files in my site and can’t cache hotlinked files from another site?

I store catalogue files (mps and pictures) on another server and hotlink them on my Discourse site. Am I right that such files won’t be cached by cdn? Is there a way to cache the hotlinked files too?

Unless you tell discourse not to, it will pull those remote images to its own image store. The below assumes you turned that off.

You should put that site behind CDN and then share the CDN url to discourse.

If you put a CDN in front of your image site but share the origin url to discourse, You can use a built in feature to replace the origin url with the CDN url .

2 „Gefällt mir“

Am I right, that if I activate the CDN feature in Discourse and switch off saving the origin to Discourse, the cdn service will cache these external files and Discourse will replace all the links to files hotlinked from another site?

I doubt that can caches external files hotlinked from other sites. Can anybody approve it?

FYI - I’ve posted a new thread on how to setup full site CDN acceleration (and SSL termination) using AWS Cloudfront here (link below). There be dragons here - so tread lightly.

1 „Gefällt mir“

Ist das immer noch erforderlich, wenn der Fehler Reason: CORS header ‘Access-Control-Allow-Origin’ missing auftritt?

Ich kann nichts finden, das diese Variable in Github verwendet:


Bearbeiten: Der Einstellungs-Kommentar besagt immer noch, dass er benötigt wird, und es funktioniert danach. Also werde ich einfach akzeptieren :slight_smile:

Gilt heutzutage (2023) noch, dass die unten genannten vier Regeln strikt befolgt werden müssen? Wenn ich zum Beispiel Akamai verwenden würde, das darauf ausgelegt ist, die Hauptdomain mit seinem CDN zu beschleunigen. Hat jemand eine aufbereitete Konfiguration der unten genannten Regeln, zum Beispiel ob Message Bus und Long Polling immer noch Anfragen an den Origin senden müssen? Wo sollten diese Einstellungen vorgenommen werden? Die Basis-URL für Long Polling scheint aus dem Admin-Dashboard entfernt worden zu sein?

2 „Gefällt mir“

Es gibt einige erweiterte Einstellungen, mit denen Sie Message Bus-Anfragen von einer anderen Domain aus bedienen können. Es ist jedoch sehr komplex.

1 „Gefällt mir“

Der „long polling base url“ muss über die Rails-Konsole gesetzt werden. Da er aus dem Admin-Dashboard entfernt wurde. Ich habe wahrscheinlich den Grund verpasst, der irgendwo zuvor gepostet wurde, warum er entfernt wurde, wenn die Einstellung immer noch erforderlich ist, damit die Website im Full-Site-CDN-Modus gut funktioniert.

Ebenso muss DISCOURSE_ENABLE_CORS: true in app.yml gesetzt werden.

Sie sollten ihn über eine Umgebungsvariable (DISCOURSE_LONG_POLLING_BASE_URL) in Ihrer app.yml festlegen. Er ist versteckt, da nur sehr wenige Personen ihn festlegen müssen und davon ausgegangen wird, dass Sie wissen, was Sie tun, wenn Sie dies tun.

1 „Gefällt mir“

Danke, @pfaffman! Ich hätte wissen müssen, dass all diese großgeschriebenen Variablen in die app.yml gehören.
Welche Anwendungsfälle von message-bus werden also wirksam? Zum Beispiel eine Antwort auf einen Beitrag, die eine Benachrichtigung usw. verursacht? Ich würde einen Anwendungsfall-Test durchführen, um sicherzustellen, ob message-bus auf meiner Website wie erwartet funktioniert, ohne DISCOURSE_LONG_POLLING_BASE_URL gesetzt zu haben.

Hallo,
Wurde die „long polling base url“ aus dem Admin-Dashboard entfernt? Oder kann diese Einstellung über die Rails-Konsole vorgenommen werden?

long_polling_base_url ist eine versteckte Site-Einstellung, kann aber von der Rails-Konsole aus festgelegt werden, wenn Sie keine Umgebungsvariable in Ihrer app.yml verwenden:

3 „Gefällt mir“

Diese Liste gibt definitiv mehr Einblicke in Discourse.
Ich habe das CDN mit meiner Website eingerichtet, es hat die Edge-Caches erreicht, habe aber noch keine Probleme mit der Message-Bus-Antwort-Header erlebt, fühlt sich aber immer noch nicht solide an. Weder CORS-Einstellungen gesetzt.

Cache-Control: must-revalidate, private, max-age=0

Hallo,
Ich habe meine Frage in einem anderen Thread gepostet: Full Site CDN Using AWS CloudFront - #2 by Hyan. Ich habe die gleiche Konfiguration vorgenommen und #DISCOURSE_CDN_URL: https://discourse-cdn.example.com unverändert gelassen. Kann ich dies auf dieselbe URL der Website setzen? Zum Beispiel http://forum.example.com. Andernfalls gibt es Assets-URLs im relativen Pfad ohne Domainnamen.
Ich wäre dankbar, wenn @sam oder @pfaffman einen Hinweis geben könnten.

Ich empfehle die Nutzung von Cloudflare nicht als CDN. Manche Leute tun es. Vielleicht können sie helfen.

EDIT: Oh, Entschuldigung. Das ist „Full Site CDN…“ Vielleicht sollte ich hier nichts beitragen.

Nein, ich verwende das Akamai CDN, das dynamische Inhalte zwischenspeichern kann.
Aus dem ersten Beitrag in diesem Thread geht hervor, dass ich DISCOURSE_CDN_URL so einstellen sollte, dass es nicht wie eine vollständige Website-CDN funktioniert, obwohl die URL dieselbe wie die Website-URL ist. Ich bin mir nur nicht sicher, ob die Einstellung dazu führt, dass meine Website kaputt geht und andere unumkehrbare Ergebnisse erzielt werden, und ich am Ende die Software von Grund auf neu installieren muss. In diesem Beitrag Full Site CDN Using AWS CloudFront hat der Autor es nicht eingestellt und DISCOURSE_CDN_URL unverändert gelassen, und es ist keine separate URL erforderlich, um message-bus/long-polling zu bedienen. Ich verwende diese Lösung und meine Website läuft bisher gut. Der einzige Nachteil der Lösung ist, dass viele relative URLs (keine Basis-URL, da der Wert von DISCOURSE_CDN_URL leer ist) im Seitenquelltext vorhanden sind, was sie nicht wie eine Website auf Produktionsniveau aussehen lässt.

Als Nachbereitung auf meine Fragen habe ich einen ähnlichen Beitrag gefunden, um den es in diesem Beitrag geht: CloudFront not caching static files - #4 by Falco
Ich schätze die Antwort von @Falco. Kann ich bei diesem Full-Site-CDN-Setup DISCOURSE_CDN_URL auf dasselbe wie DISCOURSE_HOSTNAME setzen? Ich gehe davon aus, dass Full-Site-CDN bedeutet, dass das CDN die URL des Hostnamens beschleunigt, was DISCOURSE_CDN_URL zum selben wie DISCOURSE_HOSTNAME macht. Aber hier gibt es keine vernünftige Dokumentation dazu in Meta.

Hey, gibt es eine Vorlage für Kaninchen?

Sie benötigen keine Vorlage dafür. Konfigurieren Sie einfach Bunny so, dass es von Ihrer Discourse-Site abruft, und setzen Sie die DISCOURSE_CDN_URL auf den von Bunny bereitgestellten CDN-Endpunkt in app.yml.

1 „Gefällt mir“

Ich versuche es als „CDN-Beschleunigung“ mit meiner VPS-IP mit Bunny DNS. Es funktioniert, aber alle Benutzer haben die gleiche IP.

Ich habe gerade die Konfiguration gefunden, sie heißt „X-Real-Ip“.