Postedby ScriptRock Jul 17, 2014 8:00:00 AM
This is a tale of a newcomer vsa relative oldie in the Configuration Management (CM) arena. Both are tools tohelp the sysadmin or devops professional to better manage large numbers ofservers. They excel at stuff like repetitive task automation, simultaneousdeployment of apps and packages to a group of servers, or configuration andprovisioning of new servers from scratch.
What They Are, How They Work
Chefwas originally released in 2009 - in the world of CM tools, that’s an eternityago. It is supported by parent sponsor Opscode, and is frequently compared andcontrasted to that other old-timer CM tool Puppet. Like Puppet, Chef is alsowritten in Ruby, and its CLI also uses a Ruby-based DSL. Chef utilizes amaster-agent model, and in addition to a master server, a Chef installationalso requires a workstation to control the master. The agents can be installedfrom the workstation using the ‘knife’ tool that uses SSH for deployment,easing the installation burden. From there managed nodes authenticate with themaster 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 implicationis that agents must be configured to check in with the master periodically andinstantaneous master-to-agent rollout of changes isn't really possible.Continuing with the kitchen metaphor (see ‘knife’ above), Chef configs arepackaged into JSON files called ‘recipes’. Also, the software can run in eithera client-server or in a standalone mode called ‘Chef-solo’.
Ansibleis quite different from Chef. It is similar to another upstart, Salt, than tothe old boys Chef and Puppet. It was developed and first released in early 2012by the parent company AnsibleWorks, and is starting to gain a dedicatedfollowing despite its youth and untested-ness. It is written in Python and onlyrequires 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’sare its light weight, relative ease of use and speed of deployment compared toother CM tools. For example you don’t need to learn Ruby - Ansible packages allcommands into YAML modules called playbooks - as long as your preferredlanguage can output JSON modules, you’re good to go. Ansible also does awaywith the need for agents; all master-agent communication is handled either viastandard SSH commands, or the Paramiko module which provides a Python interfaceto SSH2. An added bonus is the SSH’s excellent inbuilt security.
Support, Performance, Ease of Use
Chefis 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 learncompared to the blissfully simple Ansible. Chef offers support for Linux, *nix,and Windows. The browser-based GUI is quite good (again, no surpriseconsidering it’s been around for a few years), although it’s not as complete asPuppet’s, lacking features like reporting and advanced config options. All inall, Chef’s relative maturity means it may appeal to corporations, who place apremium on stability, more than individuals.
ITguys are famous for avoiding documenting anything, so it’s no surprise thatAnsible’s documentation is still a weak point. This, however, is somewhatmitigated by how easy it is to learn. Ansible is currently only available forLinux and Unix, and its GUI is terrible compared to Chef’s – it’s not evensynced to the CLI, so you may occasionally find that the GUI and CLI givedifferent results of a query. Ansible’s agent-less push-mode using the ZeroMqimplementation at the transport layer means quick deployment and very lowperformance overhead; the caveat is that it’s just not as flexible and powerfulas using agents.
Conclusion
Firstoff, any admin or devops will be mighty glad to have such tools in theircorner; just a few years ago there was much less choice in this field. Choosingeither of them is a win, and your life will be richer and easier for it.
Thatsaid, if you must choose between them, consider your own needs carefully firstand weigh them against what each solution offers. You can use the comparisontable below to compare Chef and Ansible.
|
|
Pros |
Cons |
|
Chef |
More mature solution. Better documentation (slightly). Larger community, with a large collection of modules and configuration recipes. Support for Linux, Unix, Windows |
Ties users to Ruby. Doesn’t support push. Relies on JSON which is not as friendly as YAML. Not as easy to learn and deploy. |
|
Ansible |
Fast, agent-less deployment and communication. CLI supports almost any programming language. Uses Python, which is omnipresent in Linux distros. Excellent security using SSH / SSH2. |
Still very new; not yet tried and tested. GUI still underdeveloped. No support for Windows/ Mac OS. |
References
http://probably.co.uk/puppet-vs-chef-vs-ansible.html
http://benscofield.com/on-ansible/
http://www.infoworld.com/d/data-center/review-puppet-vs-chef-vs-ansible-vs-salt-231308?page=0,1