Je n’ai pas réussi à comprendre pourquoi, dans la dernière mise à jour, notre installation a cessé de servir les ressources via le CDN. Nous utilisons CloudFront et cela fonctionnait bien pour servir à la fois les uploads et les ressources, mais il semble que, dans la dernière mise à jour, les ressources soient servies depuis le serveur.
Un autre problème que nous rencontrons est que, si nous passons la variable DISCOURSE_CDN_URL, Discourse commence à demander des ressources qui ne sont pas générées ou uploadées par la tâche s3:upload_assets (par exemple, les feuilles de style). Cela fait complètement planter le site avec une page blanche. Ce post mentionne quelque chose de similaire.
J’ai supprimé DISCOURSE_CDN_URL, qui était défini avec la même valeur que DISCOURSE_S3_CDN_URL, car cela cassait le site (il tentait de charger des ressources qui n’existaient pas sur S3).
En regardant en arrière le site sur lequel j’avais des difficultés, il semble que j’aie oublié le https:// dans l’URL CDN que j’utilisais. Je ne comprends pas comment cela a pu fonctionner un jour, ou, si cela n’a jamais fonctionné, comment je n’ai pas remarqué cela lorsque j’ai ajouté cette valeur incorrecte.
@eatcodetravel, bien sûr, vous devez masquer les mots de passe SMTP et les clés S3, mais je pense que vous devrez partager au moins les valeurs CDN pour que quiconque puisse émettre des hypothèses sur ce qui pourrait être le problème.
Oui, j’ai dû supprimer DISCOURSE_CDN_URL, car il a commencé à demander des ressources qui ne sont pas téléchargées sur S3 par la tâche rake s3:upload_assets, ce qui fait planter complètement le site. Peut-être que c’est la partie qui a changé et nous devons mettre à jour rake s3:upload_assets pour qu’elle fonctionne à nouveau correctement.
Oui, il est possible d’utiliser la même URL CDN pour DISCOURSE_CDN_URL et DISCOURSE_S3_CDN_URL, mais cela nécessite une énorme quantité de configuration d’authentification dans le CDN afin d’utiliser la source correcte pour chaque actif en fonction de l’URL. Par exemple, le CSS provient de l’application, le JS de S3, et ce n’est qu’un seul cas parmi des dizaines.
L’attente est donc que vous configuriez les deux : DISCOURSE_CDN_URL agit comme un « proxy » vers votre application web, tandis que DISCOURSE_S3_CDN_URL agit comme un proxy vers votre bucket de stockage d’objets.
Ah d’accord, est-ce que cela a changé récemment ? Je ne suis pas sûr que CloudFront puisse servir de proxy inverse pour notre application plutôt que pour un bucket S3.
Je vois que vous utilisez CloudFront dans meta. Y a-t-il quelque chose de particulier que vous faites pour le faire fonctionner, ou Discourse s’occupe-t-il de tout lui-même ?
Si vous inspectez cette page, vous verrez que nous avons deux URLs Cloudfront différentes. Nous utilisons donc ce que j’ai mentionné précédemment : deux distributions, l’une pour le CDN normal et l’autre pour S3.
Le problème évoqué dans le titre du post original est le suivant : le CSS provient de l’application et le JavaScript de S3. Il vous faut un CDN capable de savoir d’où provient chaque ressource et d’atteindre l’endroit nécessaire, ou alors deux CDNs. C’est d’ailleurs pourquoi nous avons deux configurations différentes.
Bien que cela ait tout à fait du sens maintenant que je le comprends, je ne suis pas sûr que cela soit documenté. Et vous risquez d’avoir des ennuis (du moins, c’est ce qui m’est arrivé !), car la tâche Rake move-uploads-to-s3 exige que vous ayez un s3_cdn. Cela explique pourquoi à plusieurs reprises, j’ai essayé de déplacer des éléments vers S3 et j’ai fini par abandonner.
Je pense qu’il serait bien d’avoir un avertissement quelque part du type : « Hé, vous ne pouvez pas avoir un CDN S3 sans un CDN d’actifs. »
Ok, maintenant je comprends ce que tu dis, je ne savais pas que c’était requis. Puis-je demander pourquoi le CSS doit provenir de l’application ? Pourquoi ne pouvons-nous pas le télécharger via la tâche rake s3:upload_assets ?
Je vais faire quelques recherches sur la manière de réaliser cela sur Cloudfront et je partagerai ici mes découvertes et les obstacles rencontrés.
Eh bien, je l’explique peut-être mal. C’est possible, mais c’est fastidieux, comme le montrent vos sujets et celui-ci en particulier.
Le site de @eatcodetravel fonctionne actuellement avec uniquement S3_CDN configuré, mais cela conduit à un état étrange où le CSS (qui bloque le rendu) est servi depuis votre serveur, tandis que les images dans les messages ne le sont pas, ce qui n’a aucun sens.
Parce que l’option Admin > Personnaliser existe. Les utilisateurs peuvent modifier le CSS depuis le panneau d’administration. De plus, les extraits JavaScript personnalisés présents dans les thèmes sont également servis depuis l’application, d’après ce que je sais.
J’ai fini par résoudre ce problème en créant une deuxième distribution CloudFront pointant vers le serveur web, tout en conservant l’autre uniquement pour S3. Merci @Falco pour ton retour, mais je conviens que cela doit être mieux documenté.
s » ?