Updated on December 2, 2015 by UpGuard
As we move full-swing into what InformationAge is calling The Year of DevOps Culture, we thought it appropriate to look at some of our favorite DevOps tools and highlight their strongest attributes and perceived shortcomings. A plethora of solutions for configuration management and infrastructure provisioning is available these days-- Puppet, Chef, Ansible, and Salt are a few notable options. Chef is one of the more popular of the bunch, so we’ve put together a list of what we consider its top 5 best and worst attributes.
1. Easy Cloud Integration
From the get-go, Chef was engineered for close integration with other tools. This makes it an optimal solution for orchestration and automation in multi-cloud environments. Knife-- Chef’s command line tool-- can be extended through the use of plugins, allowing for the creation of custom subcommands to augment the base set of commands. This is critical for use cases that integrate heterogeneous cloud environments (e.g., organizations using different cloud vendors in their IT infrastructure). Chef even provides a series of Knife Cloud Plugins for out-of-the-box support of popular cloud offerings like Azure, EC2, and Eucalyptus.
2. A Framework for Both Windows and Linux
Though originally built for automating Linux environments, Chef supports Windows with a myriad of excellent features. For example, Chef’s Windows cookbook provides a number of Windows-specific resources for installing common Windows components easily. Other handy items include an IIS cookbook that automates the creation of IIS sites and web apps.
Chef is also continuing to broaden its support for Windows by incorporating Powershell’s Desired State Configuration (DSC) resources as native Chef resources. Chef’s dsc_resource enables the inclusion of any DSC resource in a Chef recipe.
3. Use of Ruby
Chef uses pure Ruby, so anyone with some experience using the popular language (or development in general) can learn how to cook. Basing its tool on a full-fledged programming language has other nice perks, like access to a standard library, a vast collection of open-source packages, and a broad body of community-based knowledge.
It’s worth noting that Puppet also uses a Ruby-based domain specific language (DSL), though it’s more along the lines of a JSON/Ruby hybrid. Version 2.6 of Puppet, however, does allow developers to work with pure Ruby. Check out this article to see how Puppet and Chef stack up against each other.
4. Docker Support
Virtual containers are all the rage these days in the DevOps world, and Docker is leading the charge with its flagship containerization tool. Chef can automate the creation, management, and monitoring of Docker containers through the use of its Knife Container Plugin.
5. The Chef DK (Chef Development Kit)
The Chef DK makes getting started with the framework easier by including everything needed to run Chef in one package. A host of other tools are also included in the development kit, like the previously mentioned Knife, Chef Client, Ohai, and Chef Zero. Chef DK is available for Mac OSX, Red Hat Enterprise Linux, Windows, Ubuntu Linux, and Debian.
1. Steep Learning Curve
Chef is notorious for its steep learning curve, so in most cases budgeting ample time is necessary to get up to speed. Command of the Ruby language is only one requirement for gaining proficiency--for example, knowledge of Git is also a prerequisite for mastering Chef. That said, acquiring a small body of Chef knowledge enables one to do dangerous things fairly quickly. Gaining a true understanding of how to correctly automate system configurations with cookbooks--including how to test them--requires considerable time and effort.
2. Use of Ruby
That’s right-- one of Chef’s best attributes is also one of its worst. Instead of using or creating a DSL for configuration management and automation, Chef uses a native subset of Ruby. For non-developers and IT staff like systems administrators, learning Ruby to master Chef is akin to learning German to drive a Porsche. While it’s true that some systems administrators learn Perl, Python, or Ruby to augment requisite shell scripting skills, most would prefer having a choice in the matter. Implementing Chef essentially adds another language required to perform systems administration tasks.
3. Order of Operations
Consider how Chef works: a list of recipes is applied to a node, with each single recipe consisting of an ordered list of resources to be applied. This imperative approach to configuration management and automation places critical importance on what order things are done. Instead of specifying a desired end state for the systems at hand (i.e., the declarative approach), Chef users must define exactly what to do and in what order, without any mechanism for dependency management. This adds more complexity to managing configurations and offers less insight into how systems are configured.
4. Reliance on JSON
Chef relies heavily on JSON, which works well for quickly loading or sharing website data between sites, but not so well for systems administration purposes. YAML, on the other hand, is more geared towards configuration management: it’s easier to read (no quotation marks, brackets, braces, or open/close tags), allows for commenting, offers extensible data types and relational anchors, and contains other syntax enrichments and features absent in JSON.
5. Mediocre Documentation
Though it’s gotten better as of late, Chef’s documentation still leaves much to be desired. This is a common gripe among Chef users; even aficionados will attest to this shortcoming, though they’d be quick to point out that as a newer player in the DevOps arena, Chef is continuing to build out its support materials and documentation corpus. Fair enough. All the same, this serves as no consolation for those unable to resolve issues using the current documentation and support materials.
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.