Folks,
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].
Use:
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.
Impressions:
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
rumpkernel.org 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
[1]
https://www.freelists.org/post/rumpkernel-users/EC2-launch-script-feedback-valued
p.s. here's the "proof":
http://52.2.126.166/
(I'll probably take that offline eventually, so don't be surprised if it
doesn't work at an arbitrary future date)
