Accélération CDN complète du site pour 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 « J'aime »

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 « J'aime »

Est-ce toujours nécessaire lorsque l’erreur Reason: CORS header ‘Access-Control-Allow-Origin’ missing se produit ?

Je ne trouve rien qui utilise cette variable sur Github :


Edit : le commentaire des paramètres indique toujours que c’est nécessaire, et cela fonctionne après. Je vais donc simplement accepter :slight_smile:

À l’heure actuelle en 2023, ces quatre règles doivent-elles encore être suivies strictement ? Par exemple, si j’utilisais Akamai, qui est conçu pour accélérer le nom de domaine principal avec son CDN. Quelqu’un a-t-il une configuration simplifiée des règles ci-dessous, par exemple, le message bus et le long polling doivent-ils toujours être demandés à l’origine ? Où ces paramètres devraient-ils aller ? L’URL de base du long polling semble avoir été supprimée du tableau de bord d’administration ?

2 « J'aime »

Il existe des options avancées qui vous permettent de servir des requêtes Message Bus à partir d’un domaine différent. C’est cependant très complexe.

1 « J'aime »

Ainsi, « long polling base url » doit être défini via la console Rails. Comme il a été supprimé du tableau de bord d’administration. Je dois manquer la raison publiée quelque part auparavant pour laquelle il a été supprimé si le paramètre est toujours requis pour que le site fonctionne correctement en mode CDN complet.

De même, DISCOURSE_ENABLE_CORS : true doit être défini dans app.yml.

Vous devriez la définir avec une variable d’environnement (DISCOURSE_LONG_POLLING_BASE_URL) dans votre fichier app.yml. Elle est masquée car très peu de personnes ont besoin de la définir et on suppose que si vous le faites, vous savez ce que vous faites.

1 « J'aime »

Merci, @pfaffman ! J’aurais dû savoir que toutes ces variables en majuscules devaient aller dans app.yml.
Alors, quels sont les cas d’utilisation du bus de messages qui prendront effet ? Par exemple, une réponse à un message provoquant une notification, etc. ? Je ferais un test des cas d’utilisation pour m’assurer si le bus de messages fonctionne comme prévu sur mon site sans que DISCOURSE_LONG_POLLING_BASE_URL soit défini.

Salut,
« URL de base du long polling » a-t-il été supprimé du tableau de bord administrateur ? Ou ce réglage peut-il être effectué via la console Rails ?

Le paramètre long_polling_base_url est un paramètre de site caché, mais il peut être défini depuis la console Rails si vous n’utilisez pas de variable d’environnement dans votre app.yml :

3 « J'aime »

Cette liste donne certainement plus d’informations sur Discourse.
J’ai configuré le CDN avec mon site Web, il a atteint les caches périphériques, mais je n’ai pas encore rencontré de problème de bus de messages avec ses en-têtes de réponse, mais cela ne me semble toujours pas solide. Ni défini les paramètres CORS.

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

Salut,
J’ai posté ma question dans un autre fil de discussion Full Site CDN Using AWS CloudFront - #2 by Hyan. J’ai fait la même configuration et laissé #DISCOURSE_CDN_URL: https://discourse-cdn.example.com inchangé. Puis-je le définir sur la même URL que le site Web ? Par exemple, http://forum.example.com. Sinon, il y aura des URL d’assets en chemin relatif sans nom de domaine.
J’apprécierais si @sam ou @pfaffman pouvaient donner un indice.

Je ne recommande pas d’utiliser Cloudflare comme CDN. Certaines personnes le font. Peut-être qu’ils peuvent aider.

EDIT : Oh, désolé. Il s’agit de « CDN de site complet… » Peut-être que je ne devrais pas contribuer ici.

Non, j’utilise le CDN Akamai, qui prend en charge la mise en cache du contenu dynamique.
D’après le premier message de ce fil, il semble que je devrais définir DISCOURSE_CDN_URL comme un CDN qui ne sert pas le site complet, même si l’URL est la même que l’URL du site Web. Je ne suis tout simplement pas sûr si sa définition peut casser mon site et entraîner d’autres résultats irréversibles, me forçant à réinstaller le logiciel à partir de zéro. Dans ce post Full Site CDN Using AWS CloudFront, l’auteur ne le définit pas et laisse DISCOURSE_CDN_URL inchangé, et cela ne nécessite pas d’URL distincte pour servir message-bus/long-polling. J’utilise cette solution et mon site Web fonctionne bien jusqu’à présent. Le seul inconvénient de la solution est qu’il y a beaucoup d’URL relatives (pas d’URL de base, car la valeur de DISCOURSE_CDN_URL est vide) présentes dans la source de la page, ce qui donne l’impression d’un site Web qui n’est pas de niveau production.

Pour faire suite à mes questions, j’ai trouvé un post similaire à celui que je pose ici CloudFront not caching static files - #4 by Falco
J’apprécie la réponse de @Falco, dans cette configuration CDN pour le site complet, puis-je définir DISCOURSE_CDN_URL comme étant le même que DISCOURSE_HOSTNAME ? Comme je suppose que le CDN pour le site complet signifie que le CDN accélère l’URL de l’hostname, ce qui rend DISCOURSE_CDN_URL identique à DISCOURSE_HOSTNAME. Mais il n’y a pas de documentation décente à ce sujet dans meta.

Salut, y a-t-il un modèle pour le lapin ?

Vous n’avez pas besoin d’un modèle pour cela, configurez simplement bunny pour qu’il récupère les données de votre site discourse et définissez DISCOURSE_CDN_URL sur le point de terminaison cdn fourni par bunny dans app.yml.

1 « J'aime »

J’essaie avec “CDN acceleration” avec mon IP de VPS avec Bunny DNS. Ça fonctionne, mais tous les utilisateurs ont la même IP.

J’ai trouvé la configuration, elle s’appelle “X-Real-Ip”.