by Zachary Crownover, Technical Consultant at Taos
Objects are not completely foreign to Puppet, but the concept of them and their application with regard to the node is vastly different from Chef. The framework that Chef provides you with for building new configuration management objects will cause you to use traditional Ruby programming tools more so than with Puppet, and grant you the insight they do as well. There is a clear distinction between the two frameworks in the level of access to core Ruby features, as noted through gem support in Chef. Attention to execution order is key, regardless of your choice of configuration management system. Together with design characteristics, these subtleties in both systems make for a new and refreshing navigational experience.
It is true that in the Puppet world, nodes are objects as well, but the relation is more apparent in Chef. Everything is referenced as a direct aspect or attribute of the node itself. You have the full power of Ruby and IRB at your behest to accomplish the mission with Chef. You can launch a Chef Shell session, interactively advance through your cookbooks, and reference specific parts of all the actively running code, from variable values to testing new resources, to seeing what methods are available for a given object, even the node object. There are different operating modes within Chef Shell, and depending on what part and how you’re debugging you can traverse through them all to get a deeper insight to what’s going right or wrong. For an easy out, or last resort, you can require the Pry gem in any Chef code at any point by adding a line stating ‘binding.pry’. This will set a breakpoint in the code to escape at and let you analyze current code at that specific instance as well as test code that you want to add to make things work as you want.
Accessing Ruby through Puppet is more limited than Chef, as demonstrated by Ruby gems, like Pry being capable of fitting into any Chef code. Puppet provides you with a Domain Specific Language that’s processed internally before being converted to Ruby later on. The only way to process actual Ruby in Puppet is through a hack of knowing that the file templating system relies on Ruby itself, and telling Puppet that you’re doing an inline_template; essentially, templating a file, without a file. Chef provides you with libraries that are directly referenced from within Ruby code, and keeping you at the lower abstraction allows you to use tools like Pry. That is to say, all of Chef is inherently valid Ruby, and any tool you could use in any other Ruby script can be used in Chef. An entire blog could be dedicated to the features and functions of Pry itself, but suffice to say, it’s arguably one of the most valuable resources for debugging any Chef code. To note though, as with the inclusion of Pry by a simple, require ‘pry’, any gem that Chef’s Ruby is aware of can be included and the associating libraries referenced anywhere in the code.
A last and crucial difference to be aware of is execution ordering in Puppet and Chef. In Chef everything is sequential, executed in the order included and written, whereas in Puppet, order is random apart from cases where it is explicitly ordered by ‘before’ or ‘require’ statements or certain resources that carry their own implications. Chef provides the option to have resources notified with a time of ‘immediately’ which goes directly to that resource before returning to the next logical block, which is only necessary when explicitly having resources that do nothing by default or having resources that are queued to act upon certain changes occurring. When writing Puppet modules you can write out any order that you feel is readable and efficient, so long as resources that need to be executed before others explicitly state their order requirements. Chef is more top-down in that approach, and simplistic.
The relationship between objects and nodes is more apparent in Chef than it is in Puppet. Invoking Ruby from within Chef is also unlimited in power, with any gem at your request, Pry being a very useful example. Chef is more ordered and structured than its competitor, Puppet. Execution order is important and more difficult to track and manage in Puppet than in Chef, but can be specified. While different in their own ways, they have more in in common than not, they’re formidable alternatives, and either can get the job done, but whichever tool you choose, be sure to use it to its fullest.