configure CDN about shields HOT 49 CLOSED

Sounds good to me.

from shields.

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.

from shields.

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

from shields.

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 [email protected]:

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

from shields.

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/

from shields.

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

O.O

from shields.

@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?

from shields.

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

from shields.

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

from shields.

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 [email protected]:

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
.

from shields.

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 <
[email protected]> 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 [email protected]:

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
.

from shields.

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

from shields.

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

from shields.

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

from shields.

Yessir.

On Sun, Sep 15, 2013 at 11:14 PM, Chad Whitacre [email protected]
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)

from shields.

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?

from shields.

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

from shields.

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.

from shields.

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

from shields.

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.

from shields.

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.

from shields.

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

from shields.

Is it more semantically natural to have ...

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

Or what?

from shields.

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

from shields.

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.

from shields.

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

from shields.

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?

from shields.

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

from shields.

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.

from shields.

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

from shields.

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

from shields.

@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! :-)

from shields.

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.

from shields.

Yay for decisions! 💃

from shields.

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.

from shields.

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

from shields.

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

from shields.

from shields.

from shields.

Is the new server not running yet?

from shields.

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

from shields.

from shields.

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

from shields.

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

http://shields.io/

from shields.

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

from shields.

Yep, it's working for me. 🐼

from shields.

Sweet! 🍡

from shields.

@whit537 Getting this on HTTPS:

Normal?

from shields.

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

from shields.