Ansible vs Puppet: Which is right for you?

As DevOps engineers, systems administrators, and developers, we often need to work on consistent, repeatable servers. For DevOps engineers and administrators, especially, who might be managing thousands of servers, the need to make changes and provision multiple servers at once with consistent configurations is paramount -- and often the reliability of our infrastructure depends on it.

An answer to this problem comes in the form of a myriad of configuration management platforms, which let us define our desired configurations tasks or end states, then use those definitions to make consistent changes on any servers upon which they are run. Two of these platforms are Ansible and Puppet.

Ansible is a configuration management, cloud provisioning, and application deployment tool written in Python and maintained by Red Hat. For configuration management, users write YAML-based task lists called "playbooks," which describe the steps taken to configure a related portion of the server.

Ansible requires no additional package downloads on our configured servers, only that Ansible needs to be installed on its control node -- the primary source of truth for our Ansible playbooks and modules.

To manage our swathes of infrastructure, we'll create inventory files, which are simple lists containing the DNS or IP information of our desired servers, and Ansible uses SSH to access these servers and make changes when our playbooks are run.

Ansible is extensible, and users can also write their own modules, which provide functionalities that can then be used in playbooks. While Python is Ansible's native language, these modules can be written in any language that supports JSON, for ease of use.

Ansible is open source, although an enterprise offering, Ansible Tower, which adds dashboard, role-based access control (RBAC), job scheduling, integrated notifications, and graphical inventory management.

Puppet is an automation and configuration management platform written in C++, Clojure, and Ruby, maintained by Puppet, Inc. Configuration management is done in a declarative manner, in which users describe the desired end state via the Ruby-based PuppetDSL.

Puppet is idempotent, and manifests can be written to be cross-platform. These end-state descriptions are them mapped to approved servers running the `pupept-agent` service.

Unlike Ansible, Puppet uses a client-sever architecture, and you will need to install the Puppet agent on any servers managed by Puppet. The client server will then have to be accepted on the Puppet Server, our primary server for managing Puppet (and servers under Puppet enforcement).

Using Puppet but don’t want to have to write your own modules?

Try out hands-on labs for using the Puppet Forge, an online repository hosted by PuppetLabs that stores public modules to use in Puppet infrastructure. 

Puppet is also extensible, although you'll be working in Ruby to do so.

Puppet has an open source offering, but Puppet Enterprise adds extensive dashboards, RBAC, cloud provisioning, and compliance.

Which solution is best for you (if any!) ultimately depends on your goals.

Ansible is quick to setup, and playbooks are written in a familiar user-friendly language, YAML. This means users can generally pick it up quicker than Puppet, which uses a Ruby-adjacent language with its PuppetDSL. Due to its client-server architecture, Puppet is also slower to setup, and time needs to be taken to approve any managed nodes (or automate the approval of nodes).

But speed and ease-of-use are not the only facets we should consider when choosing a configuration management platform. Puppet's manifests have one edge that Ansible's playbooks do not: While Ansible's playbooks are essentially a list of commands that _must_ be run in order, Puppet's manifests and modules are reusable segments that can run in _any_ order, and used modularly.

Puppet also runs a `puppet apply` every fifteen minutes (or whatever you set it to), ensuring your servers are under enforcement throughout the day. This aids in Puppet's ability to work as not just a compliance auditing tool, but a compliance automation one, as well.

Puppet also has the benefit of maturity: Puppet is seven years older than Ansible. However, Ansible has the backing of Red Hat, whereas Puppet is owned by its own private company -- something I have found to be a mixed blessing, as a Puppet user.

Ansible has long had a clear goal and precise implementation: it's not hard to jump back into Ansible after a time away. However, there are times when it feels like being a Puppet user is standing on shifting ground. I began using Puppet with Puppet 3 and stopped around Puppet 4. Coming back to Puppet 6, having not used Puppet 5,  felt like relearning Puppet from the ground up, an experience I wasn't expecting and haven't had with other configuration management platforms.

A look at the difference in the amount of resource types between Puppet 5.5 and Puppet 6.22 is evidence of this — Puppet 5.5 has 48, whereas Puppet 6.22 and later has 12. This doesn't mean that these changes are bad, necessarily — but Puppet has had many substantial changes in its lifetime that one may potentially take into account.

It's impossible to state which platform is better — you can only determine which platform is better for your needs. Beyond considering the differences talked about above, be sure to take time to get hands-on with both platform before making any decisions. You may also want to consider other options, such as Chef, Salt, or even Terraform, based on your needs.

Ultimately, both platforms are highly scalable, offer automation and cloud provisioning functionalities, and provide extensive enterprise offerings and support. Ansible has a lower barrier of entry, whereas Puppet's DSL might take more time upfront to learn in exchange for a powerful declarative language. Both are strong candidates when getting your configuration management up and running.

Elle Krout was a technical writer at various companies where technical writers do more than write before transitioning to DevOps and working as a technical trainer. She has written and released over eleven courses on DevOps, including Puppet, Salt, YAML, and her personal favorite, a regular expressions deep dive.