[MirageOS-devel] Fwd: Amazon EC2 support now in Rumprun

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

From the Rump lists -- it looks increasingly complex to boot a unikernel in EC2 
when using non-S3 storage.

-anil

> Begin forwarded message:
> 
> From: Antti Kantee <pooka@xxxxxx>
> Subject: Amazon EC2 support now in Rumprun
> Date: 19 August 2015 08:46:45 GMT-7
> To: rumpkernel-users <rumpkernel-users@xxxxxxxxxxxxx>
> Cc: Andrew Stuart <andrew.stuart@xxxxxxxxxxxxxxxxxx>
> Reply-To: pooka@xxxxxx
> 
> 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)
> 


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel