Comparison Of Configuration Management Tools

Introduction

The term “DevOps” is becoming increasingly ubiquitous in todays’s IT industry. It is not one single technology or standard per se, but rather a new way of thinking surrounding how we provision and allocate the numerous computing resources required from todays’s ever increasing and demanding applications.

The culture fostered by a DevOps focused mindset allows for the continuous delivery and integration of these applications that in turn creates a more streamlined and controllable approach across the development lifecycle, from initial testing to final deployment.

At the heart of this DevOps mindset is a series of tools that can be used to configure and automate the process and which makes it all possible in the first place. These tools all take the drudgery and repetition out of having to manage multiple servers or VM’s, which in turn helps speed up the process immeasurably while also cutting down on human error. They also allow for a more closer relationship between developers of the code and the operators of the machines they are run on. As noted Microsoft tech evangelist and programmer, Scott Hanselmann, says “The most powerful tool we have as developers is automation: I can’t stress this point enough. Humans are lousy at doing repetitive work, but computers excel at it. Look hard for the opportunity to automate processes down to a single button push. Even better, can you remove the button entirely?” [1]

For this report, a close examination of the top three most used configuration tools in the industry today which are Chef, Puppet and Ansible. The popularity of these tools was determined from running a Google Trends analysis [2] to gauge what are the top three most searched for tools in the configuration management sphere. As with most things, no one tool is superior and they are all have their own pro’s and con’s depending on the context they are being used in. Related tools such as Docker and Terraform were excluded, as while they can perform some configuration tasks, they are more suited to deployment and containerisation tasks.

Puppet

Puppet is the oldest of the three tools first launched in 2005, and has arguably the highest market share of them with big multinationals such as Dell and Oracle employing it to manage their servers. It has both open source and premium editions.

Puppet uses a traditional master/agent architecture, as in, there is one master server containing the configuration files, with multiple machine nodes with a agent daemon (background process) installed on them that periodically polls the server to see if there is any changes to the configuration files. If there is then that node pulls the configuration file from the server and updates itself. This periodic polling helps in alleviating any “configuration drift”that may set in over time as various nodes move away from their Desired State Configuration (DSC) and resets them to it. This is also an example of a pull mechanism at work, something which it shares in common with Chef.

Briefly on the topic of configuration drift, is were each node over time diverges in its initial configuration settings and becomes harder to manage and predict how it will operate as a result. [3] One of the primary goals of all the configuration tools discussed here is about keeping configuration drift to a minimum.

Puppet is written using the Ruby language and its configuration files are composed using Puppet DSL (Domain Specific Language). These files can then be grouped into what are called “manifests” to be implemented on nodes. The Puppet DSL is an example of a declarative language. The official Puppet blog succinctly states the advantages and disadvantages of using Puppet DSL to write your configuration files for Puppet “The trade-off in a DSL is that you can do more work in less code, and it’s generally far simpler and more approachable to the average user, but it’s also less powerful, which means there are some problems they can’t be used to solve. There are some classes of users who will never accept them as a result.” [4]

As Puppet is the most mature of the tools, it naturally follows that it has the biggest established user base, most clear documentation and also by general opinion the best web UI. It also has the best integration with third party reporting tools making it ideal for sysadmins.

As with Chef, the master server can be Linux or Windows based, while the nodes can potentially be running any underlying operating system. Also a secondary master server can be setup to ensure high availability in case of failure of the primary master.

Ansible

The newest of the three configuration tools, Ansible was first launched in 2012. Ansible is open-source and written using the Python language and requires Python libraries (which are generally found in most flavours of Linux) to be installed on the master server in order to function. Some notable organisations using Ansible include NASA and Intel.

Unlike the previous two tools, Ansible is “agent-less”, as in it does not have a traditional master/agent dichotomy. While there is a central master server, there are no agents running on the nodes. Instead the master Ansible server upon receiving any configuration changes (referred to as modules) proceeds to automatically connect to the nodes using the SSH (Secure Socket Shell) protocol, and then pushes those configuration changes out onto the nodes. From this we can defer that Ansible is an example of a push mechanism that does not require automated polling from the nodes, thus resulting in less overall network traffic which is one of the obvious benefits of Ansible over either Chef or Puppet.

Some other benefits of Ansible compared to the other two tools, are that since there are no agents running on the nodes, the setup time for Ansible is considerably shorter as no agents have to be installed and neither do they take up any valuable processing time on the nodes when they are running idle.

Unlike with Puppet and Chef, the master server must be Linux based, even though the nodes do not have to be. Also a secondary master server can be setup to ensure high availability in case of failure of the primary master. One possible disadvantage of Ansible that is highlighted here [5] is that configuration scripts written for one particular operating system of a node might be incompatible with a different operating system on another node. So if your environment includes both Linux and Windows machines you will probably have to write two different configuration files for both, which is an issue that does not seem to be present with Chef or Puppet.

Ansible uses YAML (Yet Another Markup Language) as the language used to write its configuration modules. YAML is very human readable and is generally considered easier to write configuration modules for than in Ruby (used in Chef) or Puppet DSL (used in Puppet), so therefore ease of use in configuration is also another plus for Ansible over those two. A series of configuration modules can be organised into what are called “playbooks” to be automatically run when required. Like Puppet DSL, YAML is a declarative language, rather than Chef’s Ruby language which is imperative (programming based) in nature.

Even though Ansible is the youngest of the three tools discussed here, it has achieved a high adoption rate and product maturity relatively quickly, even though there has been concerns about the lack of documentation. As its creator, Michael DeHaan noted on this topic “I think because of the way it was designed—being very modular with a tight core—it has been very mature throughout it's lifecycle, but what has really changed is the pace of contributions. Having hit almost 900 contributors by now, it changes the way you work a lot, but in a good way.” [6]

Chef

Chef is the second oldest of the three tools, first released in 2009. It probably has more in common with Puppet than that of Ansible, as like Puppet it also employs a master/agent design incorporating polling using a pull mechanism as was discussed in detail in the Puppet section of this report. Some large organisations using Chef include Facebook and IBM. It has both open source and premium editions.

One of the significant differences between Chef and Puppet however is that there is an extra component that resides beside the server known as a workstation. The workstation allows one to test configurations in an isolated environment before making them available to the main server and its nodes. This helps with safer and faster rollouts to upgrades and changes, even though can this can induce some additional processing overhead.

Similarly to Puppet, Chef is written in the Ruby language but unlike Puppet, Chef also uses Ruby to write its configuration files, which are imperative in construction. This makes it the hardest of the three tools to write configuration files for but also potentially gives it the greatest scope in power (precision of control) in terms of how you want to configure and provision your nodes. In general it appears that Chef was designed to be used with users who have high programming knowledge (especially if all ready familiar with Ruby) and not so much your typical sysadmin user. Further elaborating on this point in a quote from this article“To use an analogy, using Puppet is like writing configuration files whereas using Chef is like programming the control of your nodes. If you or your team have more experience with system administration, you may prefer Puppet. On the other hand, if most of you are developers, Chef might be a better fit.” [7]

The Ruby configuration files form the basis of what are known as “recipes” in the Chef lexicon. These recipes can then be integrated further into “cookbooks” for consumption by nodes. Each recipe defines resources used in a state such as what services should be operating, what packages need to be installed and what files need to be created. The resources can be modified to make sure programs are installed in a specific order based on dependencies. [8]

As with Puppet, the master server can be Linux or Windows based, while the nodes can potentially be running any underlying operating system. Also a secondary master server can be setup to ensure high availability in case of failure of the primary master.

Comparison

In the process of individually examining each of the three tools, this report has also been comparing and contrasting them. To offer a more visual representation of the similarities and differences between them here is a simple table to highlight it all that was created for the purposes of this report.

Conclusion

In final conclusion, as originally stated in the introduction it is impossible to say which of these three tools is the superior one, as it all depends on your individual context and needs. Saying that, here are the five most pertinent questions one should ask before choosing one of these tools to help guide you in your decision.

Consider the implications of choosing an agent vs agent-less architecture? Agent-less with its push mechanism seems to be the overall better and more modern choice here and Ansible therefore wins in this category.
Consider rather you want to write the configuration files in an imperative vs declarative style? Chef uses an imperative language and is therefore more powerful but also harder to use. The opposite is true of Ansible and Puppet which both use a declarative language.
If the end users of these tools are actually developers then Chef is better geared for them, whilst if they are more Sysadmins, then Ansible and Puppet will be easier for them to manage.
If documentation and reporting features are the most important to you then Puppet is the most advanced in these areas, with Ansible being the most lacking here.
If the nodes in your environment belong to different operating systems, then Ansible will require more work as its configuration files are OS dependent.

References

Hanselmann, S. (2018). Lessons from 29 DevOps Experts. [online] Studio B. Available at: http://www-new.studiob.com/index.php/scott-hanselman/ [Accessed 15 Oct. 2018].
Labs, F. (2014). What’s Trending with DevOps Tools: A Study Using Google. [online] Blog.flux7.com. Available at: https://blog.flux7.com/blogs/devops/whats-trending-with- devops-tools-a-study-using-google [Accessed 24 Oct. 2018].
Morris, K. (2012). Configuration Drift. [online] dzone.com. Available at: https:// dzone.com/articles/configuration-drift [Accessed 24 Oct. 2018].
Kanias, L. (2012). Why Puppet has its own configuration language. [online] Puppet. Available at: https://puppet.com/blog/why-puppet-has-its-own-configuration-language [Accessed 23 Oct. 2018].
Nigam, P. (2018). What are the disadvantages of Ansible?. [online] Quora. Available at: https://www.quora.com/What-are-the-disadvantages-of-Ansible [Accessed 24 Oct. 2018].
DeHaan, M. (2014). Behind the scenes with CTO Michael DeHaan of Ansible. [online] Opensource.com. Available at: https://opensource.com/business/14/10/interview- michael-dehaan-ansible [Accessed 23 Oct. 2018].
Yoga, A. (2017). Chef vs. Puppet: Methodologies, Concepts, and Support | Logz.io. [online] Logz.io. Available at: https://logz.io/blog/chef-vs-puppet/ [Accessed 24 Oct. 2018].
Habib, O. (2017). Deploying at Scale: Chef, Puppet, Ansible, Fabric and SaltStack. [online] Application Performance Monitoring Blog. Available at: https://blog.appdynamics.com/ engineering/deploying-at-scale-chef-puppet-ansible-fabric-and-saltstack/ [Accessed 24 Oct. 2018].