Comments on: Amazon Ec2 Cookbook: Startup Flexibility

By: Ted Dunning

Ted Dunning — Thu, 29 Jan 2009 19:06:34 +0000

My own approach to late binding is simpler than any of these.

I write a tiny startup script that retrieves the user data for the instance and runs it as a shell script. This provides ultimate flexibility and gets me out of the AMI building business quickly.

Any fancy cluster binding can be built on top of this. Typically the user data has a small script that downloads the full scale configuration code and scripts which then do the late binding as necessary.

By: aboone.com » Blog Archive » Managing Multi-Node EC2 Deployments with SVN, Ant and bash

Tue, 18 Mar 2008 03:39:39 +0000

[...] easily be applied to a wide variety of deployments. The techniques described here were inspired by this blog post. This article is intended for people who are already somewhat familiar with Amazon Web Services [...]

By: apokalyptik

apokalyptik — Wed, 10 Jan 2007 20:11:14 +0000

Intriguing. The production that I’m planning on puttng this is is (at the moment) only slated to need one AMI, so mainly I was interested in being able to create, insert, and subsequently improve scripts for Unpacking the site, populating the database from backup, and installing regular backup jobs.

I’ll have to take a look at puppet. I expect that it’s something I could easily bootstrap in (now) without changing my AMI at all. And it sounds like it will be a godsend to know when the time comes around to use more than one ami!

I could also probably replace puppet later with something else using this simple loader mechanism.

By: Steve Loughran

Steve Loughran — Wed, 10 Jan 2007 09:23:50 +0000

I work on the SmartFrog configuration framework (Java based); our plan for EC2 is to bring up that daemon and use it for late binding configuration.

One of the best techniques we use for large clusters is not to have any preconfiguration in the host, but instead have it announce its presence to the cluster; the rest of the cluster decides what it will be. This lets you decouple ‘provisioning’ from configuring. Bring up 20 nodes; decide which will be app servers and which will be workers based on how many come up, and in what order.

The alternative to smartfrog that you may want to look at is ‘puppet’ – http://reductivelabs.com/projects/puppet/ – its a ruby based configuration languge, and again, you can bring up the daemon on startup for late configuration.