I just started using EC2 BeanStalk. It's been surprisingly painful...the system makes sense, but some of the config details are obscure...(using Rails 3.2 and mysql)
Server ops isn't my thing...and while I've set up EC2 machines before for specific apps and services, I'm trying to build a workflow for deploying as flexibly as I could with Heroku. I looked at Rubber for a brief moment and it felt like too much...so I gave Beanstalk a try.
Beanstalk has components that I can figure out on my own and the command line tools are easy enough...I'm currently stuck on figuring out when the hell it decides to set the DB user and password, despite what I've explicitly set it...so I know what's going wrong, but the whole settings part is much more annoying than it was on Heroku (even without trying to do anything too complicated). But EC2 has the full suite of services I need so I'll stick with it for now. I expect that once I'm comfortable with BeanStalk, it won't be hard to just migrate to old fashioned EC2 and capistrano.
BeanStalk's support for Rails is relatively recent so the lack of questions on StackOverflow is probably why I'm struggling
I use capistrano for deployment, I mainly like it because I can set up a VPS on any service and have it clone the repo from git, config is almost identical between applications depending on the complexities of each and it can be heavily modified for the clients needs as well.
If I'm just showing off work to clients and pushing things to a staging/dev server, a lot of the time I'll use grunt-rsync or grunt-sftp to push everything up at the end of my `$ grunt produce` task. For site deployments, I prefer Capistrano since it's dead simple.
SaltStack (http://saltstack.com/community.html) and Ansible (http://ansible.cc) would be your two closest options. Of the two, I prefer Ansible for its simplicity and the fact that it can be extended in any language, but it's worth noting that that simplicity currently comes at a cost of power compared to Chef. (E.g., Chef has a concept of "ensure this service is present," and that works on all supported operating systems, whereas Ansible has different modules for different supervisors.)
That's quite nice, but your weakness is that a single-point of failure can delay your deployment, without you noticing it early enough. Or do you have solution for that?
We stage all changes on a 'develop' branch and run the same exact build process(thanks to bamboo) and deploy to the staging server.
If QA passes, then we just merge the changes to master, push and deploy to production servers.
Bamboo has a nice variety of test suites you can run too.
I really like that git(via bitbucket) and bamboo notify hipchat of any build failures/updates so we can respond immediately if something serious actually goes wrong.
64 comments
[ 3.0 ms ] story [ 138 ms ] threadShouldn't Heroku be on this?
Beanstalk has components that I can figure out on my own and the command line tools are easy enough...I'm currently stuck on figuring out when the hell it decides to set the DB user and password, despite what I've explicitly set it...so I know what's going wrong, but the whole settings part is much more annoying than it was on Heroku (even without trying to do anything too complicated). But EC2 has the full suite of services I need so I'll stick with it for now. I expect that once I'm comfortable with BeanStalk, it won't be hard to just migrate to old fashioned EC2 and capistrano.
BeanStalk's support for Rails is relatively recent so the lack of questions on StackOverflow is probably why I'm struggling
http://saltstack.com/community.html
http://www.ansibleworks.com/
http://fabfile.org/
Couldn't give it a try yet, but seems rather interesting
Definitely worth a look
We're working on a deployment manager based on Substack's fleet.
https://github.com/substack/fleet https://github.com/PinionTech/rear-admiral
2. Apache ANT for the build script
3. Then back out to a production/tarball git repo
4. Every load balanced server image has a cron job to poll the production git for changes
This way all I( or my team members) have to do is push to git.
Everything else is automated. All servers load balancing will keep themselves up to date.
If QA passes, then we just merge the changes to master, push and deploy to production servers.
Bamboo has a nice variety of test suites you can run too.
I really like that git(via bitbucket) and bamboo notify hipchat of any build failures/updates so we can respond immediately if something serious actually goes wrong.
Chef - because it's so easy to write cookbooks
Caterer - because the push model is clean, and it has a similar workflow to Vagrant.