Today we pit two popular tools for configuration management against one another; Chef vs Puppet. These types of tools help engineers to maintain a consistent configuration in all servers. For instance, all servers might need to have IIS with a binding to port 443 for HTTPS access and the respective firewall rule for inbound traffic. More importantly, if anyone removes the firewall rule, these type of tools will keep consistency by creating the firewall rule again.
What about database connection strings where you have a different one for dev, test, and prod?
Yes, Puppet or Chef can handle these as well.
Today’s post is about comparing Chef with Puppet. These are very similar tools that accomplish the same goal: maintaining a consistent state. But, they also differ in how they help users to maintain consistency and repeatability throughout all the delivery pipeline. Lastly, I’ll talk about how to choose one tool over the other one, depending on your needs and the needs of your team.
So let’s get into it.
Chef and Puppet have similarities in how they manage configurations in servers. Even though both tools work in different ways internally, the result is the same. With both tools, you can define the desired state through code. Both tools work with a master-node architecture where the master is in charge of storing all data, and nodes are in charge of making sure servers always have the desired state configuration in place.
For instance, one of the main goals of using Chef or Puppet for configuration management is that you can define as code what should be the desired state of a group of servers. It shouldn’t matter if you want to apply the same configuration to servers, Chef and Puppet will make sure to implement any change in an independent way. In the same way, we all hit Ctrl + S several times to make sure we’re saving the changes. But where these type of tools shine is that if someone enters the server manually, and changes the desired state of the server, these tools will bring the servers up to date by re-configuring them.
From an architecture perspective, Chef and Puppet look pretty similar since they both use a master-agent architecture. A master node is where all server configurations get stored. Masters for both tools are highly available (HA), but with slight differences—more on this later. Then, for each server that you want to manage, there’s an agent installed that’s pulling the configuration in periods automatically. Agents are always checking that the desired state is compliant, not the other way around. Both tools can manage Linux and Windows servers.
Lastly, both tools have an open-source version and a paid version with more features like a better HA configuration.
I said before that the architecture of Chef and Puppet are similar, but they differ slightly on how they handle HA. In Puppet, the master replicates its data to another server, and they work in an active/passive way. For Chef, HA is handled with three servers in an active/active mode with an API front end that can scale horizontally.
A significant difference between Chef and Puppet is in how they define the desired state configuration for servers. Each tool has its own domain-specific language (DSL). Chef uses Ruby for DSL. You have more freedom to create complex configurations because you’re using a programing language. Chef calls this desired state configurations you write recipes. Anything that you can do with Ruby, you can do in Chef to create recipes like if-conditions or calling other libraries. The benefit to this is that developers might feel more comfortable writing Chef recipes. Moreover, developers won’t feel restricted to a DSL only, adding when defining a configuration.
On the other hand, Puppet has its own DSL, “which was designed to be accessible for sysadmins.” And if you have experience working with Nagios configuration files, writing manifests (their version of Chef recipes) won’t be a problem. You don’t have too much freedom here, but that’s also good from the perspective of having a universal language. Therefore, you don’t need to have a developer background to use and learn Puppet.
Lastly, these tools differ in how you develop and test recipes or manifests. Chef has a workstation including the Chef SDK that you can install in your local computer as a staging environment. You can test the recipes locally, then upload them to the master node. Puppet doesn’t have a workstation, but it has an SDK where you can test manifests while developing them. Moreover, you can apply manifests locally with the puppet apply command.
Let’s take a look at a code example of how to make sure the Stackify agent is installed.
A recipe in Chef will look like this (pure Ruby):
# ...
# bunch of variables declared
# ...
# download and extract stackify agent
tar_extract node['stackify']['stackify_agent']['agent_url'] do
target_dir Chef::Config['file_cache_path']
creates "#{Chef::Config['file_cache_path']}/#{stackify_agent_install_relative_path}/#{stackify_agent_install_script_name}"
not_if { File.exist?(stackify_agent_jar_location) }
end
template_file = "#{Chef::Config['file_cache_path']}/#{stackify_agent_install_relative_path}/stackify-agent.conf"
template template_file do
source "stackify-agent.conf.erb"
end
# run stackify agent install script
bash 'agent_install' do
user 'root'
cwd "#{Chef::Config['file_cache_path']}/#{stackify_agent_install_relative_path}"
code <<-EOH
./#{stackify_agent_install_script_name} #{stackify_agent_install_script_options}
rm -rf #{Chef::Config['file_cache_path']}/Linux
rm -rf #{Chef::Config['file_cache_path']}/#{stackify_agent_install_relative_path}
EOH
not_if { File.exist?(stackify_agent_jar_location) }
end
For Puppet, there’s a module to install the Stackify agent, and the manifest will look like this:
class { 'stackify':
package_ensure => 'present',
package_install_options_environment => 'development',
package_install_options_activationkey => 'XXXXXXXXXXXXXXXXXXXXXXXXXX',
file_download_directory => 'C:\\Temp',
service_manage => true,
service_ensure => true,
service_enable => true,
}
As you can see, the above code examples confirm what I said before. In Chef, you have more freedom. But in Puppet, the code might look simpler when there’s a module you can use.
Let’s take the comparison, including the premium features, which include other things besides configuration management.
For Puppet, they have Puppet Enterprise that includes the following capabilities:
They also have Puppet Remediate, which is a tool for vulnerability management of your servers. You can get better insights about which vulnerabilities exist in your servers, and apply patches at scale to all servers.
In Chef, besides configuration management, the paid version includes the following capabilities:
You get more details on each vendor site, they have pretty good resources to help you get started quickly.
How to choose between Chef and Puppet is a hard question, and the answer, as always, is … “it depends.”
Whichever tool you choose, it should be a team decision, especially from the ones who will end up working with the tool. A good approach could be considering the team’s background. Folks with a sysadmin background might find it more suitable to use Puppet. Even though they’ll have to learn the DSL, it’s never going to be like learning a programming language. Although, if they have a background in development, folks might like Chef more (even if they don’t know Ruby).
But you should also consider the premium features from each tool. Which of those features will help your organization to reduce silos and waste? Again, it all depends on your needs. I’ve seen that both vendors will always try to level-up with each other with the features. For example, in Puppet, you can create custom functions with Ruby.
And of course, another essential aspect is pricing. I don’t want to include prices here because it fluctuates a lot, and it varies depending on each customer needs. Another reason is that in the case of Puppet, their pricing page doesn’t have a public number but a “Contact Us” button. Chef, on the other hand, its pricing page has numbers, but you still need to contact them. I’d advise you to contact them directly and look for a good offer. Depending on the number of servers you need to manage they could offer you a better price.
As a friendly reminder, there’s no silver bullet for a configuration management tool. Both Chef and Puppet are very mature nowadays, and they’re constantly improving their product, making research investments, creating better ways for people to learn their tool, etc. I hope that this comparison has helped you to get a better understanding of how both tools work. Maybe you’re getting prepared for a job interview, or are curious about the main differences and similarities.
But if you’re deciding which tool to use for your company, make sure you have a clear idea of what problems you’re having and how these type of tools can help you alleviate the load. There’s always going to be a learning curve, and it will depend on the team’s background and which tool is more suitable for them. Moreover, look at the premium features and services besides configuration management, as your company might need more help with the compliance policies.
Stackify's APM tools are used by thousands of .NET, Java, PHP, Node.js, Python, & Ruby developers all over the world.
Explore Retrace's product features to learn more.
If you would like to be a guest contributor to the Stackify blog please reach out to [email protected]
