Iruka Avantha

Configuration automation and management with Ansible, Puppet and Chef

In the past, all configuration changes to files within servers was a manual process; lengthy and time consuming for developers. This manual process is no longer necessary, because excellent configuration tools such as Ansible, Puppet and Chef now exist. These tools can facilitate complex automation at the click of a button, or with one simple command line.


When building computer programs, applications, and operating systems – configuration files (sitting within server configurations such as Tomcat or Apache) – are used to define the initial settings.

In the past, all configuration changes to files within servers was a manual process; lengthy and time consuming for developers. For example, a product environment could involve 10-20 servers, and when a product was updated, all servers required repetitive individual configuration changes. This manual process is no longer necessary, because excellent configuration tools such as Ansible, Puppet and Chef now exist. These tools can facilitate complex automation at the click of a button, or with one simple command line.

Automating particular Configurations as Code (CaC) can include:

  • Server configurations
  • Server file structure
  • Application configurations, etc.

Developers now have the ability to automate all configurations, as well as maintain version controls – just in case rollbacks to previous versions – are ever needed. CaC even enables seamless critical application patches with zero downtime and doesn’t affect live environments.

In the DevOps world, CaC has become a frequently used process due to the software industry being pushed to automate product configurations wherever possible. This is because the DevOps lifecycle is a collection of cogs that need to turn continuously, and if one cog breaks, it can stop all the cogs from turning. Automating CaC solves the problem by ensuring that the cogs work continuously without break. For example – with CaC, a simple file permission change in a server can now be applied to multiple environments simultaneously.

As organisations move towards a DevOps approach based on Continuous Delivery (CD), CaC is becoming even more important. CD enables a continuous stream of new incremental functionality for implementation – with DevOps streamlining the movement of these incrementally updated workloads – from development and testing environments to operations. Rapid updates and DevOps synchronisation just wasn’t possible when the Ops teams had to manually size and set-up production environments.

DevOps engineers should now be able to provision a well-defined and tested working environment using Configuration Management (CM) tools along with Continuous Integration (CI) and Continuous Delivery(CD) tools. Ansible, Puppet and Chef (as well as CFEngine, Juju, Rudder and Salt) are some of the important CM tools in use. However, these tools are expected to cater to various functionalities such as idempotency* (providing administrators with the ability to repeatedly carry out a set of actions to achieve the same result).


Ansible, Puppet and Chef – a closer look

There are numerous DevOps CM tools available. The remainder of this article highlights – in my opinion – the most important CM technologies: Ansible, Puppet and Chef. I’ve selected these tools depending on what they can provide and how these relate to business requirements.


Puppet is one of the oldest automation tools, and is very popular among the DevOps community. It is an open source tool that has been used in some of the world’s biggest and most demanding environments.

Puppet is based on Ruby, but uses Domain Scripting Language (DSL). It runs as a master-agent architecture, and has a pull-based CM system.
Agents manage nodes and requests from masters that control the configuration information. These agents pull status reports and queries regarding its associated node from the master puppet server.

Most importantly, Puppet runs on nearly every OS. It also has active community support through Puppet Labs. It has the most intuitive web UI to take care of many tasks, including reporting and real-time node management. There is also an enterprise version.

(Fig 1: Puppet Enterprise Interface)

However, there are a few drawbacks to Puppet as well. For example, it is not the best solution available to scale deployments.

Puppet also lacks a push system, so there is no immediate action on changes. The pull process follows a specific schedule for tasks.


Chef is also an open source tool that is used for CM. Based on Ruby, this is also a pull based CM tool. Normally Chef operates as a master-client model. For the majority of the cookbooks written, pure Ruby has been used.

The Chef server runs on the master machine and Chef client run as agents on each client machine. This setup is very stable, reliable and mature, especially for large scale deployments in both public and private environments.

Chef also works with any kind of OS. It has a rich collection of modules and configuration recipes. Being centered around Git, it also has strong version control capabilities. Chef provides strong documentation, support and contributions from an active community. Chef’s enterprise version has a rich interface that can manage nodes and environment configurations.

(Fig 2: Chef Manage Interface)


One of the drawbacks of Chef is that its initial setup is complicated. The lack of simplicity can lead to large code bases and complicated environments. Also, Chef doesn’t support push functionality.


Ansible is an open source tool, and uses a push model setup. The Ansible platform is written in Python and users can write playbook and script using YAML.
Ansible was developed to simplify complex orchestration and CM tasks. It can be setup in one server as the control server, without any agents running on the client machines. It uses SSH connection to login to the nodes that the developer wants to configure.

Client nodes only need Python. This is the only dependency needed in nodes because of the easy installation and initial setup. The lack of master eliminates failure points and performance issues. Agentless deployment and communication is faster than the master-agent model. It is most suitable for environments designed to scale rapidly, and there is an easy learning curve thanks to the use of YAML. The playbook structure is simple and clearly structured. Most importantly, Ansible supports both push and pull models. Ansible also has a enterprise version called Ansible Tower.

(Fig 3 : Ansible Tower Interface)

Since Ansible is the new platform among other CM tools, it is still in its infancy, and therefore is not as mature as the more established tools, such as Puppet and Chef.

(Table 1: Comparison between Puppet, Chef and Ansible CM tools)

As can be seen in the above table, Puppet and Chef are the old players in the DevOps, making them more suitable for larger enterprises. Ansible is a new player in the field and is a good option for fast and simple solutions. Either way, the application of Ansible in the DevOps world looks promising.

Each of these CM tools are aimed at different kinds of DevOps user. Important aspects to consider when choosing a tool for a CM solution include:

  • Determining unique requirements for workflows
  • Determining the most feasible solution for the organisation.
  • Other specific aspects to consider include:
  • Architecture
  • The operation model
  • Key technical and business aspects.

Bringing a CaC tool to the product improves its quality and stability, and moves it closer towards the newest technologies and its accompanied features.

Thank you for reading this Tech Guide. We hope you will also read our next tutorial so that we can help you solve some more interesting problems.

*Idempotency: if we multiply a value by zero then the value will be zero. No matter how many times you multiply it the value is still zero. In other words, idempotency means it can be run again to produce the same result.


Iruka Avantha

Associate Software Engineer | Mitra Innovation