Unikernels

In honor of the transnational strike on Amazon this week, here are instructions for moving your AWS unikernels to a cloud that used to claim it wasn’t evil. You might also be interested in establishing a picket line for your packets.

This blog originally ran on Amazon EC2. Since early 2017, it’s been running on a different tech behemoth’s massive public cloud. The deployment process is considerably easier and faster on this alternative public cloud – I first saw it as a live demo given by Michael Bright and immediately knew I wanted to replace my AWS pipeline with it. My AWS unikernel deployments required a secondary Linux host for building AMIs from a kernel image and usually took around 20 minutes from start to finish; GCP deployments can be done from my development host and take around 90 seconds.

Julia Evans, prolific blogger and rad person, gave me several kind comments on the “Why I Unikernel” posts (security, self-hosting). She also asked, quite reasonably, whether I’d written a high-level summary of how I host my blog from a unikernel. “No, but I should,” I said, and unlike most times I say I should do something, I actually did it.

Here’s the very-high-level overview:

• use brain to generate content that some human, somewhere, might want to read (hardest step)
• write all that stuff in Markdown
• use Octopress to generate a static site from that Markdown
• use Mirage to build a unikernel with the blog content
• upload the unikernel to an EC2 instance running Linux
• build a new EC2 instance from the uploaded unikernel
• make sure that newly generated instance looks like my website with new content
• shut down the Linux host that made the new EC2 instance
• make somerandomidiot.com point to the new EC2 instance
• kill the EC2 instance which previously served somerandomidiot.com

And below, one can find the gory details.