Amazon EC2 support now in Rumprun

  • From: Antti Kantee <pooka@xxxxxx>
  • To: rumpkernel-users <rumpkernel-users@xxxxxxxxxxxxx>
  • Date: Wed, 19 Aug 2015 15:46:45 +0000


I added an "ec2" target to the rumprun utility. What it does, is it creates a file system layout (including the config json and block device images) that you can then transfer to an Amazon EC2 volume. A launchable machine image (AMI) can then be created from that volume, and launched. What the rumprun utility does not do, is in any way attempt to create or launch the image. So, like with the "iso" target, "rumprun ec2" doesn't actually run anything. That makes the features largely complementary to Andrew Stuart's EC2 script [1].

First compile and bake your application for xen_pv as normal. Then run rumprun as normal, of course with the exception of using "ec2" as the platform instead of "xen". The value of -N is used as the target directory (or rumprun-appname by default), and in there you'll find the file system layout you need to transfer to Amazon.

Next, it gets tricky (but see below under "how to improve" if you think it gets too tricky). Start any Linux instance on EC2. Tar up the directory created above and copy the tarball to the Linux instance. Then, essentially follow Andrew's script [1] from the comment "this will be the root file system for the unikernel". As a notable diversion, you need to format the file system as ext2, not ext4, or rumprun won't be able to mount it at runtime. You can also use web point-and-click interfaces to create/attach/detach the volume. After unmounting and detaching the volume, skip to "prepare the unikernel for booting on EC2" in the script. Finally, launch the AMI. You'll probably want to launch from the web console at least the first time so that you get security groups etc. correct. Note, if you're using the AWS "free" tier and launch from the command line, make sure to include -t t1.micro in the ec2-run-instances command. Apparently Amazon doesn't make it too hard to accidentally use non-free services (been there, done that).

So, in summary, to create the AMI you need:
+ ec2-create-volume
+ ec2-attach-volume
+ mke2fs
+ mount
+ tar
+ unmount
+ ec2-detach-volume
+ ec2-create-snapshot
+ ec2-register
(see [1] for a rough idea of parameters, especially for ec2-register)

After having played with EC2 more now, I'm not convinced that we can solve the ec2 side with a one-size-fits-all script, considering the amounts of varying options that the ec2* commands take. Though, if we get ec2ivol support working some day (see below), we might consider a "one script fits the default use case" approach.

How to improve support:
It would be better if the rumprun tool would create a disk image which you could transfer to Amazon with ec2ivol, and then you could proceed to do the snapshot-register-run dance without needing to launch a "preparation instance". That's actually what I tried first. After several hours of pvgrub dying in divide-by-zero, I decided to try following Andrew's instructions more literally. Since following Andrew's instructions worked, I gave up on ec2ivol, and not only because running ec2ivol a few times for a 10MB fs image seems to eat up all of the AWS "free" tier S3 quota. nb. the contents of the ec2ivol'd file system looked correct when examined from a "prep instance", so maybe something got confused when the file system wasn't the size of the entire partition?

A disk image also provides the advantage of being partitionable, and we could then include the data disk images (-b parameters to rumprun) as partitions instead of indirectly on the root file system like they're handled now.

EC2 doesn't seem to be particularly friendly towards unikernels. I got the impression that it's oriented towards the scenario where you run a fullblown OS and then do tweaking from inside that OS. Testing is painful since ec2 commands run for ages, so one iteration is easily several minutes. It's possible that I'm missing something with a whole ~10h of EC2 experience under my belt, but if their goal was to create a first impression of a convenient/agile/fast system, they failed. Furthermore, 1h being the minimum charge for launching an instance and 1GB being the granularity of provisioning storage is way overkill for unikernels. Seems like a good opportunity for a cloud provider to target and grab the unikernel market. (If such a provider already exists, drop a note, I'd like to partner with them for hosting on a Rumprun unikernel.)

Anyway, enjoy if you can and please send patches and bug reports if you're so inclined. Huge thanks go to Andrew for figuring out the EC2 side of things -- if it weren't for his efforts, I'd be sending this mail with quite a bit more of EC2 experience.

- antti


p.s. here's the "proof":
(I'll probably take that offline eventually, so don't be surprised if it doesn't work at an arbitrary future date)

Other related posts: