I currently use some shell scripts for deployment. This works well on my development server. It also works when starting to run things in a data center, but there are limitations and shortcomings. For one, my deployment scripts do not have any verification. I can add that, but then again I would be duplicating work that others have done well before. More important is the fact that my deployment scripts assume a prepared installation environment with all the packages and gems needed installed. I want a deployment system that also provisions the target server with all my prerequisites like Apache or nginx, Passenger Phusion, Sinatra and CouchDB. Note that our application does not use Rails, the storage is handled by CouchDB and non-UI work is handled by racks running directly in Phusion. The UI is handled by Sinatra.
We are looking at running our service in Amazon EC2 when we are ready to launch. As we use Fedora and Ubuntu for development, the obvious candidate distros are the same or related distros like CentOS, RHEL and Debian. If the deployment system handles package installation through an abstractions system, this system must support both yum and apt.
Chef is built around a chef server hosting the deployment scripts (cookbooks) and chef clients managing the worker nodes. It uses CouchDB in the background for storing information. From what I see, Chef is very powerful and looks like a nice way of handling huge clusters. The power also seems to have the side-effects that doing simple things in a smallish cluster is a lot of work. Uses Rake underneath
Capistrano uses it’s own DSL in combination with Ruby. Capistrano is Rails-centric, but have instructions showing how to use it for non-Rails deployment. The deployment instructions mostly run shell scripts which makes it very flexible.
Vlad the Deployer
Vlad seems to be an extension to Rake. Aims to be a better Capistrano. It seems very subversion oriented. One of the features is Turnkey deployment for mongrel+apache+svn. Since we’re not using mongrel or svn and although we use apache now might switch to nginx soon, this all seems wrong.
Puppet is an extremely flexible and powerful provisioning system. However, as is often the case, this comes at a cost. Doing simple things like our deployment is very time consuming in Puppet. It uses it’s proprietary DSL to specify very accurately how the target environment should be after running puppet. It is capable of running in the background and syncing automatically every 30 minutes or so. The feature set is overkill in our case right now and if we need those features later I’ll be a happy man who will gladly spend time moving to puppet.
Sprinkle uses Ruby directly instead of a task specific DSL. Full support of the main deployment systems is included. What puzzled me at first was that it supports Capistrano and Vlad the deployer for remote command delivery. Later I realized that Sprinkle is a provisioning system and leaves application deployment to other specialized systems. Nice separation.
One of requirements of Moonshine is A server running Ubuntu 8.10 which effectively disqualifies it for our use. I’m sure supporting other distros is not much work, but I’m not willing to do that work at this point anyway.
Might seem weird to include this in the list, but we use Passenger and anything that can get us there faster is considered. This would get us apache, passenger and lots of other things we do not use like MySQL. Since I do not want to install things we don’t need and passenger_stack only works on Ubuntu (and not even Debian), it is disqualified.
With Moonshine out due to lack of distro support and Vlad the Deployer out due to being mongrel+svn focused and puppet being too difficult, the following candidates are still contestants: Chef, Capistrano and Sprinkle.
Sprinkle has nice dry-run functionality allowing you to see what will happen to your remote servers before you do anything. Capistrano gets praise for easy of application deployment so the Sprinkle and Capistrano combo sounds interesting. My choice is now down to Sprinkle or Chef for the server provisioning and the winner is Sprinkle. The reason for my choice is that it is simpler and does what I currently need it to do. Migrating to Chef in the future is still an option.