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

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?

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

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.)

I’m trying this again. I’ve got uploads going to s3. That works.

I configured cloudflare to CDN the site. If I enter https://lc-XXX.literatehosting.com/uploads in the s3_cdn_url site setting, new uploads go to the S3 bucket and the image is linked to the CDN url and it works.

BUT if I try to set the s3_cdn_url with an ENV in app.yml (or edit config/discourse.conf by hand and sv restart unicorn, all of the assets are loaded from S3 (where they aren’t). That might be OK, but if I try to rake s3:upload_assets, it complains that S3 isn’t configured.

I happened across this while figuring out some clashing settings names.

I think (and hope, because it means I understand this and didn’t write absolute nonsense in the thread linked above) that if you remove these two lines:

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

Then you can set DISCOURSE_S3_CDN_URL, and it will only be used for uploads, not assets.

I think that you do understand, and, thanks to you, I’m at least closer to understanding myself! Thanks very much!

Running into this and still very confused after reading this thread…

I’m trying to server s3 uploads (not compiled assets) from CDN (Cloudfront).

If I configure “s3 cdn url” via the settings screen, it works as expected (well…except for System upload not using s3 cdn url)

However, if I configure via DISCOURSE_S3_CDN_URL and rebuild, the frontend is broken because its trying to load compiled assets from my s3 cdn url.

Seems DISCOURSE_S3_CDN_URL / s3_cdn_url should only affect uploads, and DISCOURSE_CDN_URL should only affect assets.

That is my experience too. I ended up making a plugin to set the S3_CDN_URL.

@pfaffman seems like this should be filed as a bug then, yes?

Perhaps. It’s not a feature likely to be used by normal self hosters,so it’s going to be a low priority. Also, I think that there is soon to be a change in how global settings and shadowed by global work, so it’ll likely get worked out then.

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 ?

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

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.

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.

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.

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

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.

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

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'

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

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 ?