Ten years ago, there were only two choices for provisioning and configuration management: CFEngine and IBM Tivoli. Neither solution was up to the challenges of the cloud or even the virtualized data center, and thus Puppet and Chef were born.
But today, Puppet and Chef are no longer alone: New tools have cropped up from AnsibleWorks and SaltStack, and they both offer healthy alternatives for DevOps.
“Admins are becoming developers,” said Luke Kanies, founder and CEO of Puppet Labs. “There is a shift going on around what [the] operations role is. It becomes much more about the entire application, and the view of it that the business has. It’s much more about the vertical silos than it used to be. You’re a DBA sys admin or a virtualization sys admin. Now there are technology specialists. Once you’ve got the automation in place, it becomes about the horizontal extraction that works across an application. There’s all this change going on, and in some ways it’s all relatively predictable.”
So what, if anything, distinguishes the four commercial provisioning and configuration-management systems? For one thing, Puppet is strictly focused on handling the configuration of servers after they’ve been stood up. It specializes in going through a fresh system and flipping all the important bits you’ve specified beforehand: user access controls, network routing information, HTTPD configuration and .htaccess, as well as anything else that can be changed on a server.
Chef, on the other hand, is all about actually installing all the various components, and building a server from scratch. It does this through Recipes. Recipes are written to describe what a system should look like in its end state; perhaps that means installing a specific version of Java, then Apache Web Server, then Tomcat.
Both Chef and Puppet achieve their goals through scripts that define how a system should be configured and laid out. Thus, the meat of the DevOps day job can quickly become the care and maintenance of all Chef and Puppet scripts.
The end game here, however, is to get to the point where systems can be programmatically defined and dynamically provisioned. It is for this reason that Chef uses Ruby as its Recipe programming language.
Just as each Java team would have someone charged with maintaining Ant scripts, or with keeping a local Maven repository up to date, Chef and Puppet are often the focus for semi-code aware IT folks.
But when the person charged with handling these scripts comes from the development side, it can quickly become obvious that coding Recipes and Puppet scripts is a fulltime job. It’s no wonder so many developers have warmed up to Ansible.
Ansible is a simple take on the configuration and provisioning problem. Instead of handling installs and script execution from a central server, Ansible just opens an SSH connection to the machine it’s provisioning, and then runs regular shell scripts.
Half of the appeal here is that Ansible does not require a new language, or an extensive period of initial script creation; many developers already have installation scripts lying around their test cluster or on their desktop machine. These can quickly be ported to Ansible.
When it comes to business needs and compliance, however, Chef and Puppet are lacking in one major feature: speed. This is why Salt was created. In a world of always-on cloud servers, Salt’s big trick is to immediately enforce changes to servers, ensuring that if a system is out of compliance now, it can be brought into compliance within a few minutes.
#!Jostling for features
When it comes to capabilities, both Chef and Puppet have five-year head starts on Ansible and Salt, but that’s not always an advantage. CFEngine was created in 1993, but it was long ago cast aside in favor of tools that addressed the new needs of the IT admin.
But so too do Salt and Ansible address the needs of users, particularly in cloud-based environments. Kevin Smith, vice president of engineering at Opscode (the company behind Chef), said that both Salt and Ansible have grown to meet provisioning and configuration-management needs that weren’t being met in the marketplace.
That said, however, he also intimated that some of the ideas these other projects espouse are now being taken on by both Chef and Puppet.
“My personal take on both Ansible and Salt is they do have good ideas there,” said Smith. “Rarely does someone build something like this just for fun: They have an itch they want to scratch. In Ansible’s, case I think the motivation there is to address some of the difficulty that more mature tools like Chef and Puppet have in getting setup and getting productive in their environments. Salt is much more about instant execution, which is something we’re addressing with push jobs in Chef.”
Puppet Labs’ Kanies said of Ansible: “I think it’s very cute. It’s great to have projects trying to find the edges of the market. It’s a complicated time, because there’s a very high churn in the early innovator market. Inside of a startup that has no admins, the things they’re looking at in a configuration-management solution are going to be fundamentally different from what enterprises are looking for. Overall, the push by Ansible and Chef and Salt to take over the market is a sign of the health of the market.”
Kanies is not a fan of some of the solutions proposed by these other options, however. A deeply passionate sys admin at heart, he created Puppet because he was fed up with CFEngine’s shortcomings.
Michael DeHaan, CTO of AnsibleWorks, said that “Ansible focuses on simplicity.” He said that Ansible is designed to execute its tasks in a rigidly ordered manner, thus ensuring administrators can have the same set of steps executed in the same order on every machine. Chef and Puppet both rely on their knowledge of the host operating system to determine the order of their actions, and thus installing items in a specific order can be tricky with Chef and Puppet.
This, however, was always touted as one of the more important features of Puppet: You didn’t need to care about the order of installation, or even how things were installed. If Puppet ran against a server and it was not fully configured properly at the end, you’d just run Puppet against it a second time.
That’s very different from the way Ansible takes on the problem. “I think Puppet was originally a very good step above CFEngine, but what we’ve been doing is looking beyond the way Puppet does things,” said DeHaan.
However, the very complexity of Chef and Puppet allows them to address complex configuration and provisioning needs that are the bread and butter of large IT shops. Specifically, Kanies said that the next obvious step for such systems is service orchestration.
“It’s kind of the next big thing,” he said. “Configuration management started out as a ‘bits on disk’ problem. How do I get these bits onto a machine? The minute you solve that problem, the user still has big problems: It starts to look like an application deployment problem. In order to do continuous delivery, you’ve got to have some aspects of orchestration.
“Orchestration needs vary considerably from one customer to another. A stateless wide-scale Web application might not need any orchestration at all. For something like a three-tier application, that probably needs more ordered bits on disc. It’s something we’re spending a lot of time on.”
But no matter which problems your configuration-management systems are solving, one thing is certain: Configuration management and provisioning systems can very quickly turn your operations team into a development team, or turn your development team into an operations team. That’s because Chef and Puppet require a lot of configuring and scripting on their own, enough to be a full-time job for your DevOps people.
In this way, DevOps can be quite similar to development, at least in workflows. “We treat our Cookbooks and Recipes as being source code, the same as any of our application component source,” said Opscode’s Smith. “It’s stored right alongside the component it’s going to deploy. As that component goes through its life cycle, it can be maintained in parallel. That’s a fairly common pattern we see out in the wild too.”
#!Future planning committee
Because so many IT admins are now writing Chef and Puppet code all day, both platforms are growing to address these needs. Puppet Labs, for example, acquired Geppetto, an IDE for writing Puppet scripts, this summer. Geppetto contains “all the tools a developer would expect to have, focused on configuration management rather than overall application development,” Kanies explained.
Still, he noted, DevOps skill levels and focuses vary widely from organization to organization. That means Puppet and its ilk have to address more than just the hardcore coder.
“You do see a segregation where you get people who are more developer-like and focus on the original code and focus on the things they’re more special at,” said Kanies. “Then there’s user people who say ‘I want four of those.’”
To address those “user people,” Puppet Labs is aiming to build a simpler interface for configuring machines. The idea is to allow users to pick broad strokes of configuration, and to have those configurations assembled, somehow, without the need to write lengthy scripts.
“You can say ‘I want all the machines in my London data center, but I want to upgrade them 10% of the time.’ You can do either percentages or individual node counts,” said Kanies, describing the capabilities of Puppet Enterprise, the company’s commercial version of Puppet and its surrounding tools.
Opscode’s future is taking a different approach, with Hosted Chef, a SaaS product offering that takes away the need to host your own Chef server.
For Ansible, DeHaan said that service orchestration and rolling updates are of paramount importance to Ansible’s enterprise appeal. While the platform is about agentless and simple configuration management, he said that one of the prime facets of the tool is the ability to pull from a Git repository on a regular basis, and to enforce those configurations across a cluster, moving slowly across servers like a lathe of updates.
