Nurse Euca is here to help you.

“I never see what has been done; I only see what remains to be done.  –Marie Curie”

Automated installers are great. When they work, they work really well — but when they don’t, not only do they not work, but they bring great sadness to the hopeful user who trusted your automated installer.  Tragic!  Heartbreaking.

So why don’t automated installers work, when they don’t work?  In almost every case, it’s because there’s a condition your installer assumes that isn’t met.  And in this day and age, you don’t have just one installer for your software, you’ve got multiple potential install+config tools: multiple package managers, multiple configuration tools, multiple permutations of hardware, multiple permutations of hypervisor, multiple permutations of network topology.  Which means that you’d better do a *great* job of figuring out your environment before you try to lay down and configure your bits.

Enter Nurse Euca.  Nurse Euca will run before any install and take everyone’s temperature, offer an aspirin or a splint where needed — or will let you know if one of your requirements is Dead On Arrival.  (“I’m sorry, Doctor, but em1 appears to be in septic shock. I recommend against resuscitation.”)  (That’s totally gonna be an error message, btw.)

Awesome, right?  Well, it will be when we write it.  We’ve got bits and pieces of these kinds of checks in various places.  On Friday we will be having a hackfest to pull these threads together and get Nurse Euca jumpstarted.

Hey, here’s a mostly-empty Github repo!  By the end of Friday, it won’t be.

We’ll be on freenode, #eucalyptus-devel, at 7am Eastern US time.  Yes, it’s early; we’ve got some friends in the Old World who will be hugely helpful, so we’ve chosen the time to accommodate them.  See you then.

Nurse Euca is here to help you.

Getting Eucalyptus Recipes Off the Ground

One of the projects I’m enjoying working on right now is the Eucalyptus Recipes project, which you can find on Github.  I actually hacked together some code, and even checked it in!  Needless to say, patches welcome.  And if “patches” means “complete replacement with better code,” that’s fine also.

The goal is to build a collection of recipes (small right now, but growing) that any Eucalyptus user can inject into the boot process of an instance at start time, using cloud-init or a similar mechanism.  Simple predefined Euca image + Euca recipe of your choice = fully configured software appliance.  Because all Eucalyptus users have access to a standardized set of pre-built images, we can be relatively sure that any recipe that builds atop a particular image will be guaranteed to build properly anywhere that image runs.

This is in contrast to an image-based approach, to which AWS users have become accustomed.  There are thousands of pre-built AMIs out there from which AWS users can pick and choose.  That’s good, because there are images for almost every imaginable need — but it’s also problematic in a lot of ways.  These AMIs are basically opaque.  You don’t know what’s in them, you don’t know who built them, you don’t know how they were built, and until you actually run one, you don’t know what they actually do.  The new improved AWS image catalogue will help this some, but it’s a problem inherent to the image model.

At Eucalyptus, we’re working on an images project as well, but I believe that the recipes approach holds more promise in the near term.  Here’s why:

1. Storage. Eucalyptus provides a mechanism for users to fetch a set of predefined Eucalyptus machine images (EMIs).  One day, we may provide a huge catalog of pre-built EMIs, but in the short term, we’re not really set up to host such a thing.  With the recipe approach, we can concentrate on providing a small set of minimal EMIs for the major distros, and we can test them thoroughly so that they make a strong base for building from.

2. Ease of customization. In a pre-baked image, the configuration is fixed.  If you want to change how the image works, it means hacking the image in place and rebundling it.  That’s a pain, especially for, say, changing the MySQL root password for your spiffy WordPress install.  Following the recipe approach, you just fork the recipe, replace passwords and other sensitive options in the forked recipe itself, and then build with the forked recipe.

3. Education!  Read the recipe, and you can see how the application is actually built and configured.  This is important to me personally; I distrust black boxes, and when I was a heavy AWS user, it was one of the things that made me nervous.  Four Kitchens made a great Drupal+Varnish AMI available, and it “just worked”, which was pretty sweet and saved me a bunch of time — but I lived in a low-grade fear that if something went wrong, I wouldn’t understand how it was configured.  My hope is that we end up with some very well-documented and interesting recipes that also teach people a little bit about how things work along the way.

4. Community development.  If an AMI or an EMI is broken, patching it basically means creating an entirely new image that has no evident relationship to the old one.  There’s really no clear concept of “upstream” with an image, and no simple way to collaboratively improve upon it.  Defining an appliance as a script in Github, on the other hand,  makes collaborative development and improvement of that appliance comparatively straightforward; it works just like any other open source project.

5. Integration with complementary tools.  I wrote my first recipe in bash, because when it comes to coding I’m a bit simple, really, and nothing to be done.  And it’s not as though this recipe notion is a new one; Puppet and Chef both have emerging forges with recipe collections of their own, and two of the first recipes we wrote were for Chef and Puppet bootstrappers.  I’m not quite sure how it will work, but it’s pretty clear that many of the recipes will be “hey, make sure Puppet is running, and then go get that Puppet recipe from over there and run it.”  One of the recipes I checked in recently sets up nginx based on the Puppet forge recipe.

6. Amazon compatibility.  There’s no reason in the world that these recipes shouldn’t work on AWS as well.  It’s my hope to add “tested with these AMI IDs” as part of every recipe’s documentation.

To be clear, there are also a couple of downsides to the recipe approach:

1. Time to instantiation. The image versus recipe dispute is age old, and one reason people have traditionally chosen to run from images is because they are “ready” so much more quickly.  Going from image to fully functioning instance in Eucalyptus takes seconds; going from image, to recipe, to fully functioning instance can take minutes.  When that difference matters, images are still the way to go — although I still think the right approach is to use a recipe to create an instance, and then to snapshot that instance and store it as the deployable image.

2. Proprietary applications. There will doubtless be organizations that will want to deliver proprietary software appliances to Eucalyptus users.  This mechanism may not be suitable for those providers, since it’s fairly incompatible with secret sauces.

As it turns out, recipe building is also a perfect use case for our Eucalyptus Community Cloud.  The ECC is intended to give potential Eucalyptus users a sense of how Eucalyptus works — but because the ECC is small and resource-constrained, we kill instances every six hours or so.  When writing recipes, though, iteration is the name of the game, so it’s perfect.  I wrote a Drupal 6 recipe over a weekend using the ECC.

Want to check out a recipe on the ECC?  Simple stuff:

* Install euca2ools on your local system.  It’s yum/apt-get installable from most repos at this point.
* Get your account on the ECC.
* Download and source your credentials for the ECC.  Be sure to set up your ssh keys as well.
* Get the recipes repo: git clone https://github.com/eucalyptus/recipes.git
* Get a list of images available by running euca-describe-images.  Pick the base image you want to start from.  The ID of the vanilla CentOS 6.2 image is emi-D482103E.
* Start your instance with the recipe, for instance: euca-run-instances -k yourkey emi-D482103E -t m1.large -f centos6_nginx.sh
* ssh into your instance and watch the show.  (For me, this was mostly tailing the yum log.)

So, it’s the beginning of a thing.  Like all beginnings of all things, its future is uncertain — but it feels useful to me, and I hope that we can build some value with it in the coming weeks and months.

Oh, also: see you at OSCON.

Getting Eucalyptus Recipes Off the Ground