Sam Jacoby

In which my adventures in migrating some small-websites over to Amazon’s vaunted services are discussed.

To those who have much, yet more.

Over the past few days, I’ve been playing around with Amazon Web Services (AWS). Now, I’ve been a spectacularly satisfied customer of A Small Orange for years, but I’ve been lately frustrated by the limitations of shared hosting. As I play around with different application platforms (Rails, Django, NodeJS), as part of my continuing professional-development-program, its clear that I need a bit more than 250MB of space and a restricted shell.¹

So, over this weekend, I migrated my sites over to play around with the twelve-months free access provided for AWS micro-instances, that is, tiny cheap servers. It’s been reasonably enlightening. I’ve built up a couple of Arch Linux images, my preferred distribution, and played with getting environments spinning up for some applications that haven’t seen the light of day in some time.

To Cloud. Or not to Cloud?

Some part of me—or well, most of me—dislikes the cloud. Yes, it’s convenient. Yes, Amazon, Rackspace, and all the rest do a damn-good job of things. Yes, it’s the future. Virtual machines are great, make sense, are cheap, effecient, and all the rest. In some way, though, it’s equal parts exciting and depressing—there is something lost and something gained, when you spin up an instance from yet-another dashboard.

I’ve always found something striking about that bit of magic that comes with connecting a run-down beige box to an ethernet port in the corner of a room, configuring its permissions, and having it flash its small payload across the waves. This cloud, for all the hoopla—is just better word off-site refrigerated storage with 24-hour access. Convenient, sure. But like gmail, you’re trading convenience for freedom. As much as AWS is convenient, it’s also inherently less-free. Amazon’s got your stuff.

Nevertheless, ever the modern man, I am a pragmatist—and even if I won’t remain with Amazon forever, I thought I should start figuring out how some their systems work. And what can I say? Right now, I have an insanely-fast, scalable, reliable, customizable server, with root access. I can’t really complain.

At the moment I’ve got two micro-instances running—one is serving the static pages, the other, a little typography training app I wrote a few years ago. That won’t last long, because you only get one instance free—but I’ll switch the nameservers back to A Small Orange soon, while continuing to serve the dynamic content from AWS.

Reverse Proxies

Now, I’ve long heard preached that fine practice—the prudent splitting of dynamic and static content. That makes plenty of sense, really. Or plenty of sense if I ever had much content to serve. In practice, though, It’s not something I’ve ever needed. As someone who has only ever placed things online from some reptilian instinct to share, I have never had any problems with server performance—to say the least. For some time, I ran my personal website from an X40.²

There are a million-and-one ingenious ways to do this and I don’t understand half of them. All I wanted was a nice, static server that put pages that I made on the internet, and two, have another server throw up some of the dynamic content. That way, I could have one clean server—where I actually knew what was going on—and pass off all of the messy stuff to other computers that had whatever intricate combination of python and everything else that was necessary.

Enter reverse proxies—which are exactly what they sound like. When you ask for something from a server, it scurries of to yet another server, and fetched it from there, passing it through itself and onward to you. So you never know that what you asked for came from some other place. And the proxying server doesn’t have to worry itself about whatever complex things you asked for, fobbing you off on some other machine (in my case, the correct AWS instance). Reverse proxies are what really pushed me to AWS, ultimately, as they’re not allowed in the shared hosting environment of AWS.³

At any rate, they’re dead simple. These are what mine look like.

ProxyPass /apps/monotype/ http://ec2-109-21-77-32.compute-1.amazonaws.com/monotype/

ProxyPassReverse /apps/monotype/ http://ec2-109-21-77-32.compute-1.amazonaws.com/monotype/

Exciting stuff, eh? Never done anything easier. Now, I’m not doing any of the fancy load-balancing or the various bells and whistles that real people probably do, but it’s been a pleasant introduction. The Apache docs give the rather stern warning: make sure you don’t inadvertently turn your server into a forward server, in which case it can be easily hijacked and redirected to all sorts of nefarious ends.

Serving Images from S3

Added 2015-08-06 10:25:09 I’ve used Flickr’s lovely embedded iframes to serve most of the images on this site, but lately, I’ve been frustrated with how slowly it loads. On some of the image heavy pages on my motorcycle project, it’s very noticeable. I don’t think the slideshow format works well for this site, anyhow, so I wanted to look into how to do my image hosting with s3⁴. I didn’t want to change my own development habits, though, so I turned to my .htaccess file, which my host, ASmallOrange, respects, even though I’m in a super-cheap shared VPS with very limited shell access.

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} \.jpg$ 
RewriteRule ^.*media\/img\/(.*)$ https://s3.amazonaws.com/Shackman/samjacoby.com/$1 [L]

That’s it! In the fabfile.py that I use to manage the deployment of this website, I also added the following:

local("aws s3 sync --delete --exclude '.DS_Store' --acl='public-read' --size-only deploy/media/img/ s3://Shackman/samjacoby.com/")

The aws utility is provided by Amazon—and while the sync function is not as clever as rsync, it works well enough for my purposes.