Puppet and Ansible are both open source configuration management tools, each having its own strengths and weaknesses. This article will point the reader in the right direction when it comes to choosing one over the other.
Puppet is basically a tool that helps you to manage and automate the configuration of servers. It is one of the biggest names in the configuration management market. Developed around 2005 by an Oregon based software development company in Ruby, it is open source and runs on all major OSs like Linux, Windows, UNIX, macOS, etc.
Puppet allows us to define the state of our IT infrastructure, and then automatically enforces the correct state. It does not matter whether we are managing a few servers or thousands of physical or virtual machines, as it automates tasks that systems administrators do manually, thereby freeing up the time for them to work on the projects that deliver greater business value. Companies like Oracle and Google run their data servers with Puppet.
Ansible is an open source IT engine that automates application operation, cloud provisioning, intra service orchestration and other IT tools. It was introduced in 2012 by AnsibleWorks, now owned by Red Hat.
As Ansible is developed in Python, it is lightweight and has fast deployment. It can also be run from CLI commands without using configuration files such as reboot, whether the server is running or not. For relatively complex tasks, its configuration is handled by the YAML syntax in a configuration file called a playbook. Ansible commands can be written in any programming language and be sent in the JSON format. It has also recently started supporting Windows.
Features common to both Puppet and Ansible
Before discussing the differences, we will consider the features common to Puppet and Ansible. Both are designed to automate the work involved in taking a physical or virtual machine from a generic configuration to a point where it serves the given tasks. These tasks may include installing packages, managing services, creating and updating configuration files and running commands. Both have the idea of idempotency, which is important for automation. It means that when any automation script runs correctly, it should always leave the system in a consistent state, no matter how many times it runs and no matter what else has changed in that system. If partially run, and then run again, it should run correctly to completion just as if it were run from the beginning.
Puppet or Ansible tools are written to be resource models of the desired state. this is preferable to writing regular shell scripts which is very difficult.
Both support a rich template language for configuration files. Puppet’s template is based on Embedded Ruby, while the Ansible template is based on Jinja2. Both have support for variables, whether fed in from a common set of files or set dynamically. To understand better, let us see a snippet of sample code of both – a simple example of putting a Hadoop configuration file into place.
The code snippet for Puppet is:
file { '/opt/hadoop/etc/hadoop/hdfs-site.xml':
content => template('hadoop/hdfs-site.xml'),
owner => 'hadoop',
group => 'hadoop',
mode => '0644',
}
And the snippet for Ansible is:
name: hdfs config file template: dest: /opt/hadoop/etc/hadoop/hdfs-site.xml src: hdfs-site.xml owner: hadoop group: hadoop mode: 0644
Given below are examples on how files would look before being templated out using variables.
In Puppet:
<configuration> <property> <name>fs.defaultFS</name> <value>hdfs://<%= @hdfs_host %>:<%= @hdfs_port %></value> </property> </configuration>
In Ansible:
<configuration>
<property>
<name>fs.defaultFS</name>
<value>hdfs://{{ hdfs_host }}:{{ hdfs_port }}</value>
</property>
</configuration>
As you can see, both look quite similar.
Differences between Puppet and Ansible
Setup difference: Puppet is easy to install. It is model-driven and built for systems administrators. It runs on two different modes — agent mode and apply mode (also called ‘masterless’). It is based on the client-server architecture, and can be installed on multiple servers together.
Ansible has a master and no agent is running on the client machines, which means it can run from one location and connect to the machines it manages over the network, through the SSH protocol. It is quite simple, agentless and uses YAML language.
Management and scheduling: This can also be called the push and pull configuration. In Puppet, the configuration gets pulled by the client from the respective server. Every 30 minutes, it checks the status of the nodes that are performed by the Puppet agent.
However, in Ansible, the server pushes the configuration to the nodes for better and faster deployment of codes. Its free vision does not have a good option for scheduling. Ansible enterprise version gives some improved options but these are not better than Puppet.
GUI: GUI of Puppet is more user friendly than that of Ansible. Puppet GUI can be used for viewing, managing and monitoring complex tasks. It also supports CLI (Command Line Interface) mode, which is developed in Ruby.
Ansible was only introduced as a CLI tool, but now in the enterprise edition it has a UI mode. However, it is not as flawless as CLI, as it has a sync issue with the command line.
Support: As Puppet is much older than Ansible, it is obvious that it has more support and a much bigger community for Puppet. There are also numerous debug scenarios available on the Web that can help the developer to handle the failure or error.
Ansible offers two levels of professional support for its enterprise version. It also has its own set of more than 200 meetups around the world – a bigger assembly of users and sponsors annually called AnsibleFest. Overall, it has a smaller developer and user community than Puppet, and has fewer support and troubleshooting resources on the Web.
There are some more differences like the languages used by them, scalability, error or failure handling, availability, etc.
Some unique features of Puppet and Ansible
Let’s see an example to demonstrate the uniqueness in the design of Puppet. Suppose there is a resource somewhere that specifies ‘https’ service should be started and enabled, and that there is also another resource elsewhere which specifies the same thing. In the above case, the given machine cannot apply both the resources. An error will be generated by Puppet, when it tries to compile the catalogue into the machine. This feature is not available in Ansible.
Ansible does not need an agent to be installed on client machines. Instead, it uses common access mechanisms and language to perform tasks. Ansible expects its roles and modules to be applied when required and potentially selected for a specific run, so it is more relaxed about duplication. It also runs its tasks mostly in order – top to bottom – so even if you have the unwanted situation of changing the same resource multiple times, the behaviour is still generally expected.
Which to choose?
Ansible and Puppet are both superb tools, each in its own way for different reasons. The choice comes down to the business requirements or needs. If you are looking for a tool to maintain a mostly stable set of machines, then choose Puppet. If you are looking for a tool to configure a set of machines that are frequently revised and reprovisioned on demand, then opt for Ansible.
Also, for people who are using Transient for development and testing, support for both tools is great. But in my opinion, Ansible has a slightly easier learning curve because of its relaxed rules. Puppet can be used if we are planning to use it in production.
The bottomline is that either of the tools is better than manually entering the commands and shell scripts.
