We’re currently using Capistrano not only to deploy our Ruby on Rails application, but also to setup and manage our physical and virtual (Xen based) servers. We have Capistrano recipes for adding users, installing packages like apache or mysql, configuring a Xen VM and more. Coming accross puppet, I started to wonder about the essential difference between the two. Puppet claims to enable the user to automate server management to a large extent, a goal which we already reached by implementing our custom Capistrano recipes. So, what are the differences between the two?
First, I tried to understand the overall goal of both tools. Capistrano was built with deployment of rails applications in mind. Of course, it is very easy to extend it to manage your servers like we did, and recipe collections like deprec add exactly that functionality to it, but still, the basic problem Capistrano adresses is deployment.
Puppet on the other hand started as a lifecycle management tool from the beginning. It offers a lot of possibilities to define dependencies and desired states of services like apache should be running and needs this and that package additionally to those config files. Puppet then tries everything to reach that desired state automatically. This difference in the overall goal leads us to the different approaches both tools are using.
Capistrano uses an imperative approach where you describe in recipes how to do things. Looking at Capistrano recipes gives you a kind of “dynamic” view on your systems. You can see how a specific configuration evolves step by step. The recipes answer the questions “What do I want to do”?
Puppet uses a declarative approach where you describe a desired state for your system configuration. Your manifests answer the question: “How should it look like”? Puppet derives the steps to take from the static configuration and applies them as needed automatically.
Here is a short comparison matrix showing some features I found interesting. It is by far not complete, but I hope it might give you an overview:
|Configuration language||”Meta” language||Ruby|
|noop mode||yes||yes (since 2.5)|
|Ad-hoc server monitoring||no||yes|
|Mode of operation||deamon pulls config||user pushes changes|
|Dependency definition||Dependency trees with services, packages, and files||Single dependencies for dir, writability, command, gem and regex match|
Puppet acts on a different level than Capistrano dealing mostly with managing dependencies rather than scripting tasks. Puppet and Capistrano can play nicely together in a scenario where puppet is responsible for ensuring a certain system configuration and Capistrano is responsible for the more dynamic aspects like deploying new releases of your custom applications or ad-hoc server monitoring. But as my own experience and the success of deprec shows, Capistrano is a great help for configuring systems, too.