J’ai une question concernant la technologie CDN.
Ai-je raison de penser qu’un CDN ne peut mettre en cache que les fichiers de mon site et non les fichiers hotlinkés provenant d’un autre site ?
Je stocke les fichiers de catalogue (MPS et images) sur un autre serveur et je les hotlink sur mon site Discourse. Ai-je raison de penser que ces fichiers ne seront pas mis en cache par le CDN ? Existe-t-il un moyen de mettre en cache également les fichiers hotlinkés ?
À moins que vous ne disiez à Discourse de ne pas le faire, il récupérera ces images distantes vers son propre stockage d’images. Ce qui suit suppose que vous avez désactivé cette option.
Vous devriez placer ce site derrière un CDN, puis partager l’URL du CDN avec Discourse.
Si vous placez un CDN devant votre site d’images mais partagez l’URL d’origine avec Discourse, vous pouvez utiliser une fonctionnalité intégrée pour remplacer l’URL d’origine par l’URL du CDN.
Ai-je raison de penser que si j’active la fonctionnalité CDN dans Discourse et que je désactive l’enregistrement de l’origine dans Discourse, le service CDN mettra en cache ces fichiers externes et Discourse remplacera tous les liens vers des fichiers hotlinkés depuis un autre site ?
Je doute que cela puisse mettre en cache des fichiers externes hotlinkés depuis d’autres sites. Quelqu’un peut-il le confirmer ?
Pour info – j’ai publié un nouveau sujet sur la configuration de l’accélération CDN complète du site (et de la terminaison SSL) avec AWS CloudFront ici (lien ci-dessous). Attention aux dragons ici, alors avancez prudemment.
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 
À 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 ?
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.
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.
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.
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”.