search

rgpages / election-2014-general

2014 general election coverage for Lane County, Oregon; developed and curated by The Register-Guard.
http://vote.registerguard.com
0 stars 2 forks source link

Backup plan #42

Open mhulse opened 9 years ago

mhulse commented 9 years ago

Meant to say: have this also hosted in an S3 bucket. Cname the project for easy pointing to diff host.

elec2014 as subdomain?

mhulse commented 9 years ago

Would be good to setup new subdomain today. Anyone opposed to the subdomain name of:

election.rg.com

Or 2014.rg.com

election14.rg.com

If we use election.rg.com we can reuse next time.

Thoughts?

robertdenton commented 9 years ago

Election.rg.com sounds good to me.

Rob Denton

On Fri, Oct 31, 2014 at 11:32 AM, Micky Hulse notifications@github.com wrote:

Would be good to setup new subdomain today. Anyone opposed to the subdomain name of: election.rg.com Or 2014.rg.com election14.rg.com If we use election.rg.com we can reuse next time.

Thoughts?

Reply to this email directly or view it on GitHub: https://github.com/rgpages/election-2014-general/issues/42#issuecomment-61307457

mhulse commented 9 years ago

After talking to j, We're going to go with vote.registerguard.com. J is going to ask Hamp and David to do this, copying the same setup as Zeppelin.rg.com

jheasly commented 9 years ago

Just for my own edification, how does having a CNAME pointing to GitHub result in being able to serve from an Amazon bucket?

robertdenton commented 9 years ago

I had the same question...

Rob Denton

On Fri, Oct 31, 2014 at 3:54 PM, John Heasly notifications@github.com wrote:

Just for my own edification, how does having a CNAME pointing to GitHub result in being able to serve from an Amazon bucket?

Reply to this email directly or view it on GitHub: https://github.com/rgpages/election-2014-general/issues/42#issuecomment-61341516

mhulse commented 9 years ago

Scenario:

GitHub network slow or throttles connection.

Solution:

We point vote.registerguard.com to a backup install of page that lives in an S3 bucket named:

vote.registerguard.com

The only drawback is the propagation time.

So, instead of us linking to pages.registerguard.com/election-2014-general, we point all links to vote.registerguard.com. If shit goes sideways, we move the subdomain "vote" instead of "pages", because "pages" hosts other things that we don't want to move. By CNAMEing just vote, then we can move just that content to any other location without having to worry abut breaking other things, and all of the links we put out there (like, via social media) will not break.

Hope that makes sense. :+1:

jheasly commented 9 years ago

Ah, yeah that does. So, to make sure I understand, if things go sideways we'd need to redirect the CNAME to the bucket. I take it that that is more or less instantaneous (as opposed to having to wait for the CNAME to propagate out to all the DNS servers out in Internet land)?

mhulse commented 9 years ago

FWIK, when creating a CNAME (or A-RECORD) for first time, that's usually pretty quick. If it's an existing name/record, then that could take time to re-propagate. It's not optimal because there will be a lag, but it's better than the alternatives. :)

mhulse commented 9 years ago

Just to clarify:

Q: Do CNAME records require time to propagate?

When I typically update DNS ("A" records) I will allow for an extended period of time for the changes to propagate throughout the root nameservers.

Do I need to make this same allowance for updates and changes to CNAME records?

A:

No you don't because DNS records don't propagate. What you do need to allow for is for any cached records to expire, based on the TTL of the record in question.

If this is a new record, no caching can have occurred so the new record should be available and should resolve immediately.

http://serverfault.com/a/415300

jheasly commented 9 years ago

Yeah, that makes sense to me, the difference between the A records and CNAMES, cause it seems to me as long as "registerguard.com" isn't moving around, resolving/re-resolving subdomains should be pretty quick.

It's nice to have the "detachment point"/subdomain ready to go ...

mhulse commented 9 years ago

Subdomain is setup.

Just need to figure out best way to auto-push to a bucket.

Alternative could be post-commit hook to a git-powered vhost on our servers.

jheasly commented 9 years ago

Question: Should we need it, will we need someone from IS to make the subdomain switch?

mhulse commented 9 years ago

Question: Should we need it, will we need someone from IS to make the subdomain switch?

Yes. Should be able to do that remotely though. Will confirm on Monday.

I'll setup alternative hosting location ahead of time. I'm thinking a folder on our static server would be the easiest.

jheasly commented 9 years ago

Suh-weetness, all around.

mhulse commented 9 years ago

Suh-weetness, all around.

Fo shizzle!

We're looking good at this point. I just have to finish #20 tomorrow and then Monday should be minor adjustments and #35 for cross-browser testing. Nice!

mhulse commented 9 years ago
mhulse commented 9 years ago

David setup testvote.registerguard.com; need to pull a backup there and do quick testing.

Should we just use our servers for this?