Review: Puppet vs. Chef vs. Ansible vs. Salt

Puppet Enterprise has the most complete Web UI of the bunch, allowing for real-time control of managed nodes using prebuilt modules and cookbooks present on the master servers. The Web UI works well for management, but does not allow for much configuration of modules. The reporting tools are well developed, providing deep details on how agents are behaving and what changes have been made.

Enterprise Chef

Chef is similar to Puppet in terms of overall concept, in that there's a master server and agents installed on managed nodes, but it differs in actual deployment. In addition to a master server, a Chef installation also requires a workstation to control the master. The agents can be installed from the workstation using the knife tool that uses SSH for deployment, easing the installation burden. Thereafter, managed nodes authenticate with the master through the use of certificates.

Configuration of Chef revolves around Git, so knowledge of how Git works is a prerequisite for Chef operation. Like Puppet, Chef is based on Ruby, so knowledge of Ruby is also required. As with Puppet, modules can be downloaded or written from scratch, and deployed to managed nodes following required configuration.

Unlike Puppet, Chef doesn't yet have a well-formed push feature, though beta code is available. This means that agents will need to be configured to check in with the master periodically, and immediate application of changes isn't really possible.

The Web UI for Enterprise Chef is functional, but does not provide the ability to modify configurations. It is not as complete as the Web UI for Puppet Enterprise, lacking in reporting and other features, but allows for inventory control and node organization.

Like Puppet, Chef benefits from a large collection of modules and configuration recipes, and those rely heavily on Ruby. For that reason, Chef is well-suited to development-centric infrastructures.

AnsibleWorks Ansible

Ansible is much more similar to Salt than to either Puppet or Chef. The focus of Ansible is to be streamlined and fast, and to require no node agent installation. Thus, Ansible performs all functions over SSH. Ansible is built on Python, in contrast to the Ruby foundation of Puppet and Chef.

Installation of Ansible can be done through a Git repository clone to an Ansible master server. Following that, nodes to be managed are added to the Ansible configuration, and SSH authorized keys are appended to each node, related to the user that Ansible will run under. Once this is done, the Ansible master server can communicate with the node via SSH and perform all required tasks. In order to function with operating systems or distributions that do not allow root SSH access by default, Ansible accepts sudo credentials in order to run commands as root on those systems.

Ansible can use Paramiko, a Python SSH2 implementation, or standard SSH for communications, but there's also an accelerate mode that allows for faster and larger-scale communication.

Ansible can be run from the command line without the use of configuration files for simple tasks, such as making sure a service is running, or to trigger updates and reboots. For more complex tasks, Ansible configuration is handled via YAML syntax in configuration files called Playbooks. Playbooks can also use templates to extend their functionality.

Ansible has a collection of modules that can be used to manage various systems as well as cloud infrastructure such as Amazon EC2 and OpenStack. Custom Ansible modules can be written in just about any language, as long as the output of the module is valid JSON.