AWS Redirects To Medium
Ok, this blog post is a little meta. It’s a post about the history of Greenhouse’s blog — and some technical things too.
Blogging: The Initiation
In late 2015, a few engineers on the Greenhouse engineering team pointed out that we’d been working on some interesting technical problems, but no one outside of our offices knew about them. Enter the Greenhouse engineering team’s first blog posts — a Jekyll-powered, static site. These posts were added to an AWS bucket and hosted at tech.greenhouse.io. Each blog post was ultimately just an markdown file stored as an AWS object.
The writing of these blog posts continued for about a year. But after our team went through a substantial growth spurt, blogging fell by the wayside in favor of building more features, tackling technical-debt, and building out better processes for the growing team.
Last summer, as I took over as organizer for the Full Stack Engineering Meetup group and helped kick off our engineering team’s external branding initiative, I started to encourage more engineers to resume writing blog posts. This time though, I saw value in hosting them on our own Medium publication — In The Weeds. I saw both the Meetup group and a Medium publication as great mediums (no pun intended) to showcase the talent we have and technical problems we’re tackling here at Greenhouse.
A future post will cover the steps I took to reestablish a successful blogging culture. But for the context of this post, all you have to know is that a year later, we’re going strong and averaging a post every other week!
Deploying the Blog
For discoverability, design, and minimal maintenance purposes, we decided to start posting everything on In The Weeds. It made the process more straightforward and allowed our employees to begin building their own personal brands alongside Greenhouse’s. But we still had thirteen posts at the old tech.greenhouse.io — hence my looking into redirecting requests from that AWS bucket to Medium.
Old Blog Implementation
Our old Jekyll-powered blog was set up to be hosted as an AWS bucket behind CloudFront. Authors would write their posts as markdown files and commit them to a GitHub repo. When someone would write a new post, they’d create a pull request against
master and submit their new markdown file for “code” review. For each push up to GitHub, Solano (our CI service) would build the blog using Jekyll — and if successful would then run a deploy script. That script would check to see if the current branch was
master , and if so, would write things to the AWS bucket. Once written to the bucket, all the markdown files in the
_posts directory would be publicly visible on tech.greenhouse.io. Here’s a portion of the script.
With a number of our blog posts reaching reads in the tens of thousands, and significant SEO rankings we’d like to maintain, we couldn’t just copy/paste the blog post content and re-post to Medium. Well, we could — and we did, but there was more to it in order to maintain high ranking in search results.
We wanted all requests to the tech.greenhouse.io posts to redirect to their corresponding copies on Medium. In order to do so, we had to call the
put-object command on each post. Working off of Amazon’s PUT Object documentation, I added the below code to the deploy script.
Of course, things never work the first time. In order to test this, I
curl'd the above blog post, only to receive a 200 response. I was really hoping for a 301 redirect. Here’s the response…
AWS Bucket Website Hosting
Interestingly, you can see the redirect header Amazon documented I should see —
x-amz-website-redirect-location is being set to the Medium URL I’d expect. But the request just wasn’t redirecting.
Rereading Amazon’s documentation for configuring a webpage redirect, I notice a clue in, well, the first sentence. “If your Amazon S3 bucket is configured for website hosting, you can redirect requests for an object to another object in the same bucket or to an external URL.” I should have probably confirmed that the bucket was configured for website hosting, because it wasn’t! With a little help from the Infra team, we got this rectified.
Of course, things never work the second time. When
curl’ing, I was still seeing the same results. With a little more Googling, I came across another Medium post and some CloudFront documentation which provided the final solution. We needed to update our CloudFront settings for this bucket to use the proper origin. Once properly set, a
curl finally produced the 301 we wanted!