Off the back of my answer to the question: How can DevOps help to improve Software Escrow procedures? Tensibai had the question:

What would necessitate Capistrano on top of puppet or chef?

My response was to post a link to Noah Gibbs' article "Do We Need Both Capistrano and Chef?". Personally, I still subscribe to Noah's view that it is most appropriate to:

  • use a specialist deployment tool such as Capistrano for deployments.
  • use a specialist configuration management tool such as Chef for configuration management.

The fundamental approach that each type of tool uses to complete its task is very different:

  • Configuration Management Tools - are about creating and maintaining the desired state of a system, they are inherently idempotent in nature. Examples of configuration management tools are Chef, Puppet, Ansible, PowerShell DSC, Salt Stack.

  • Deployment Tools - are about delivering versions of software into a hosting environment, they provide functionality to maintain multiple versions of the software on multiple machines and manage which version is "current", they are inherently imperative in nature. Examples of deployment tools are Capistrano, Octopus Deploy, Deployer and Command.io.

I do believe that Configuration Management Tools can do the job of deployment tools and in the case of Immutable Infrastructure they are the most appropriate tool for the job as software versions on the target don't need to be maintained.

Question: Have configuration management tools such as Chef, Ansible and Puppet matured to the point that they are capable of fulfilling both the idempotent and imperative models?

  • Ansible always could, Puppet since 4.0 – Jiri Klouda Mar 28 '17 at 2:36
  • 1
    Richard, thank you for all the high quality questions that you have been submitting lately. I really appreciate the hard work you put into pre-populating the site during beta. Asking good leading questions is hard and you are really good at what you do. – Jiri Klouda Mar 28 '17 at 15:00
  • @JiriKlouda you are more than welcome, quite literally have a "DevOps SE" post-it™ on my computer to remind me to post the questions when they come to mind. – Richard Slater Mar 28 '17 at 17:18

In such context the typical advice should be immediately applicable: use the right tool for the job.

But then you also cannot ignore nowadays the almost virulent tendency of software tools to extend functionality into more or less related fields and actually become toolsets for various reasons: cool feature(s) to have, expand customer base, amass more revenue, etc.

For example many file management tools include image viewing features and many image processing tools include file management features. You can move files around and you can view images with either of the tools, often equally well.

Because of this it's quite possible to have entire portions of the software development process covered/overlapped by multiple tool(sets) even if their main feature/capability differs.

So it really boils down to the exact functionality you want to achieve in your particular process and how well one tool or the other does the job in your context. Subjectivity/preferences/convenience included.

Making this question primarily opinion-based ;)

  • I completely agree! More and more organization are developing "DevOps toolchain" specifically with this right tools for the job idea. For more info this wiki pages does a decent job talking about the different tools/jobs: en.wikipedia.org/wiki/DevOps_toolchain – Karl Harnagy Apr 4 '17 at 16:22
  • I'd just add that the more you extend a tool's use beyond its primary purpose, the more effort it will take to do so. You might be able to use certain tool for both deployment and configuration, but there's a good chance it will be more work (or require side-stepping best practices) than just using two tools. – jschmitter Feb 12 at 18:32

Configuration management tools are used to get a system into a known state. Deployment tools deploy new program files and program data to a system. At the end of the day, both types of tools do some combination of:

  • Determine the current state of the system.
  • Transfer files to the system.
  • Add or change persistent data (e.g. configuration files, database data, registry settings)
  • Start or restart programs.

Configuration management tools have declarative languages which specify the state of the system. Deployment tools have imperative languages which tell the system to do things. A DevOps person needs to do both.

Using the deployment tool Capistrano, it is clumsy to use its language to tell the system to ensure that the web server is active. You have to issue a command to restart the web server, and another to check to see if the web server is up. It is a kludge to get the web server into a known state.

Using the configuration management tool Ansible, it is clumsy to restart a web server. The language lets you tell the web server to be "up", but if you specifically want it to be restarted, you have to set its state to "restarted". But there is no easy way to check if the web server has been restarted. This is a kludge in Ansible to enable one-off operations.

Some folks prefer doing both types of jobs with one tool, and working around the rough edges. Other folks prefer having two tools to do almost the same thing, but without rough edges. To answer the question, "appropriateness" is a matter of taste. This answer explains why.

  • I agree on Capistrano being slightly awkward for this case. It is usually used as namespace for remotely executed ruby scripts/snippets/lambda over ssh. Your section on Ansible is not correct. You might want to research it a bit and fix it. Good first post, but please work on it a bit more. – Jiri Klouda Mar 27 '17 at 4:44
  • @JiriKlouda whats wrong with the Ansible section? Do you mean the section no easy way to check if the web server has been restarted in that it could be checked by registering a variable? – David Vasandani Apr 15 '17 at 17:31
  • There are multiple ways to do it, author of the answer just doesn't know them. Feel free to turn it into separate question as comments are not good place for technical answers. – Jiri Klouda Apr 15 '17 at 23:21

TL;DR: Just use Ansbile, it is both configuration and deployment tool :)

There are several types of deployment:

  • Application based (files, archives packages)

  • Container based (includes VMs, Habitat, LXC, Docker)

  • Function based (Micro services / Lambdas / Functions)

I assume in this case we speak only about application updates on server(s).

For deployment you need to have two things happen:

  1. Correct files or packages need to move to the server.
  2. Configuration and service states need to change.

Now for (1) you can use multiple strategies:

  • Artifact Repositories / Syncing
  • Package Repositories / Package Managers
  • Version Control System / Updating + Compiling (optionally)
  • File transfer protocols (scp, rsync, ftp)
  • Deployment Tools

For the (2) you can use:

  • Configuration management tools
  • Deployment Tools

So while the Deployment Tools are a way to do deployment all in one, they are not always the best strategy. Sometimes you want to use combination of these ways for deployment. You most likely already use package managers at least on your servers already. You most likely run configuration tools anyway. The problem with some of the configuration tools was a proper orchestration among multiple servers, but now even Chef and Puppet can do that quite well. Ansible has been always good at this.

From personal experience, I've used all combinations, but currently we use Capistrano for deployment and Ansible sync for configuration management, and VCS and package repositories for file transfers, but there are issues with Capistrano and we are planing to move away from it to unify on Ansible for both deployment, maintenance and configuration management.

  • 2
    My experience with Ansible and Capistrano would lead me to the same conclusion. I'd just go with Ansible. And the nice thing about Ansible is that its "desired state" declarations map very nicely to underlying imperative commands. – Jay Godse Mar 29 '17 at 14:12
  • 1
    People sometimes ignore the community contributions around Configuration Management tools. Ansible's community components are, with some noteable exceptions (like DebOps), are not yet as polished and feature-complete as Chef's and Puppet's. As a measurement of this, while I found Puppet and Chef are able to both "apply" and unapply configuration directives (do or undo a set of changes), Ansible is great at the "apply" part, but not so great at the "unapply" part. – Jesse Adelman Apr 20 '18 at 0:06

Application deployment is a hard thing to pin down because it has a lot of sub-problems. Config management systems are excellent at modeling tasks which are convergent and work with "what is the desired state of the system". In the context of app deployment, this is great for things like deploying bits to a machine, managing configuration files, and setting up system services. What it is extremely bad for is things that are inherently procedural, notably database migrations and service restarts. I usually try to put the convergent logic in Chef and let an external procedural tool (usually Fabric in my case) handle the few remaining bits as well as sequencing the actual converges.

So, basically, you should use both for the pieces they are best at.


For software and deploying code to an existing server or inside a Docker container, the answer is relatively simple - No, you don't need both, but you might want both if another tool or utility adds value and is the right tool for the job, however things get more complicated when you are deploying servers and operating systems.

One value-add of a DevOps mentality is treating infrastructure as code and frequently deploying or destroying virtual machines or even bare metal in a highly elasticized environment. Your configuration management system cannot easily netboot and kickstart your server for you and cannot manage repositories, packages and updates/patching for you during and after deployments or in some cases, licensing and entitlements.

For Amazon Web Services, this is rather conveniently manageable by APIs for the most part, but for those of us who have to manage our own data centers, this is not an option. For this reason The Foreman project (and Red Hat which re-brands this) have found it necessary to bundle Katello, Candlepin and a configuration manager such as Ansible, Foreman or Puppet together when deploying the Katello Scenario.

So while you might be able to get away with using configuration management tools for software code deployments on the Dev side of the house, over on the Ops side, there are several cases where the answer is a resounding "no, configuration management tools are not appropriate to use as deployment tools" Doing so would require a serious re-invention of the wheel and is impractical. You must instead use your configuration management tools to initiate deployments in another tool.

  • Or not, chef handle gracefully Capistrano like deploys, chocolatey packages deploys under windows and all well know packages installs (deb, rpm, msi, nullsoft, etc.). It does bring some burden on the packaging side, which habitat aim to solve, but that's a configuration management system fairly able to handle deploys, I can tell it by seeing it doing roughly 40 deploys per week on multiples environments including production, that's not without a high burden beforehand to code it, but that's not that much above the same thing with any other tool ateotd. – Tensibai May 22 '17 at 21:07
  • 1
    Actually The Foreman is neither a provisioning, deployment or configuration management system. It is just a skin which provides a web based UI and framework that glues together a configuration management system (puppet), license management system (candlepin), repository and patch management system (Katello), and a provisioning/deployment system (kickstart). It front-ends all of these different projects and glues them together. While pretty much any configuration management system can install a package, what they can't do is provide patch management in a manner similar to a WSUS server – James Shewey May 23 '17 at 2:25
  • or pin to or deploy specific versions of packages, include packages that are not in upstream repos or mashup repos. My point is that if Red Hat/The Foreman/Katello felt it couldn't be done with just a configuration management system - most notably because it lacked the provisioning/deployment piece that that is worth noting. – James Shewey May 23 '17 at 2:33
  • I misread the sentence about katello, my bad. First comment was for the sake of completeness :) – Tensibai May 23 '17 at 5:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.