Are configuration management tools appropriate to use as deployment tools?

Question

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?

Answer 1

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 ;)

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.