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 .
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.
À 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 ?
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.
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 :
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.
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.
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.