My blog, keeping you up-to-date with my latest news.


Chef Vs. Puppet

DevOps • 2014-08-06 • 3 Comments


Puppet or Chef? Chef or Puppet? This question has been asked in many companies or in the mind of developers wanting to evolve in deployement.
And, when asked the question about what deployment tool use, answer are usually: "Puppet is better", "Puppet is for pu**y, go Chef!".

After several months using Puppet and do some contributions on Stackforge, I had the desire and need to see what Chef have in the stomach!


First, I need to see in which languages they are written. Ok, both are in Ruby, except that Puppet use a D.S.L (Domain Specific Language), a mixte between JSON and Ruby.
Chef also use a D.S.L but based on the Ruby syntax.

Example with Chef.

file "/tmp/something" do
  owner "root"
  group "root"
  mode "0755"
  action :create

Example with Puppet.

file {"/tmp/something":
  ensure => "present",
  owner  => "root",
  group  => "root",
  mode   => 644,

As you can see, both do the same thing and are written almost in the same way.

After, we must do not forget that testing code is a priority, unfortunately lot a developers forgot, and the argument that say "Yes, but I you use Puppet you don't need to learn Ruby" is a silly nonsense because unit tests are written in Ruby (Puppet-rspec and ChefSpec), and same for acceptance tests (Beaker for Puppet, and Kitchen for Chef), even if there other way to do acceptance tests.

This is a really bad point for Puppet knowing that you must learn Ruby and Puppet D.S.L, so please, stop say that Puppet is easier to learn and write than Chef..


So, how does it works ? Oo
Puppet need that all dependencies must be declared because that's him who decided the execution order when he install or configures the server. So, you must write "Install A before B", otherwise, if you write "B before A" or "B after A" in the code, you will see a "Wild random result appeared!" (And can't catch 'em all)

Chef is cleaner, you only need to write "A before B", and it's done.

The Puppet system is harder to maintain when you have many traitments, all actions must be or have dependencies while avoiding cyclic dependencies.
And at the end, you need to write piece of code similar to this one, and again, please stop say that Puppet is easier to read...

Package["nova-common"] -> Nova_config<| |> -> File["/etc/nova/nova.conf"]
Nova_config<| |> ~> Exec["post-nova_config"]


Order for everybody to understand, a resource defines the desired state for a single element of this configuration on a node, eg properties of a file, a directory, a package, etc... So both have many resoruces, after reading documention on OpsCode and Puppetlabs, it seems that Chef have better resources for Linux user (That fortunately I am :D).

A simple example is that Puppet does not support Bash by defauft, insteaf of Chef.

After trying to make custom resources with Puppet ( and on Chef (, no way for me the easiest way is with Chef.

After you can use dependencies to add custom resources already created by the community, like stdlib or inifile to make Puppet more flexible, it's just become harder to create them.

Personnally,I do not care about Windows or Mac OS, or even all the resources related to Nagios that Puppet offer, which is why I would give one more point to Gryffin... Chef :)

Facter Vs. Ohai

Facter, Ohai, What's this? oO
In few words, this two command line tool will scan your little server and tel you somme interesting informations about your system, such as IP, RAM, users, etc...

vagrant@os-database:~$ ohai ipaddress
vagrant@os-database:~$ facter ipaddress

Again, both do the same thing, but one is in JSON, and other in plain text.
Anf if we go further and we were looking for information on memory.

vagrant@os-database:~$ ohai memory
  "swap": {
    "cached": "0kB",
    "total": "786428kB",
    "free": "786428kB"
  "total": "503248kB",
  "free": "189124kB",
  "buffers": "71060kB",
  "cached": "94688kB",
  "active": "184284kB",
  "inactive": "84232kB",
  "dirty": "0kB",
  "writeback": "0kB",
  "anon_pages": "102784kB",
  "mapped": "16708kB",
  "slab": "27076kB",
  "slab_reclaimable": "14316kB",
  "slab_unreclaim": "12760kB",
  "page_tables": "2904kB",
  "nfs_unstable": "0kB",
  "bounce": "0kB",
  "commit_limit": "1038052kB",
  "committed_as": "479556kB",
  "vmalloc_total": "34359738367kB",
  "vmalloc_used": "21956kB",
  "vmalloc_chunk": "34359712572kB"
vagrant@os-database:~$ facter | grep memory
memoryfree => 348.46 MB
memorysize => 491.45 MB
memorytotal => 491.45 MB
vagrant@os-database:~$ facter | grep swap
swapfree => 768.00 MB
swapsize => 768.00 MB

Ouch!! Ohai find more information than his colleague, after this is a JSON, but with the Ruby Power, it's easily exploitable.

If you want to customize this tools, you can create plugin, Facter allow you to write plugin in plain text, JSON, Yaml, Ruby, Python, etc... Ohai needs to return a Ruby Hash, a Mash, and Array or plain text.

Nothing complicated here, it will depend on your needs, I would still prefer Ohai for his informations, and Facter for how to write plugin.

Hiera Vs. Data Bags and attributes

Hiera is a tool to manage the configuration of your Puppet project, it's very powerful and allows you to start classes, stocks and make puppet easier to use and configure.
The principle is simple:

  • Define the hierarchy
  • Write data with key / value in YAML or JSON
  • Overload if necessary data with multiple hiera files
  • Use facter if you want
  • Make a puppet apply with the parameter --hiera_config

Unlike Puppet, the hierarchy is very important and you must not forget to put "A.yaml" before "B.yaml", otherwise you will have unexpected data overload.

myData: 'my value'
  - 1
  - 42
myClass::myAttribute: 'my value'

It's simple, fast, and efficient.

Chef uses simple attributes:

  • Write the attributes in a Ruby file in the attributes directory in your cookbook
  • Use variables "default", "force_default", "normal", "override", "force_override" or "automatic"
  • Use Ohai or other cookbooks attributes
  • Use Ruby code :)
  • Run your cookbooks

While the hierarchy is built with Puppet, Chef strength hers.

For the data bags, there're gloabl variables stored in files, they can be encrypted using a key (eg openssl), they will allow you to save confidential informations such as passwords, ssh-keys,or whatever you think they are private. If you are using verioning tools (I hope), you will be able to add, commit and push your "data bags" files without fear that someone will steal your passwords

For this part here, chef can be more complicated, but again, the power of ruby is authentic, you'll be able to do whatever you want.
Hiera is still pretty cool and powerfull, but the data bags are still top.

Kitchen Vs. Beaker

I know that many developers do not know or do not want to test their code. Yes, yes, I know a lot.
However, it is important, especially when you work for "Continuous Delivery" team :)

If we return to Kitchen (Chef) and Beaker (Puppet), both do the same things, and as I said above it is necessary to learn a minimum Ruby syntax especially if we used ServerSpec to write tests .
Anyway, what interests me most is the support tools on which I can run my test suites.

Support for Beaker:

  • vSphere
  • Vagrant
  • Google compute Engine
  • Solaris
  • EC3
  • VMWare

Beaker is a new tool that takes over rspec-Ssytem unfortunately it is not mature enough, eg vagrant configuration is fixed and you must modify the source code to increase performance of the VM.

Support for Kitchen:

  • Openstack o/
  • DigitalOcean
  • Vagrant
  • Joyent

Yes, you guessed it, the little smiley beside Openstack is a very good point, I love this tool and I often thought it a pity that the Puppet tools do not focus more on him.

Command line

Puppet is easier to use. With a simple "puppet apply" and good options, it's done, your manifests will be executed. if you use a puppetmaster, nothing complicated either, you syncrhonize your client with your server, a "puppet agent --server" and done again.

Chef is different, when I locked on it the first time, I saw chef-client, chef-zero, chef-shell, chef-apply, chef-dk, chef-solo, chef-server,... yes you understand, I was completely lost. especially since not all are tools from the command line :) So I take the time to read and understand how work the beat!

The plus for chef is his "knife" tool which help you to manage:

  • Nodes
  • Cookbooks and recipes
  • Roles
  • Data bags
  • Environments
  • Resources on the cloud including the provisioning (eg Openstack)

The point goes to Puppet regarding ease of use, but Knife still the difference and after using Chef commands, you will see that's not really complicated ;)

And the winner is...

  • Language: Chef
  • Approach: Chef
  • Resources: Chef
  • Facter vs Ohai: Draw
  • Hiera vs Data bags: Chef
  • Beaker vs Kitchen: Chef
  • Command line: Draw

If I take only these criteria, Chef is a best tools and after use I agree.
However, other criteria may be interesting, as the community, the number of modules, upadtes, support for versions of ruby...

It's time to you to get an idea by trying both.

But the most important in all this is that you must stop saying "You need to be a developer to use Chef, it's easier to write Puppet manifests".

<< Back to Blog Discuss this post



  1. John

    Facter requires a plugin to output JSON / YAML is pure nonsense. For the longest time facter provided -y flag to output YAML, and recent version supports --json flag to print out in JSON.

    Another thing to consider is availability of your package. On my Fedora 23, I can install facter via DNF but I can't install ohai. That's more reason to go with facter than ohai for me.

  2. HeLin

    What an awesome way to explain this-now I know evtehrying!

  3. Journey

    Which came first, the problem or the soluoitn? Luckily it doesn't matter.


Add a comment

  • Please verify you are human