By Greg DeKoenigsberg | July 13, 2012
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.