Once again, I am taking this article from another website (http://www.infoworld.com/d/data-center/review-puppet-vs-chef-vs-ansible-vs-salt-231308). It is a very good article that I would like to remember. So, that is the reason why I re-post it again in my blog.
Review: Puppet vs. Chef vs. Ansible vs. Salt
The leading configuration management and orchestration tools take different paths to server automation
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.
[ Read the individual reviews: Puppet • Chef • Ansible • Salt | Puppet or Chef: The configuration management dilemma | Subscribe to InfoWorld’s Data Center newsletter to stay on top of the latest developments. ]
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 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.
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.