Updated on June 23, 2017 by UpGuard
This is a tale of a newcomer vs a relative oldie in the Configuration Management (CM) arena. Both are tools to help the sysadmin or devops professional to better manage large numbers of servers. They excel at stuff like repetitive task automation, simultaneous deployment of apps and packages to a group of servers, or configuration and provisioning of new servers from scratch.
Chef was originally released in 2009 - in the world of CM tools, that’s an eternity ago. It is supported by parent sponsor Opscode, and is frequently compared and contrasted to that other old-timer CM tool Puppet. Like Puppet, Chef is also written in Ruby, and its CLI also uses a Ruby-based DSL. Chef utilizes a master-agent model, and 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. From there managed nodes authenticate with the master through certificates.
Chef doesn't yet have a well-formed push feature, though beta code is available to do this. But in the meantime the implication is that agents must be configured to check in with the master periodically and instantaneous master-to-agent rollout of changes isn't really possible. Continuing with the kitchen metaphor (see ‘knife’ above), Chef configs are packaged into JSON files called ‘recipes’. Also, the software can run in either a client-server or in a standalone mode called ‘Chef-solo’.
Ansible is quite different from Chef. It is similar to another upstart, Salt, than to the old boys Chef and Puppet. It was developed and first released in early 2012 by the parent company AnsibleWorks, and is starting to gain a dedicated following despite its youth and untested-ness. It is written in Python and only requires the Python libraries to be present on the servers to be configured, which anyway is the default on almost all Linux distros today. Ansible’s USP’s are its light weight, relative ease of use and speed of deployment compared to other CM tools. For example you don’t need to learn Ruby - Ansible packages all commands into YAML modules called playbooks - as long as your preferred language can output JSON modules, you’re good to go. Ansible also does away with the need for agents; all master-agent communication is handled either via standard SSH commands, or the Paramiko module which provides a Python interface to SSH2. An added bonus is the SSH’s excellent inbuilt security.
Chef is an older product, so its documentation is better than Ansible’s. That said, there are complaints by many new to Chef that it is quite confusing to learn compared to the blissfully simple Ansible. Chef offers support for Linux, *nix, and Windows. The browser-based GUI is quite good (again, no surprise considering it’s been around for a few years), although it’s not as complete as Puppet’s, lacking features like reporting and advanced config options. All in all, Chef’s relative maturity means it may appeal to corporations, who place a premium on stability, more than individuals.
IT guys are famous for avoiding documenting anything, so it’s no surprise that Ansible’s documentation is still a weak point. This, however, is somewhat mitigated by how easy it is to learn. Ansible is currently only available for Linux and Unix, and its GUI is terrible compared to Chef’s – it’s not even synced to the CLI, so you may occasionally find that the GUI and CLI give different results of a query. Ansible’s agent-less push-mode using the ZeroMq implementation at the transport layer means quick deployment and very low performance overhead; the caveat is that it’s just not as flexible and powerful as using agents.
First off, any admin or DevOps will be mighty glad to have such tools in their corner; just a few years ago there was much less choice in this field. Choosing either of them is a win, and your life will be richer and easier for it.
That said, if you must choose between them, consider your own needs carefully first and weigh them against what each solution offers. You can use the infographic below to compare Chef and Ansible.
Misconfigurations are an internal problem that emanate from within the IT infrastructure of any enterprise; no hacker is necessary for massive damage to occur to digital systems and stored data. And the problem is pervasive, with Gartner estimating anywhere from 70% to 99% of data breaches result not from external, concerted attacks, but from internal misconfiguration of the affected IT systems.