We've come to the point where we need to set up autoscaling for our web server and I'm unsure how to go about the process of scaling servers and updating the the existing code without remaking a new AMI and changing the autoscale config to use it.
I've read a bit about people bundling the new code and uploading it to s3 and having new servers grab the bundle on boot up but that doesn't seem all that pleasant either.
Currently the web app's files live in a git repo, and when we update the code, we push it to github, ssh into the web app and run a hook to bring down the latest code.
So I was thinking that another option could be to just run that hook on an hourly or daily cron task. Unfortunately that doesn't cover everything type of update (for example new blog posts' images and such which aren't included in the git repo) but it's something.
Could anyone provide some advice on what a common solution is or anything as to why my proposed solution is a bad idea?
Thanks all
Best Answer
I'm a fan of creating new AMI's for major releases and system changes, but for minor releases I like to also have boxes configured to do a
git pullon startup to update just the codebase. We release small code changes regularly, so the burden of creating new AMI's is just not worth it.After the machine is up-and-running, I think it's best to use tools like capistrano to do push-style deployments. I don't like to see new code auto-launch to a server with cron jobs, since it's much more difficult to handle exceptions. Inevitably someone will push code into the repo they need to revert, and in the meantime cronjobs could trigger and launch the errant code.
The main issue is that when a new instance is brought up in an auto-scaling context, it can update itself with the latest codebase unattended.