July 17, 2015

How did we get here...

Basic website deploy to AWS S3

Starting a new website.

My goal was to cut a bunch of corners in order to get a new site up and ready to build. I think many people would focus on the site and the content, but if we look at continuous delivery style thinking, we why the ability to push very small incremental changes to production. There are a lot of things one can think about and implement for a decent CD pipeline:

  1. Git repo
  2. Static site content
  3. Hosted environment
  4. DNS
  5. SSL
  6. Automated deploy to hosted environment
  7. CI tool to execute the deploy on commit (e.g. Jenkins)
  8. Versioning and tagging

So when I say cutting corners, I'm primarily referring to deferring steps 5-8 entirely and as for #2, rather than any specific static content, which I expect to be an Ember app, I only created a very simple index.html with a single image. I had to actively resist any temptations to add styling, links, etc. I kept a post-it on my monitor to help focus:

"Goal: get placeholder site up on AWS"

I wanted more control to be available to experiment with hosting and deployment options, so I opted for Amazon AWS for my one-stop solution. My hope is that over time I can figure out convenient automated tooling solutions and perhaps even have them "productized" in personal toolbox of capabilities.

AWS

These are some notes related to getting that simple static content up and live from Amazon S3.

  1. Create an S3 bucket
  2. Upload content to that bucket
  3. Test content via bucket URL
  4. Setup DNS via Route 53
  5. Test content via domain URL

I already had AWS account, but if you don't have one yet, you will need to do that.

I already has purchased my domain name through GoDaddy and so I had to jump through some hoops so that I could get the registrar switched to AWS. If you don't yet have your domain name purchased you may want to do that now. Otherwise if already have a domain, you should consider moving it to AWS for convenience (and get that started now), although I don't think this is technically required, just recommended. (And for the record, GoDaddy was very helpful getting me the information I needed to accomplish this.)

S3

For just the purpose of having a place to host some placeholder content, I simply used the AWS console. From the S3 dashboard, I created a new bucket. Now at first I created a bucket named similarly to my Git repo name, but it turned out that it's important to name the bucket the same as the domain you're creating it for. In my case, the site I'm building is http://4legssoftware.com, so my bucket name is 4legssoftware.com.

Since I decided to defer any sort of automated deploy for the moment, I simply uploaded my 2 files manually via the console.

Next, I set the static web hosting for the 4legssoftware.com bucket to serve the index.html file. But if you go test the bucket's "endpoint" via the browser, you'll see a permissions error. I had played around with perrmissions a bunch to get this working, but in the end all that was needed was to set the bucket's policy.

After setting the bucket policy, the bucket endpoint was successful in showing my content via the browser.

While we're here, since I want http://www.4legssoftware.com to redirect to http://4legssoftare.com, I needed to create another bucket, www.4legssoftware.com. This bucket stays empty, but simply has the static hosting properties set to redirect to the first bucket we created.

Route 53

I set up a hosted zone for 4legssoftware.com. This automatically setup NS and SOA record types .

Create an A record, e.g. 4legssoftware.com, with an alias to the matching S3 bucket.

Create a C record, e.g. www.4legssofware.com, with an alias to the 4legssoftware.com A record.

It can take as long as 30 minutes for the propagation of the DNS to really become settled, so it pays to walk away, get coffee, and stay patient before testing. But after a bit of time you can test out your new setup.

I experimented with several different combinations of record types. And I do believe as the article states, 2 A records (4legssoftware.com and www.4legssoftware.com) to alias their respective S3 buckets also works. I however opted for a C record to point the A record because it feels more logical to me. But I found it strange that the www.4legssoftware.com bucket was still required to have that route work.

Ultimately, all I have is 2 S3 buckets and 2 related DNS records. My biggest recommendations are: Be patient and really allow DNS to propagate before testing and fixing Maintain focus on the goal and just write down other possible next steps not required for that goal on the side Lastly, even though I don't have a comments section, I certainly welcome any feedback or questions. Just send them to me via Twitter or email.

"Just build websites" -- Shop Talk podcast


Stay tuned...

This can only get better ;-)

@robpark