When comparing Puppet vs Ansible, the Slant community recommends Ansible for most people. In the question“What are the best configuration management tools?” Ansible is ranked 2nd while Puppet is ranked 4th. The most important reason people chose Ansible is:
Ansible does not use agents. Instead, all master-agent communications are handled via SSH commands or through the Paramiko module which provides a Python interface to SSH.
Specs
Ranked in these QuestionsQuestion Ranking
Pros
Pro Declarative sematic
You define the state the server should be in and Puppet transforms it that state. This is opposed to explicitly declaring a list of actions to be performed.
If a developer wants more flexibility and control there's always the option of falling back to explicitly running commands but that's discouraged.
Pro Broad cross-platform support
Puppet is supported on a wide range of operating systems. See the Docs for a complete list.
Pro Large helpful community
Puppet is very mature and relatively old. This means that it has gathered quite a following over the years. This large community means that there are a lot of modules, guides and configuration recipes ready to use built by the community.
Pro Complete
Puppet is a complete solution in terms of available features and modules. It has full support for all the main Operating Systems and provides lots of tools for its users.
Pro Exceptional enterprise support
Puppet Enterprise is used by 75 of the fortune 100 companies.
Pro All-in-one Package since version 4
With Facter, Collective and Hiera.
Pro Helpful UI
Puppet's UI is very useful. It allows real-time control of managed nodes by using modules and configuration recipes that are on the master servers. Although the UI is great for management, it lacks when trying to configure modules.
Pro Easy to learn
Puppet is model-driven and easier for diverse teams (that may include non-devs) to learn than it's main competitor, Chef.
Pro Can enforce policy even without a connection to the puppet master
With cached catalogs, puppet agents can continue to enforce policy even while your masters aren't functional
Pro Agentless
Ansible does not use agents. Instead, all master-agent communications are handled via SSH commands or through the Paramiko module which provides a Python interface to SSH.
Pro Gentle learning curve
Ansible is agentless, making it quick and painless to setup. Ansible has clear and detailed documentation and provides plenty of built-in modules. Its DSL is obtained using YAML and a familiar template system.
Pro Simple tasks can be run from the command line
Some simple tasks such as triggering updates or reboots, or even checking if the service is running can be done without configuration files. These commands can be run from the command line instead.
Pro Support for major cloud providers
Ansible supports managing major cloud devices (AWS, RackSpace, Digital Ocean, OpenStack) through a collection of modules which are available.
Pro Extensible in any language / runtime
Although you may need to preinstall favorite programming environment, Ansible modules are accessed via shell calls and therefore any executable on the remote system built for use with Ansible may be used as an Ansible module.
Pro Web UI
Ansible has a Web UI in the form of AnsibleWorks AWX which unfortunately does not tie directly into the CLI. So configuration elements present in the CLI can not appear in the UI unless a sync pass is run. Although the Web UI is helpful and functional, it's still not as complete feature-wise as the CLI.
Pro Easy to customize
Ansible is very easy to customize. It doesn't force you to use a language with which you are unfamiliar. Instead, all commands are packaged into YAML modules which are called playbooks. So as long as you use a programming language that can output JSON, you are able to customize it.
Pro Rich diff
Modules that support rich diffs can expose nearly every detail of what will change. However not all core modules support diffs, so there may still be some opaque chances made.
Pro Creating reusable components is simple
Making roles modular and reusable is a fast process with Ansible.
Cons
Con Poor training materials
The puppet documentation does not contain any proper tutorials to help new users on board easily.
Con Interaction between modules can get quite complex very fast
Due to it's out of order execution you can easily get into race condition between different modules. You have to be very careful declaring pre-requisites for the tasks so they don't step on top of each other. On the other hand when you get this lets you deploy things much faster than straight line execution tools
Con Lacks flexibility
The lack of control over Puppet's model-driven approach can result in less flexibility and power from the tool.
Con Solid knowledge of Ruby is needed to create your own modules
Modules and configurations are written in a specific language based on Ruby or in Ruby itself. So in order to be able to create custom configuration and modules you need a solid knowledge of Ruby.
Although it's fair to mention that there are many modules already available for every use-case.
Con Requires culture shifts
You might find difficulty adopting puppet due to the effort involved in convincing admins to switch from procedural automation to desired state automation.
Con Does not enforce policy when the puppetmaster is offline
Does not enforce policy when the puppetmaster is offline, does have a caching mechanism but since it does not include any files that need to be transfer it basically does not work
Con Slow as hell
Compared with other CM tools it's very slow and needs to do a lot of caching to give it the impression that it's fast (which it's not)
Con Syntax is a mess
To use puppet to the full extent you need to know the following tools; most of them are an integral part of puppet, Ruby, Ruby templates, puppet DSL, Hiera, Facter and Mcollective which all have a different syntax
Con Slow
Compared to other tools, Ansible requires more time to complete the same actions.
Con Somewhat weak documentation
Ansible is still relatively new, as far as server automation tools go. This is the reason that many users have found it's documentation lacking in some parts. Although this is mitigated by the fact that it's very easy to learn to use.
Con Too easy to move the port in the crappy scripts you've been using for years
If you have an extensive codebase of scripts, your users might find it too easy to just port in the same unsupportable crappy scripts they've been using for years.
Con Doesn't have its own inventory system
Ansible really depends on you to provide it a list of nodes to run on and doesn't actively maintain a central inventory
Con No Python API available, despite the fact that Ansible is written in Python
Despite being written and taking good advantage of the python environment, Ansible offers no python api for programming, and does not make it possible to follow best practices for writing custom Ansible modules.