Closed Bug 805888 Opened 12 years ago Closed 12 years ago

Use our SSL-aware CDN

Categories

(support.mozilla.org :: General, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED FIXED
2012Q4

People

(Reporter: jsocol, Assigned: rrosario)

Details

(Whiteboard: u=user c=general p=1 s=2012.23)

We have an SSL-aware CDN so we should be serving much more static content from it. It's a reverse proxy so all we *should* have to do is switch the media- and static-URLs.
The origin for this is support-origin.cdn.mozilla.net. You should already be able to reach /media/, /admin-media/, and /static/ at that location.

Here's an overview of what needs done to put this into use:

1) Test that the contents of support-origin looks correct and usable.

The new CDN points to the *prod* data, but we could put support-origin into MEDIA_URL and STATIC_URL for staging temporarily, assuming the assets are "close enough". If that looks good but we still want to be extra-cautious, we can do #2 below and put the actual CDN name into stage (support.cdn.mozilla.net) and check again.

I don't expect any problems though, and it probably won't take too much time to check this.

One thing to look for is any content that's going out with a long Cache-Control max-age or Expires time, that does not have a suitable ?build= query string. This is something that may not pose a problem *now* (since Zeus doesn't strictly obey them- it has an upper limit of ~10min), but might be on a CDN (which *does* strictly obey them, and some of your ExpiresByType config lines are up to a week).
 

2) Update DNS away from the current non-SSL CDN to the SSL-aware one. This is all WebOps. This should happen after some examination of #1, so we don't inadvertently break GALLERY_VIDEOS_URL, which is already on CDN. Alternatively we can pull that off CDN first.


3) Update MEDIA_URL on prod. New setting would be:
MEDIA_URL = 'https://support.cdn.mozilla.net/media/'


4) Optional: update STATIC_URL on prod. Seems to be not much here.

5) Optional: update GALLERY_VIDEOS_URL on prod, to chain off of MEDIA_URL.
Whiteboard: u=user c=general p= s=2012.22
Priority: -- → P3
Whiteboard: u=user c=general p= s=2012.22 → u=user c=general p= s=2012.23
Looks like the only thing SUMOdev needs to do here is step 1, then the rest is up to IT after we give the thumbs up. Correct?
Correct... we just need a confirmation that we're good to make the change.
Whiteboard: u=user c=general p= s=2012.23 → u=user c=general p=1 s=2012.23
Target Milestone: --- → 2012Q4
(In reply to Jake Maul [:jakem] from comment #1)
> 3) Update MEDIA_URL on prod. New setting would be:
> MEDIA_URL = 'https://support.cdn.mozilla.net/media/'

I get a cert error. "...You attempted to reach support.cdn.mozilla.net, but instead you actually reached a server identifying itself as edgecastcdn.net..."

Also, would we use https even when users are on http? Or can we set the MEDIA_URL to '//support.cdn.mozilla.net/media/' instead?
Assignee: nobody → rrosario
(In reply to Ricky Rosario [:rrosario, :r1cky] from comment #4)
> (In reply to Jake Maul [:jakem] from comment #1)
> > 3) Update MEDIA_URL on prod. New setting would be:
> > MEDIA_URL = 'https://support.cdn.mozilla.net/media/'
> 
> I get a cert error. "...You attempted to reach support.cdn.mozilla.net, but
> instead you actually reached a server identifying itself as
> edgecastcdn.net..."

Yep, part of step #2 is to change DNS to point to the new name, which is Akamai instead of Edgecast. The only reason that isn't done already is that I want to make sure we don't break GALLERY_VIDEOS_URL, which currently uses it. That's why step #1 is to test that support-origin.cdn.mozilla.net serves up those files properly. :)

If you want to test the new CDN property with an /etc/hosts file change, you could do this:

23.14.20.61 support.cdn.mozilla.net


> Also, would we use https even when users are on http? Or can we set the
> MEDIA_URL to '//support.cdn.mozilla.net/media/' instead?

Hmm... well, from a CDN perspective we don't much care either way. Devs might have something to say about if that will actually work as expected, but the new CDN will respond to both.
OK, I tested this quite a bit and it looks good! There only seems to be an issue when setting STATIC_URL, but we currently only use that for the admin assets so we can skip that for now. I suspect it will be resolved by upgrading to django 1.4.

These are the settings I think we want in prod's settings_local.py:
MEDIA_URL = '//support.cdn.mozilla.net/media/'
GALLERY_VIDEO_URL = MEDIA_URL + 'uploads/gallery/videos/'

# Leave commented out for now. Uncomment when upgrading to django 1.4.
# STATIC_URL = '//support.cdn.mozilla.net/static/'


Do I need to file IT bugs for step 2 and 3 or can we work off this bug?

Thanks!
Don't worry about it, I'll take care of it right here. :)

DNS change committed. Seems to be working for me with curl to Akamai, and I see bandwidth on Akamai now as well.

I want to let it sit this way for a little while (an hour or two), so that we can see how things shape up one the new CDN before cutting over MEDIA_URL as well.
(In reply to Jake Maul [:jakem] from comment #7)
> I want to let it sit this way for a little while (an hour or two), so that
> we can see how things shape up one the new CDN before cutting over MEDIA_URL
> as well.

I am ready for a faster SUMO whenever you are. Let me know and I'll verify things.
:jakem set the MEDIA_URL in prod and things are working great. Thanks!
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.