Définition des liens DISCOURSE_S3_CDN_URL vers des ressources dans l'URL CDN S3

Soutien
1

I had this problem before and decided that I was crazy, confused, or the database on the site was suspect, but this is on a brand new site. Also, I was on Digital Ocean spaces, so I thought it might be a problem somehow.

I’m trying again to figure out how to keep images on AWS S3 like I think the Big Boys do.

Here’s what I have in the env section:

  DISCOURSE_S3_ACCESS_KEY_ID: 'key'
  DISCOURSE_S3_SECRET_ACCESS_KEY: 'lock'
  DISCOURSE_BACKUP_LOCATION: 's3'
  DISCOURSE_S3_BUCKET: 'lc-xyz'
  DISCOURSE_S3_BUCKET_NAME: 'lc-xyz'
  DISCOURSE_S3_BACKUP_BUCKET: 'lc-xyz/backups'
  DISCOURSE_S3_UPLOAD_BUCKET: 'lc-xyz/uploads'
  DISCOURSE_S3_CDN_URL: 'https://lc-rbx.s3.amazonaws.com'

When I include the s3 cdn url the site breaks because all of the links to the assets are on S3 like https://lc-xyz.s3.amazonaws.com/assets/plugin-third-party-01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b.br.js.

Because if you define s3 cdn url Discourse looks for the assets on the s3_cdn_url.

I did a rebuild, but the assets are still missing. I can do a

rake s3:upload_assets

Is there an after_bundling_assets stanza that I could add that to? (I know about after_db_migrate and after_bundle_exec, but don’t know if those would work.)

Do assets get produced some other time? (It would seem like when themes get modified assets would change.)

If I also had a “push CDN like normal”, would that keep this from happening?

Is there some best practice that I’m missing?

2

You can use after_assets_precompile as the hook for that rake task.

3

Aha! Thanks very much for that. Where does the list of those things live?

I’m still confused why this is necessary, especially since you seemed confused before. (Or maybe I should be happy that I can push all this stuff to S3, now that I know how to do it–And I think that it was you who said that one could use CloudFlare’s free CDN to front an AWS bucket.)

4

Je réessaie. J’ai des uploads qui partent vers S3. Ça fonctionne.

J’ai configuré Cloudflare pour mettre le site en CDN. Si je saisis https://lc-XXX.literatehosting.com/uploads dans le paramètre du site s3_cdn_url, les nouveaux uploads sont envoyés vers le bucket S3 et l’image est liée à l’URL du CDN, et tout fonctionne.

MAIS si j’essaie de définir s3_cdn_url avec une variable d’environnement dans app.yml (ou en éditant manuellement config/discourse.conf puis en exécutant sv restart unicorn), tous les assets sont chargés depuis S3 (alors qu’ils ne s’y trouvent pas). Cela pourrait passer, mais si j’essaie d’exécuter rake s3:upload_assets, cela indique que S3 n’est pas configuré.

5

Je suis tombé sur cela en résolvant un conflit de noms de paramètres.

Je pense (et espère, car cela signifie que je comprends cela et que je n’ai pas écrit de contre-sens absolu dans le thread lié ci-dessus) que si vous supprimez ces deux lignes :

DISCOURSE_S3_BUCKET: 'lc-xyz'
DISCOURSE_S3_BUCKET_NAME: 'lc-xyz'

Vous pouvez alors définir DISCOURSE_S3_CDN_URL, et il ne sera utilisé que pour les téléchargements, pas pour les ressources.

6

Je pense que vous comprenez, et grâce à vous, je suis au moins plus proche de comprendre moi-même ! Merci beaucoup !

7

Je tombe sur ce problème et je suis toujours très confus après avoir lu ce fil de discussion…

J’essaie de servir les uploads S3 (pas les assets compilés) via un CDN (Cloudfront).

Si je configure « s3 cdn url » via l’écran des paramètres, cela fonctionne comme prévu (enfin… sauf pour System upload not using s3 cdn url).

Cependant, si je configure via DISCOURSE_S3_CDN_URL et que je reconstruis, l’interface utilisateur est cassée car elle tente de charger les assets compilés depuis mon URL CDN S3.

Il semble que DISCOURSE_S3_CDN_URL / s3_cdn_url ne devraient affecter que les uploads, et que DISCOURSE_CDN_URL ne devrait affecter que les assets.

8

C’est aussi mon expérience. J’ai fini par créer un plugin pour définir S3_CDN_URL.

9

@pfaffman Cela semble donc devoir être signalé comme un bug, n’est-ce pas ?

10

Peut-être. Ce n’est pas une fonctionnalité susceptible d’être utilisée par les hébergeurs personnels habituels, elle sera donc une priorité faible. De plus, je pense qu’il va bientôt y avoir un changement dans la façon dont les paramètres globaux et les paramètres masqués par les paramètres globaux fonctionnent, donc cela sera probablement résolu à ce moment-là.

11

Il semble que le même problème se produise ici.
@pfaffman, j’ai besoin de votre aide.
Utilisez-vous CloudFront pour obtenir l’URL CDN de domaine personnalisé ou utilisez-vous simplement le préfixe public des objets du bucket dans l’URL CDN ?

12

Je viens de tomber là-dessus. @pfaffman, as-tu réussi à résoudre ce problème ?

J’ai réussi à faire fonctionner les téléchargements en définissant manuellement s3_cdn_url dans les paramètres du site, mais idéalement, je dois pouvoir définir la variable d’environnement (ENV) globalement lors du déploiement. Quand je le fais, je rencontre le même problème : Discourse essaie de chercher les ressources à l’adresse s3_cdn_url, ce qui me semble être un bug de discourse/lib/content_security_policy/default.rb at main · discourse/discourse · GitHub

13

Je pense que je viens juste de définir la valeur dans la base de données.

Mon hypothèse est que la solution consiste à trouver la tâche Rake qui poussera les assets vers S3.

14

Je me demandais si l’un des membres de l’équipe @team pouvait confirmer s’il s’agit du comportement attendu, à savoir qu’il n’est pas possible d’utiliser un CDN S3 (configuré globalement) pour les téléversements sans que Discourse ne recherche également les ressources là-bas. Cela semble être un comportement inattendu, sauf si j’ai mal compris quelque chose.

15

Oui, c’est bien le comportement.

La configuration d’un CDN S3 l’utilisera pour tout ce qui correspond à un fichier statique, qu’il s’agisse de fichiers téléchargés ou d’actifs JS.

16

Voici quelques informations à ce sujet, j’ai dû gérer cela le mois dernier.

Je l’ai résolu en définissant les deux variables (DISCOURSE_S3_CDN_URL et DISCOURSE_CDN_URL) et en créant deux distributions CloudFront : l’une pour les téléchargements avec le bucket S3 comme origine, et l’autre pour les ressources avec le serveur comme origine.

Voici le code que nous utilisons pour cela :

Voici notre fichier app.yml (que nous avons nommé web.yml), nous remplaçons les variables au moment de la construction infra/modules/services/discourse/web.yml at master · debtcollective/infra · GitHub

17

Incroyable. Merci beaucoup. Il ne semble pas y avoir beaucoup de documentation à ce sujet, et les paramètres laissent entendre que l’on peut simplement utiliser S3 uniquement pour les téléchargements, ce qui, je pense, est ce qui nous trompe tous.

18

C’est sur ma liste de rédiger un howto à ce sujet. J’espère le faire d’ici la fin de semaine.

19

Oui, une fois que vous comprenez qu’il faut deux distributions CloudFront, cela prend plus de sens. N’oubliez pas non plus de télécharger les ressources sur S3 après chaque reconstruction. Il y a un problème avec les mises à niveau depuis Docker Manager où vous devez exécuter manuellement bundle exec rake s3:upload_assets à l’intérieur du conteneur Docker. Si vous effectuez une reconstruction à la place, cela devrait fonctionner si vous ajoutez ces lignes à votre fichier app.yml

hooks:
  after_assets_precompile:
    - exec:
        cd: $home
        cmd:
          - 'bundle exec rake s3:upload_assets'
20

Cette tâche signale que S3 n’est pas configuré. J’ai localisé le problème dans cette méthode de global_setting.rb :

def self.use_s3?
    (@use_s3 ||=
      begin
        s3_bucket &&
        s3_region && (
          s3_use_iam_profile || (s3_access_key_id && s3_secret_access_key)
        ) ? :true : :false
      end) == :true
  end

Où GlobalSetting.s3_bucket est-il censé être défini ? Il semble que nous devions définir les variables d’environnement DISCOURSE_S3_UPLOAD_BUCKET et DISCOURSE_S3_BUCKET. Quelle est la différence entre les deux ?