On 1/31/08, matt <[EMAIL PROTECTED]> wrote: > > > > 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'.) > > Yes, I ran into that too - I took the easy way out for now and > injected a sleep :)
I'd rather poll. I already do that with -describe-instances anyway. The main reason for this, though, is the case where we're deploying from a development machine, and not part of the hypothetical automated-scaling process. A development machine will be behind a NAT, at least, and I don't want to force people to implement port forwarding! And yes, I do think there will be a "master" instance, but I like that Capistrano would pull from the monitoring/managing app, and not the other way around. Also, it won't only be a master -- it'd be a waste of an instance not to put other things on it. > (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.) > > Right now I use rubber as that script to keep instances updated - I > figured most people wouldn't have that capability up front. One can > always point rubber to an AMI of your choosing and skip the install > parts once your platform is stabilized, but having it dynamic up front > helps during the initial build out. Fair enough. I really should've scripted that initial build out more, as it's going to bite me whenever I get around to doing a 64-bit image. We actually have two AWS accounts. The test account is more dynamic; that is, all packages and gems are updated directly on a running instance or three, manually. Process would be, once a week, or however often we need to, we build an image, test it, then re-bundle and deploy on the production account. Capistrano would still be responsible for some configuration and app installation, but the idea is, when we bring that production instance up, the entire system is "frozen" for another week in a known-good state. Neither apt nor gem is ever run on a production instance. --~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
