It looks like we have similar goals, but my (planned) implementation is a bit different...
I'm assuming there will, at some point, be a mechanism by which the cluster will automatically scale up and down -- as in, without admin interaction. If I understand your implementation, it wouldn't quite work that way -- you have static config files somewhere, right? It's also a simple project for me to learn Rails (or maybe Merb) -- the mapping of instances to roles will be managed by a Rails app, running on an instance. That's why I wanted an actually dynamic role, expressed as a block. In pseudocode: role :db do http_get "http://#{ec2-describe-instances.pick_a_random_instance }/config/roles/db" end These would be lazy and cached, like "set" variables. And I abuse those similarly. It means the entire process is transparent to the developer. In fact, I have something like this working right now -- only one instance, but it's not hardcoded anywhere. We just do a "cap deploy" and it grabs the first instance on that account. (It will also spawn an instance if there are none, but this has been buggy -- in particular, ec2-describe-instances tells me that an instance is alive before sshd is running, and Capistrano doesn't like 'connection refused'.) Only reason I haven't sent in a patch for the role-blocks thing is it needs a bit of cleanup (not much), and I've been drowning in a torrential flood of Rails books, tutorials, blogs, and general advice :( Should be in this weekend, though. Bonus: The same mechanism can also be used to handle DNS. PowerDNS allows me to write a DNS server in any language that can deal with tab-delimited IO on stdin/stdout, and it does support AXFR, which means I can use something like dyndns in slave mode to do the heavy lifting. Most of this hasn't been written yet, though, and I didn't look at rubber very closely before I started. If you see any obvious place to collaborate, I'm all for it. Generating config files from erb is probably a good idea. (Automatically installing packages/gems isn't as crucial, as I have all I need on a custom image already, and a Rake script to keep it updated.) On 1/31/08, matt <[EMAIL PROTECTED]> wrote: > > > Hi David, > > You might be interested in a project I'm working on do do deploys to > ec2 using capistrano. Specifically, I give every instance an alias > (and one or more roles) within the framework, and store this mapping > in a yml file so that I can auto generate the right roles for > capistrano (nice and DRY :). It makes it a lot nicer to work with ec2 > if you can deal with names of your own choosing rather than the > instance-ids. > > All the instances also get configured on a role basis (install > packages/gems, generate config files from erb templates), so it > doesn't matter how many instances you have, i.e. if you have a single > instance that belongs to all roles, that instance will be configured > for all roles, and if you then reorganize and split up your roles > amongst multiple instances, you shouldn't need to do much work because > those new instances would only be configured for the roles they belong > to. > > The README for the project is at: > http://rubber.rubyforge.org/svn/trunk/README > It should be trivial to demo it using the steps outlined therein - if > not, then I broke something, so please let me know :) > > Matt > > > > > On Jan 11, 3:29 pm, David Masover <[EMAIL PROTECTED]> > wrote: > > Working on a way to use Capistrano to deploy to ec2. I know about > > Capsize, but decided that I didn't want to hardcode image and instance > > IDs anywhere -- particularly as Capistrano itself will eventually be > > creating those itself. > > > > > --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
