Puppet and Chef have both evolved significantly—suffice to say, we’re long overdue in revisiting these two heavy-hitters. In this article we’ll take a fresh look at their core components along with new ecosystem tools and integrations that continue to position them as leading enterprise IT automation platforms.
Some past differentiators—like each platform’s respective declarative/procedural approach and underlying programming language—have been discussed ad nauseum. And as both solutions continue to grow more powerful and complex, said differences are in fact less relevant. For the purposes of this comparison we’ll instead focus on how well they solve IT and continuous delivery challenges faced by today’s enterprises.
Chef
Merely labeling a tool as a DevOps solution does not make it so. It must address contemporary IT challenges in building/managing high-velocity organizations while facilitating constant improvement and collaboration between groups. Tools—as critical agents of change—are instrumental in both managing technology as well as shaping culture:
“The tools we use reinforce the behavior; the behavior reinforces the tool. Thus, if you want to change your behavior, change your tools.”
– Adam Jacob, CTO, Chef
Chef extends this notion further by using martial arts as a metaphor for DevOps, specifically—Kung-fu. Below is a breakdown of Chef’s particular school of DevOps Kung-fu:
Indeed, many of the tenets highlighted above (e.g., collect metrics, integrate and deliver continuously, put applications and infrastructure through the same workflow) are manifest in Chef 15.
Chef Features and Highlights
At the basic level, Chef is a tool for automation, provisioning and configuration management. The platform is made up of the following components:
- Chef Server: the main hub where Chef propagates and stores system configuration information and policies (i.e., recipes and cookbooks). The Chef management console is the web user interface for Chef Server.
- Chef Client: installed on every node being managed, the Chef Client performs configuration tasks on the local machine.
- Chef Workstation: allows designated workstations to author/test/maintain cookbooks and upload them to Chef Server. Workstations are also used when utilizing the Chef development kit package.
- Chef Analytics: a platform that provides actions and run history, real-time reporting, and notifications around Chef automation activities.
- Chef Supermarket: an open source directory of community-contributed cookbooks
Continuous Delivery With Chef Automate
Traditional Puppet vs. Chef comparisons usually depict the latter as being more developer-friendly, with favorites like Chef’s Knife Plugin Architecture and the Chef Developer Kit (Chef DK) relegated mostly to developer use. At the 2015 ChefConf event, a new DevOps workflow product was introduced: Chef Delivery, a set of tools that added yet more developer-friendly features like comprehensive codebase change histories, metrics, and permissions management to the platform. Chef has since built these automation and continuous delivery into Chef Automate, a platform that brings together all of Chef’s infrastructure automation tools.
Chef Automate’s automated testing and continuous integration/delivery tools include features such as a shared workflow pipeline, collaboration capabilities, and enhanced analytics—as well as ecosystem integrations with AWS, Azure, and Docker, to name a few. Though these enhancements are no doubt a boon to Chef’s developer community, Chef’s aspirations arguably have little to do with becoming a developer-centric automation tool and more with building a comprehensive platform for DevOps pipeline management.
Improved Security With Chef Vault
Customer and/or community customizations quite often become so widespread and integral that they find their way into bonafide product releases. This is certainly the case with Chef Vault, a project started by Nordstrom to improve upon the platform’s inherent security mechanisms. Chef can natively store sensitive data (e.g. SSL certificate keys, database passwords) in encrypted “data bags”—repositories of key/value pairs—for secure and easy access. Management of these data bags, however, is a tedious and error-prone process. Chef Vault provides an additional layer of security that enables easier management of these encrypted data bags.
Chef Vulnerabilities
Per the Common Vulnerabilities and Exposures (CVE) database, Chef has a total of 3 reported vulnerabilities of medium severity:
Chef also maintains an ongoing list of security notes that provide customers proper remediation guidelines in addressing security shortcomings of the platform.
Chef Cybersecurity Risk Profile
.png)
We've taken a look at Chef's website to see if we could discover any any potential cybersecurity risks that could result in data leaks or data breaches.
Not surprisingly, Chef, a relatively sophisticated technology company scores a respectable B security rating (770/950).
Among its most significant risks are an insecure SSL/TLS version leaving it open to man-in-the-middle attacks. A lack of DMARC and DNSSEC.
Learn more about risk factors for the chef.io website or get your own security rating for free.
Puppet
As mentioned previously, Puppet is considered a more operations and sysadmin-oriented solution when compared to Chef, though again—these role-based distinctions are becoming less relevant with each release. DevOps practitioners—both developers and operations staff alike—strive to achieve optimal conditions for continuous integration/delivery. Tooling is therefore increasingly evaluated based on its ability to achieve these ends effectively and efficiently in the context of an enterprise’s unique needs. Notwithstanding, Puppet has enjoyed significant first-mover advantages over the years, and though both Chef and Puppet have been neck-to-neck market leaders since the early days of IT automation, the latter boasts a longer commercial track record and larger install base.
Currently on version 6.11, Puppet is commonly deployed in a client/server configuration with managed nodes periodically synchronizing their configurations with the server. Reporting (e.g., results from automation runs, errors/exceptions) and other information is sent by the clients back to the server for aggregate analysis and processing. The following graphic is a basic representation of Puppet’s data flow:
Puppet Features and Highlights
Puppet automation works by enforcing the desired state of an environment as defined in Puppet Manifests—files containing pre-defined information (i.e., resources) describing the state of a system. The core components that comprise Puppet are as follows:
- Puppet Server - the central server that manages Puppet nodes (agents)
- Puppet Agent - client software installed on managed nodes that enables communication and synchronization with the Puppetmaster
- Puppet Enterprise Console - a web GUI for analyzing reports and controlling infrastructure resources
- PuppetDB - data storage service for Puppet the data produced by Puppet
Other key components worth mentioning over others include MCollective, a framework for supporting server orchestration or parallel job execution, and Hiera—a hierarchical key/value lookup utility for providing node-specific configuration data to Puppet (for keeping site-specific data out of manifests). Puppet has integrated MCollective, Hiera, and a myriad of other open source projects into its platform to provide comprehensive automation and management of mission-critical enterprise infrastructures. Many community-contributed add-ons are also available on Puppet Forge—an expansive library of open source modules for extending the platform’s features and capabilities.
Updates to Puppet Node Manager
Puppet’s Node Manager enables the creation of rules around node attributes, which allows for easier more efficient node management. With Node Manager, nodes can be managed based on their job rather than name, eliminating the need to manually classify each node. New updates include powerful provisioning capabilities for Docker containers, AWS infrastructure and bare-metal machines.
Introducing Puppet Code Manager
Puppet has been a mainstay of the DevOps movement since its inception and continues to address the enterprise’s continuous integration/delivery requirements. The concept of “infrastructure-as-code” entails using software development best practices to manage infrastructure configurations and provisioning details—including code review, version control, and collaborative development, among others. And like Chef, Puppet’s platform has evolved in response to the growing needs for a comprehensive mechanism to manage the continuous delivery pipeline.
Available since Puppet Enterprise 3.8, Puppet Code Manager provides a consistent, automated way to change, review, test and promote Puppet code in a continuous delivery framework. Based around R10K—a general purpose toolset for deploying Puppet environments and modules by interfacing with a version control system—Puppet Code Manager accelerates the deployment of infrastructure by rendering it a testable and programmatic process. And by enabling easy integration with Git for version control, this latest addition to the Puppet platform further blurs the line between software and infrastructure.
Software Defined Networking (SDN)
SDN is a new paradigm for networking that decouples network control and forwarding from physical infrastructure, enabling agile management of network resources in rapidly changing environments. Just as cloud computing enables IT to quickly spin up compute and storage instances on-demand, SDN replaces rigid (and sometimes manual) network operations with dynamically provisioned network services and resources.
This new model for networking is right in line with Puppet’s advocacy of “infrastructure as code.” As such, the company has made significant strategic initiatives and partnerships in support of SDN. For example, Puppet Labs recently announced a partnership with Arista Networks—a leading developer of SDN switches—to provide automation support to the vendor’s SDN equipment line. This and other similar partnerships (e.g, Cumulus Networks, Dell, Cisco) will position Puppet favorably over competing vendors once SDN technologies gain widespread adoption.
Puppet security and vulnerabilities
No software is without its share of vulnerabilities, and Puppet certainly has its own. The company actively maintains a repository of Puppet security disclosures, with a complete list of reported vulnerabilities available via the CVE database. As of this writing, 79 vulnerabilities have been documented across Puppet’s ecosystem, with an average severity level of medium, and most of these applying to open source Puppet and Puppet Enterprise. Chef doesn’t maintain a CVE database for all of their products. The only product they have issued CVEs for, Chef, contains 3 CVEs from 2012.
Puppet Cybersecurity Risk Profile
Puppet's overall risk score, as measured by the Upguard Cybersecurity Rating scores an A (903/950), much higher than Chef's B rating.
However, the devil is in the details when it comes to misconfiguration, and Puppet is opening itself and its customers up to email spoofing powered phishing and spear phishing campaigns with its lenient SPF filtering.
Like Chef it also doesn't utilize DNSSEC.
Learn more about risk factors for the puppet.com website or get your own security rating for free.
Chef vs Puppet: DSL Differences and Ease of Use
While Chef and Puppet are much closer in design than radically different configuration management tools such as Ansible. The first major difference is that tools like Ansible rely on an agentless architecture, whereas both Chef and Puppet use a master-agent or puppet-slave, agent based architecture. For Ansible, configuration management changes are propagated from any work machine via SSH rather than clients on the nodes. The second major difference from those other tools is the use of the Ruby programming language upon which Chef and Puppet are built. In day to day usage, however, you will notice subtle differences between Chef and Puppet, thanks in large part to each platform’s usage of a unique domain specific language to automate configuration management.
First up, the Chef DSL looks syntactically like Ruby, in fact, it’s a standard Ruby DSL with special functions and keywords added in to handle infrastructure and application configuration across OS platforms that include Linux, Windows, and more. Because the Chef DSL allows you to write normal Ruby code alongside calling the Chef specific functions and using Chef specific keywords, it comes with a lower learning curve for those devops teams that use Ruby regularly for their work. For example, getting a Ruby developer up and running with Chef will probably take less than a single afternoon and a few quick Google searches. This is not the case with Puppet, which uses a DSL that, while declarative, strays far from standard Ruby syntax.
To see these two at work, consider the following code example which installs the Apache web server.
Chef:
package "apache2" do
action :install
end
Puppet:
class apache {
package { 'apache':
name => $apachename,
ensure => present,
}
}
The DSL differences are superficial when you look at simple use cases, but they lead to different baked in effects. Chef, for example, tends to be very flexible since you can accomplish whatever you want using standard Ruby helpers and functions. All the expressive power of Ruby is available to you. This has both advantages and drawbacks, notably that you introduce unnecessary complexity that may be hard for maintainers of your Chef recipes to untangle.
Puppet’s DSL has the strength that it keeps most tasks simple and there’s generally one sure way to do things. The downside is that if your team has complex configurations to handle, you will find yourself fighting against the constraints imposed by the DSL. It’s been noted that Chef’s DSL is friendly to Ruby developers while Puppet’s DSL is more friendly and closer to system administrators who might prefer a configuration language not far from XML or other declarative config files. Such a view remains true, though, as noted, both platforms accomplish essentially the same tasks for the most part.
Chef vs Puppet: Microservices and Containerization Support
The popularity of containerization and tools such as Docker and Kubernetes have impacted the way applications are deployed. As applications have evolved from a monolithic architecture to granular microservices, the role of traditional configuration management tools has been called into question. After all, containerization platforms such as Google Kubernetes Engine and Amazon ECS come with tools for configuring containers in the cloud.
Chef has embraced containerization and built tools to support the build and deployment of containerized applications. Its open source Chef Habitat tool, available on Github, gives you a complete app lifecycle management tool that plays well with Docker, Kubernetes, and other containerization tools. Habitat’s versatility allows it to build and deploy traditional applications, such as legacy Java or Python applications, just as easily as granular microservices, through the use of a plan.sh file that provides all the details needed to build your application. Habitat integrates well with traditional devops tools such as Jenkins, and deploys to a large number of platforms, including Red Hat Linux, other Linux distros, Mac, Windows, and Unix. The package export formats available in Habitat are set to expand in the future, but already, Docker is included. The full list features:
- Docker
- ACI
- Mesos
- Tar
- cloudfoundry
Puppet has also integrated mechanisms to make it easy for system administrators to manage and deploy containerized applications. Puppet has had multiple supported modules for installing and managing Docker, including downloading and configuring Docker images. The latest version of the Puppet Docker module available in Puppet Forge enables the running and managing of Docker containers using Puppet code. Puppet’s Docker module supports the following operating systems:
- RedHatLinux
- Windows
- Ubuntu
- Debian
- CentOS
Test Automation for Chef and Puppet Code
Good code practices include testing your code early and often, with test-driven development practiced popularly across sections of the tech industry. The move of infrastructure configuration to infrastructure as code (IaC) facilitated by devops tools such as Chef and Puppet means that there is greater scope for running lightweight tests to verify any changes that will be rolled out in your infrastructure.
Puppet’s development kit, the PDK, provides tools for unit testing as well as validating the syntax of your Puppet code files, including your metadata.json file which tracks all the module’s metadata in JSON format. Puppet relies on standard tools, including RSpec and Cucumber, for testing your Puppet code.
Chef, on the other hand, supports all the above and also includes powerful tools for testing the correctness and compliance of your infrastructure code. The first of these tools is ChefSpec, a framework that extends RSpec’s capabilities to allow testing your recipes as part of a simulated Chef Infra Client run. A plethora of examples are available in the ChefSpec Github repository to help you get started.
Another comprehensive testing tool for Chef recipes is Kitchen, which allows integration testing of your Chef cookbooks and infrastructure code, with a driver plugin architecture that tests your code on virtualization and containerization tools such as Vagrant and Docker, as well as cloud platforms.
Kitchen even includes support for integration testing configuration management code run by other configuration management tools such as Ansible and Saltstack. For those use cases, specific provisioners are required, which are available as open source libraries on Github. The Chef integration testing and compliance testing ecosystem is much more featureful than that offered by Puppet. Chef’s ecosystem also includes Chef Automate, an enterprise level tool to automate security compliance and manage your infrastructure’s automation from a single dashboard.
When to Choose Chef Over Puppet
Now that we’ve seen how these two platforms work under the hood and how they accomplish many of the same things, a word about choosing the right platform for your team’s requirements. One tool will be a better fit for one environment and set of requirements versus another, and this is something you must seriously ponder before making the selection for your team.
To begin, you might choose Chef in environments where you want to account for complex configuration management scenarios such as deploying to multiple targets in the cloud and on virtualization platforms. Chef’s design plays well in scenarios where you need the full power of the Ruby programming language to code your recipes, with little in the way of constraints to do things a certain way.
The Chef ecosystem, in particular Chef Habitat, has you covered when it comes to building your applications to run on just about any system you have in mind, and this will help simplify your containerization workflows with Docker or Kubernetes. Chef has excellent support for the open source community and other tools your enterprise may use, such as Kubernetes, Nagios, Docker, and more. Integrations are available for cloud platforms like Rackspace, with Amazon EC2 going a step further by integrating Chef servers via the AWS OpsWorks for Chef Automate service. In a sign of its open source commitment, in April 2019, Chef’s CEO announced in a blog post that Chef would be making all its products open source. Once your team has mastered Chef once, you will continue reaping the dividends by using Chef expertise across its wide, open source, ecosystem.
When to Choose Puppet Over Chef
Puppet, with its declarative style, appeals to organizations that want a reliable and easy to use tool for configuration management. This philosophical difference stands out starkly from a tool like Chef, which, while equally powerful, takes a lot more programmatic effort, involving the use of pure Ruby and the Chef DSL. The decision to use Chef imposes a steeper learning curve for non Ruby developers. The declarative style of configuration management comes with numerius strengths, including ease of maintenance and keeping configuration implementation consistent across the team.
Puppet has these advantages in common with other declarative CM tools such as Ansible, which uses the YAML format for composing configuration playbooks in a declarative style. If your devops team consists of a high number of system administrators who are likely more familiar with declarative configuration files, then using Puppet will better suit your team. Puppet is a much more opinionated configuration management tool than Chef, and should, arguably, work better on very large teams where Puppet, by design, places in-built constraints on code style.
Summary
Chef and Puppet continue to expand their automation platforms in response to the needs of the DevOps-enabled enterprise, with new features such as Chef Delivery and the Puppet Code Manager helping to streamline the continuous integration/delivery pipeline. Both vendors are forging partnerships that may ultimately define—as Chef would put it—what school of DevOps a particular organization belongs to. In the past, the two partnered with Microsoft to integrate their platforms with Azure, and Puppet—no stranger to being a first mover—was early to make key alliances with leading SDN vendors to position it favorably as the technology takes hold. So if your organization plans on adopting SDN, Puppet might be a stronger candidate in this respect.
Security is an enterprise-wide concern these days and should be taken into account when evaluating technologies. Chef has made significant strides in improving its platform’s security with Chef Vault, though its 3 published CVE vulnerabilities certainly pale in comparison to Puppet’s 79. It’s interesting that Puppet Labs rebroadcasts CVEs for vendored software such as ruby while Chef does not, despite both products including Ruby as a core component. It’s also difficult to believe Chef hasn’t found a vulnerability in any of their software since 2012.
In short, both IT automation platforms have matured greatly as enterprise solutions. We've highlighted some of Chef and Puppet’s key attributes and benefits—selecting the right option comes down to identifying each platform’s core competencies and determining which of these fall in line with your organization’s unique needs and requirements. Regardless of which automation platform you choose, UpGuard can complement either solution to round out the DevOps toolchain with advanced vulnerability assessment and monitoring, ensuring that security—as a function of quality—is baked in at every step of the continuous delivery process.
A good rule of thumb is Puppet is like writing configuration files while Chef is like programming the control of your nodes. If you or your team have more experience with system administration, you may prefer Puppet and if you're mostly developers, Chef might be the best fit.
Disclaimer
The cybersecurity risk profiles were last updated on December 12, 2019.
While we are committed to representing each company's risk profile accurately, this blog is not the place for real time risk monitoring, and the above information should be taken as point in time snapshots.
Puppet vs Chef Infographic
