configure CDN

[chadwhitacre]

I have an account at MaxCDN that I'm planning to use for this, if there are no objections.

[olivierlacan]

Sounds good to me.

[chadwhitacre]

Okay, looked into this. Neither MaxCDN nor Fastly support apex domains. We would have to use http://something.shields.io/ instead of http://shields.io/.

Also, I'm not sure what's going on with pricing for SSL. I'm seeing $39/mo at MaxCDN for custom SSL (right?), but over $100/mo at Fastly for even shared SSL. I don't feel like I have a good handle on what the real costs for SSL are going to be.

[chadwhitacre]

@olivierlacan Here are two options:

1. Use a CDN. Two suboptions:
   1. Serve the homepage from http://shields.io/, and PNGs from http://cdn.shields.io.
      Use http://shields.io/ as the origin server for PNGs.
   2. Serve both the homepage and PNGs from http://www.shields.io/.
      Use http://origin.shields.io/ as the origin server for both homepage and PNGs.
2. Don't use a CDN. We could serve the whole thing from http://shields.io/, and expect to be able to afford to upgrade to AWS by the time we need it.

[kookster]

I think you can have an apex domain using the amazon cloudfront cdn in
combo with their route 53 dns service.
It is not as cheap as the rates I have seen for maxcdn, but an option
perhaps?

Andrew Kuklewicz

On Fri, Sep 13, 2013 at 5:46 PM, Chad Whitacre notifications@github.comwrote:

@olivierlacan https://github.com/olivierlacan Here are two options:

1. Use a CDN. Two suboptions:
   1. Serve the homepage from http://shields.io/, and PNGs from
      http://cdn.shields.io.
      Use http://shields.io/ as the origin server for PNGs.
   2. Serve both the homepage and PNGs from http://www.shields.io/.
      Use http://origin.shields.io/ as the origin server for both
      homepage and PNGs.
      1. Don't use a CDN. We could serve the whole thing from
         http://shields.io/, and count on CDN's to add ALIAShttp://support.dnsimple.com/articles/alias-recordsupport for apex domains by the time we really need it.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/52#issuecomment-24426878
.

[chadwhitacre]

Good look, @kookster, thanks! :-)

Amazon CloudFront now supports Custom SSL Certificates and Zone Apex, two features that make it easier for you to accelerate and deliver your whole website using CloudFront.

http://aws.amazon.com/cloudfront/custom-ssl-domains/

[chadwhitacre]

Pricing for Custom SSL Certificates is simple. We charge a fixed monthly fee of $600 [...].

O.O

[chadwhitacre]

@olivierlacan I'm afraid $600/mo is not in the budget that I can see. What do you think is the best way forward here?

[chadwhitacre]

@olivierlacan I've modified option two above to suggest that we could launch now without a CDN, and expect to be able to pay for AWS by the time we really need it.

[chadwhitacre]

@olivierlacan Let me know how you'd like to proceed.

[kookster]

I'm pretty sure that is the cost for adding an ssl cert, and has nothing to
do with the apex domains except that they were 2 features announced on the
same day.

Andrew Kuklewicz

On Fri, Sep 13, 2013 at 10:28 PM, Chad Whitacre notifications@github.comwrote:

Pricing for Custom SSL Certificates is simple. We charge a fixed monthly
fee of $600 for each custom SSL certificate you associate with your
CloudFront distributions, pro-rated by the hour.

O.O

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/52#issuecomment-24435153
.

[kookster]

You can read more about it in this blogpost that shows the set-up - these
features are related by timing only, you do not have to spend $600/mo to
use cloudfront with an apex domain -

http://aws.typepad.com/aws/2013/06/custom-ssl-domain-names-root-domain-hosting-for-amazon-cloudfront.html

Andrew Kuklewicz

On Fri, Sep 13, 2013 at 10:47 PM, Andrew Kuklewicz <
andrew@beginsinwonder.com> wrote:

I'm pretty sure that is the cost for adding an ssl cert, and has nothing
to do with the apex domains except that they were 2 features announced on
the same day.

Andrew Kuklewicz

On Fri, Sep 13, 2013 at 10:28 PM, Chad Whitacre notifications@github.comwrote:

Pricing for Custom SSL Certificates is simple. We charge a fixed
monthly fee of $600 for each custom SSL certificate you associate with your
CloudFront distributions, pro-rated by the hour.

O.O

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/52#issuecomment-24435153
.

[chadwhitacre]

@kookster Sorry to not be clear: we need SSL. Since Shields PNGs will be used on SSL web pages, we need to make them available on both HTTP and HTTPS to avoid mixed-content issues. If I'm not mistaken, SSL is actually a stricter requirement for us than an apex domain.

[olivierlacan]

@whit537 It seems like a good idea to be thrifty if we can save $500 by using cdn.shields.io/... (although badges.shields.io seems like a better semantic option) instead of the apex, but it certainly hurts the whole clean URL aspect a little bit.

I'll defer to @nbibler (hoping he has time to chime in) since he's a lot more savvy when it comes to SSL than I am.

Launching without a CDN might be feasible though. I don't mind baby steps. :-)

[chadwhitacre]

@olivierlacan It sounds like your ideal would be to use http://shields.io/ for everything public-facing. Yes?

[olivierlacan]

Yessir.

On Sun, Sep 15, 2013 at 11:14 PM, Chad Whitacre notifications@github.com
wrote:

@olivierlacan It sounds like your ideal would be to use http://shields.io/ for everything public-facing. Yes?

Reply to this email directly or view it on GitHub:
#52 (comment)

[chadwhitacre]

Yessir.

In that case, I propose that we launch with our current Heroku setup, and move to Amazon when we're further down the road (more traffic, more money).

If this is agreeable, then here's what I think we want to do:

• @whit537 renames our Heroku app from origin-shields-io.herokuapp.com to shields-io.herokuapp.com.
• @olivierlacan drops the CNAME for origin.shields.io
• @olivierlacan adds a CNAME for shields.io to shields-io.herokuapp.com.

Sound good, @olivierlacan?

[chadwhitacre]

@olivierlacan Actually, it'll be a different CNAME due to SSL at Heroku. Let me know if you want to proceed with this plan and I'll get you the right CNAME.

[nbibler]

For the time being, I would suggest using Heroku's SSL Endpoint ($20/mo) and a decent SSL certificate (GeoTrust QuickSSL Premium, for example.. one time per year, ~$100) and just running everything directly from Heroku under badges.shields.io or secure.shields.io or something. That still gives you the flexibility of moving to a CDN in the future by just moving the CNAME to the CDN hosts and migrating the certificate in the future.

[olivierlacan]

@whit537 I'm good to go, let me know which CNAME I should point to.

[chadwhitacre]

Thanks for weighing in, @nbibler. We're verified with StartSSL, so we can get unlimited certs (they charge for verification, not for certs). I think we should still be alright to launch with http[s]://shields.io/ and migrate hosting in the future. We can add origin.shields.io as a CNAME at that time (we'll only need it on http since we don't need SSL between the edge and the origin since we're not transferring sensitive data, only using SSL to avoid mixed-content warnings on the pages we're embedded on). Once that new CNAME propagates we can configure hosting w/ SSL at Amazon (or wherever we land) and then switch DNS for shields.io to point there.

[nbibler]

Sounds fine. My only concern is that you want to use whatever domain now that you anticipate using in the future. Because it's trivial to update the DNS for a CNAME, its far more difficult to have all the services and providers update their URL references in the future. Dedicating a subdomain to the "API"-built images sounds like a good idea to me to do early.

[chadwhitacre]

@nbibler Good call. If we decide in the future that we need to separate our marketing pages from the PNG API, we could always move the marketing pages to a subdomain like www.shields.io or even introducing.shields.io or something.

@olivierlacan has the final decision on this one, IMO.

[chadwhitacre]

Is it more semantically natural to have ...

• http://shields.io/ <- marketing pages
• http://api.shields.io/ <- PNG API

Or what?

[chadwhitacre]

It might not just be marketing pages, too. I suppose in the future we'll want to have traffic reports, etc., eh @olivierlacan?

[nbibler]

I presume at some point you'll want to track and report which badges are being requested, at what request rate, at what file size, etc. It would be useful to know what services are using this and what kind of load they put on your system.

If this ever moved to a pay-per-use model, you'll need to track that anyway and probably want to have a concept of what a reasonable usage is.

[chadwhitacre]

@nbibler Yup, I'm with you. :-)

[chadwhitacre]

My thinking at this point is that we should keep the PNG API and the marketing/admin pages separate.

• http://shields.io/ <- marketing pages & admin app
• http://api.shields.io/ <- PNG API

api. seems to me to be fairly universal. I don't think it will feel odd to have that in the img src urls. Though if we wanted the admin app to be single-page we would presumably want to use api.shields.io for the json api for that, and we might prefer not to conflate that with the PNG API.

@olivierlacan Do you see value in splitting our URLs or do you still want to use http://shields.io/ for everything?

[nbibler]

👍 for @whit537. I would split them, they've got two different purposes and it allows you to do more interesting things on the api endpoint if/when necessary (rate limiting, caching, etc.) that do not affect the marketing pages.

[chadwhitacre]

If we wanted to save api.shields.io for the backend for shields.io, perhaps img.shields.io could make sense for the PNG API.

[nbibler]

You could act-as-if and just call it cdn.shields.io for now. ;)

[olivierlacan]

@nbibler I'm pretty anal about end-user semantics ;-)

Just for that I tend to prefer img.shields.io or badge.shields.io so that the URLs are self-evident (and created equal).

@whit537 I do like the idea of traffic reports down the line.

[chadwhitacre]

@olivierlacan Okay! So let's go with:

• http://shields.io/ <- marketing pages & (eventual) admin app
• http://img.shields.io/ <- PNGs

I'm going to proceed on that basis unless you indicate otherwise, @olivierlacan. Thanks for weighing in! :-)

[nbibler]

Any of them sound fine to me. I'm certainly a fan of not using the top-level for it... so whatever subdomain you guys decide on will give you the most flexibility, I think.

[chadwhitacre]

Yay for decisions! 💃

[chadwhitacre]

Okay! I've forked an img.shields.io repo, leaving this one as a static Heroku site for now using the PHP hack, with an index.html file as the homepage.

[chadwhitacre]

I've deployed both to Heroku, so we're ready for a DNS change, @olivierlacan!

• ALIAS/ANAME shields.io shields-io.herokuapp.com
• CNAME img.shields.io img-shields-io.herokuapp.com

[chadwhitacre]

I guess I need to configure SSL on img.shields.io. I've reticketed that as #66.

[olivierlacan]

[seanlinsley]

[seanlinsley]

Is the new server not running yet?

[seanlinsley]

Looks like this works: http://img-shields-io.herokuapp.com/gittip/activeadmin.png

[olivierlacan]

[seanlinsley]

? But img.shields.io still isn't working

[chadwhitacre]

@daxter Fixed, sorry. Needed to add the domain to the app in Heroku. I think we're live! 💃

http://shields.io/

[chadwhitacre]

@olivierlacan Let's drop origin.shields.io. We can add it again in the future if we need it.

[seanlinsley]

Yep, it's working for me. 🐼

[chadwhitacre]

Sweet! 🍡

[olivierlacan]

@whit537 Getting this on HTTPS:

Normal?

[chadwhitacre]

@olivierlacan Yeah, I haven't configured SSL yet. I reticketed that as #66.