The proliferation of virtualization coupled with the increasing power of industry-standard servers and the availability of cloud computing has led to a significant uptick in the number of servers that need to be managed within and without an organization. Where we once made do with racks of physical servers that we could access in the data center down the hall, we now have to manage many more servers that could be spread all over the globe.
This is where data center orchestration and configuration management tools come into play. In many cases, we're managing groups of identical servers, running identical applications and services. They're deployed on virtualization frameworks within the organization, or they're running as cloud or hosted instances in remote data centers. In some cases, we may be talking about large installations that exist only to support very large applications or large installations that support myriad smaller services. In either case, the ability to wave a wand and cause them all to bend to the will of the admin cannot be discounted. It's the only way to manage these large and growing infrastructures.
Puppet, Chef, Ansible, and Salt were all built with that very goal in mind: to make it much easier to configure and maintain dozens, hundreds, or even thousands of servers. That's not to say that smaller shops won't benefit from these tools, as automation and orchestration generally make life easier in an infrastructure of any size.
I looked at each of these four tools in depth, explored their design and function, and determined that, while some scored higher than others, there's a place for each to fit in, depending on the goals of the deployment. Here, I summarize my findings.
Puppet Enterprise
Puppet arguably enjoys the biggest mind share of the four. It's the most complete in terms of available actions, modules, and user interfaces. Puppet represents the whole picture of data center orchestration, encompassing just about every operating system and offering deep tools for the main OSes. Initial setup is relatively simple, requiring the installation of a master server and client agents on each system that is to be managed.
From there, the CLI (command-line interface) is straightforward, allowing module downloads and installation via the puppet command. Then, changes to the configuration files are required to tailor the module for the required task, and the clients that should receive the instructions will do so when they check in with the master or via a push that will trigger the modifications immediately.
There are also modules that can provision and configure cloud server instances and virtual server instances. All modules and configurations are built with a Puppet-specific language based on Ruby, or Ruby itself, and thus will require programmatic expertise in addition to system administration skills.
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.
A Web UI is available for Ansible in the form of AnsibleWorks AWX, but AWX doesn't tie directly into the CLI. This means that configuration elements present in the CLI will not appear in the Web UI unless a synchronization pass is run. You can use that included synchronization tool to keep them in line, but it will need to be run on a scheduled basis. The Web UI itself is functional, but is not as complete as the CLI, so you will find yourself working between the two in general use, or just using the CLI.
SaltStack Enterprise
Salt is similar to Ansible in that it's a CLI-based tool that utilizes a push method of client communication. It can be installed through Git or through the package management system on masters and clients. Clients will make a request of a master server, which when accepted on the master allows that minion to be controlled.
Salt can communicate with clients through general SSH, but the scalability is greatly enhanced through the use of client agents called minions. Also, Salt includes an asynchronous file server to speed up file serving to minions, which is all part of Salt's focus on high scalability.
As with Ansible, you can issue commands to minions directly from the CLI, such as to start services or install packages, or you can use YAML configuration files, called "states," to handle more complex tasks. There are also "pillars," which are centrally located sets of data that states can access while running.
You can request configuration information -- such as kernel version or network interface details -- from minions directly from the CLI. Minions can be delineated through the use of inventory elements, called "grains," which makes it easy to issue commands to a particular type of server without relying on configured groups. For instance, in a single CLI direction, you could target every minion that is running a particular kernel version.
Like Puppet, Chef, and Ansible, Salt offers a large number of modules to address specific software, operating systems, and cloud services. Custom modules can be written in Python or PyDSL. Salt does offer Windows management as well as Unix, but is more at home with Unix and Linux systems.
Salt's Web UI, Halite, is very new and not as complete as the Web UIs for the other systems. It offers views of event logs and minion status, and has the ability to run commands on minions, but little else. This tool is under active development and promises to improve significantly, but for the time being it's bare-bones and buggy.
Salt's biggest advantage is its scalability and resiliency. You can have multiple levels of masters, resulting in a tiered arrangement that both distributes load and increases redundancy. Upstream masters can control downstream masters and their minions. Another benefit is the peering system that allows minions to ask questions of masters, which can then derive answers from other servers to complete the picture. This can be handy if data needs to be looked up in a real-time database in order to complete a configuration of a minion.
Puppet or Chef? Ansible or Salt?
Whereas Puppet and Chef will appeal to developers and development-oriented shops, Salt and Ansible are much more attuned to the needs of system administrators. Ansible's simple interface and usability fit right into the sys admin mindset, and in a shop with lots of Linux and Unix systems, Ansible is quick and easy to run right out of the gate.
Salt is the sleekest and most robust of the four, and like Ansible it will resonate with sys admins. Highly scalable and quite capable, Salt is hamstrung only by the Web UI.
Puppet is the most mature and probably the most approachable of the four from a usability standpoint, though a solid knowledge of Ruby is highly recommended. Puppet is not as streamlined as Ansible or Salt, and its configuration can get Byzantine at times. Puppet is the safest bet for heterogeneous environments, but you may find Ansible or Salt to be a better fit in a larger or more homogenous infrastructure.
Chef has a stable and well-designed layout, and while it's not quite up to the level of Puppet in terms of raw features, it's a very capable solution. Chef may pose the most difficult learning curve to administrators who lack significant programming experience, but it could be the most natural fit for development-minded admins and development shops.