Prod is not using a CDN

[ianb]

I did a new perf test (while looking at #3202) and notice that the static resources are not coming off our CDN.

Looking through the code, it seems to be based pretty directly on $CDN in the environment. If that is empty, then there won't be any prefix, and it will load the resources locally. @relud says that we're setting $SITE_CDN and $CONTENT_CDN, which sounds right – there should be two CDN paths. We'll need to look up the changes to figure out what happened here.

[chenba]

It looks like the cdn config was using $CDN since the beginning:

screenshots/server/src/config.js

Line 278 in 52e255a

cdn: {

[ghost]

@relud says the CDN already exists, we just need to use it.

screenshotscdn.firefox.com
screenshotscdn.firefoxusercontent.com

Is this issue saying to unset SITE_CDN and CONTENT_CDN and just set CDN? or ...?

[relud]

I think it's the other way around, the config needs to convert CDN to add two separate options, SITE_CDN and CONTENT_CDN, but in order to do that we need to identify where CDN is being used, and make sure things are moved to using the site or content cdn as appropriate.

[ianb]

To clarify, we need to change our code to use SITE_CDN and CONTENT_CDN

[chenba]

Where should CONTENT_CDN be used?

[jaredhirsch]

We have the separate firefoxusercontent.com domain for stuff users upload, so that'd be the origin server for the CONTENT_CDN. If you look at commit 52e255a, you can see how the existing CDN code fits together. Does this help?

[chenba]

The images are served from screenshots.firefoxusercontent.com on prod. We would achieve the same effect by setting CDN=https://screenshotscdn.firefox.com and CONTENT_ORIGIN=screenshotscdn.firefoxusercontent.com correct? (I'm not opposed to the change; just trying to understand this better.)

As for the webpagetest.org test results, we won't get that check mark for using a CDN because the moz cdn is not on this list: https://github.com/WPO-Foundation/webpagetest/blob/master/agent/wpthook/cdn.h

[jaredhirsch]

I think the origin server would be screenshots.firefoxusercontent.com, and the cdn would be screenshotscdn.ffuc.com. Ditto for SITE_CDN.

[relud]

so these are the settings now:

CONTENT_CDN=https://screenshotscdn.firefoxusercontent.com
CONTENT_ORIGIN=https://screenshots.firefoxusercontent.com
SITE_CDN=https://screenshotscdn.firefox.com
SITE_ORIGIN=https://screenshots.firefox.com

but I think @chenba is right, if we just set CONTENT_ORIGIN to CONTENT_CDN then we would reference all content via the content cdn, which is what we want, as long as we aren't storing the value of CONTENT_ORIGIN in the database location for shots.

[chenba]

Sorry to be the bearer of bad news, @relud, but the image URLs are written into the db. That has at least two effects.

Since the shots expire by default, the number of images not using the content CDN will drop over time.

The CSP header is dynamically built, so once we do a post-patch server release with CONTENT_CDN, we cannot roll back. If we roll back or change the CONTENT_CDN, the images saved with the original CONTENT_CDN will be blocked by CSP.

[relud]

I know we do, but we should stop. I have nginx rewriting legacy content origins to the current one, to avoid bugs like you describe