Compare Configuration Management Tools - Ansible, Chef and Puppet
Compare Ansible, Chef and Puppet on a Like to Like basis.
In this article, let’s attempt to perform a Like to like comparison between the most popular configuration management systems — viz. Chef, Puppet, and Ansible.
The idea is not to identify the best among the three, as each tool has its own ups and downs, but to provide an overview of the three to enable an easier decision on choosing a tool for your organization’s usage.
Do feel free to ask us for more information at - info@bridgeapps.co.uk
If you would want to understand the details about what configuration management is and the concepts in general — read them in one of our previous blogs here.
The above Table attempts to perform a like-to-like comparison, and we will try to elucidate the same in words below.
Scripting Language / DSL (Domain Specific Language)
Each of these tools has their own mechanism around Configuration and architecture. Configuration languages or DSL are different for each of these CM tools, and some tools will demand a higher learning curve to be mastered so should be considered as a parameter for consideration for selection w.r.t the resources in the team.
CM Tools prefer scripting languages like Ruby and Python in general, so any experience with these would help.
Puppet - Uses Puppet DSL - which is a Custom scripting language, based on Ruby, if you are aware of Ruby, this is fairly clearer and the hop is not far
Chef - Uses Ruby
Ansible - Uses Python + YAML
Architecture
CM Tooling architecture is different in each of the cases. The general architecture is Master - Agent architecture, where one of the nodes are assigned as the master server, which holds and orchestrates all of the jobs, while the agents are installed in each of the target nodes, which simply execute the jobs and respond back with the status back to the master.
CHEF.io - Master - Agent Architecture.
Puppet - Master - Agent Architecture.
Ansible - Master Only Architecture (No agent).
Installation & Setup
Based on CM Tooling architecture, the installation and setup could be complicated or not. Having an agent helps esp if the agent-master communication is through encrypted and custom protocols. Ansible is the only odd one of the lot, which achieves the same through a much simpler SSH.
CHEF.io - Many articles emphasize the complexity of building and maintaining the Chef Workstation, though personally, we believe its a matter of perspective
Puppet - Communication between the two needs to be established as a Certificate Signing process, which again can be achieved once the capability is set up.
Ansible - This is probably the easiest, and all commands executed with target Nodes are via SSH.
Do note that While Unix / Linux systems come with SSH enabled by default, for Windows 10 / Windows Server 2018 (updated) / Windows Server 2019 - onwards OpenSSH is embedded within Windows (might need activation though)
Communication & Control
The stability of Master nodes and their mechanism to communicate with the agents are key to the success of this automation. Let’s consider the different methods by which each of these CM tools communicates with respective nodes.
CHEF.io - Configurations conceptualized and maintained on Check Workstations are pushed on to Chef Servers, which then gets pushed to respective Chef nodes (agents), where they are executed.
Chef Architecture Puppet - Master / Node communication is via SSL, and hence Certificate Signing process is to be established between these nodes. Puppet master holds the configuration repository, which is then synchronized with the Agents.
Post execution, agents respond back with the facts to the puppet master
Ansible - This is probably the easiest of the architectures, and all commands executed with target Nodes are via SSH. Ansible master nodes takes the Playbook and the CMDB (list of all assets as the inputs) - which is not much different from other tools and pushes the configurations to the nodes.
Infrastructure Requirements
(More granular comparison in the table above)
Agents - Installation and Management
Every time a new Node is to be created, the installation and configuration of Agents on these nodes becomes an additional task. In a world with constantly upgrading software instances, upgrading of management of the agent software itself requires some amount of effort, though this is not very complicated and can be automated in most instances.
CHEF.io - Agents are to be installed in node under management
Puppet - Agents are to be installed in node under management
Ansible - No Agents are needed for Ansible and runs on a Server only mode. All commands are executed over SSH on the target node. This can be considered as an advantage for Ansible, earning some brownie points on comparison
Dedicated Infra
Iod idea to allocate some amount of dedicated infra for each of these tools, as other than easiness to name/manage and upgrade these servers in isolation, cost and team access (Access security) management becomes easier as well. Having said that, technically, it is not mandatory for some tools to have a dedicated infrastructure.
CHEF.io - Yes for the Chef Server
Puppet - Yes for the Puppet Master
Ansible - Not needed. Any node can be used as an Ansible controller/master
OS Support
All the CM tools have a common support matrix here. The master/controller nodes are designed to be installed on a Unix or Linux environment and can manage Nodes of any Operating system (Unix/ Linux /Windows)
Backup Servers / Availability
Availability for each of the CM tools is considered quite high and shouldn’t be a cause of concern. In the event of server failure of the master node, each of them has the option of a backup server / a secondary master which will continue to support the ongoing jobs.
CHEF.io - Option of Backup Server
Puppet - Option for an Alternative Master
Ansible - Option of Secondary Instance
In Summary, there are some fundamental differences between how each of these CM tools work/ operate to achieve exactly the same thing. I have never heard of any organization migrating from one tool to another, as each of these provide same / similar capabilities and the case is not too strong to justify the cost. Hence, it becomes even more important to emphasise onc choosing the right tool which fits your organization / culture / skillset within the orgaization / culture.
Do feel free to kick off a conversation around these tools by sending us an email - info@bridgeapps.co.uk
Author: Dilish Kuruppath / BridgeApps Ltd, London, UK
We at BridgeApps UK offer Infrastructure Management to our Customers, covering almost all aspects of DevOps & Cloud /OnPremise Infrastructure. Do feel free to enquire more at - info@bridgeapps.co.uk