by Brandon Knitter | Technical Consultant at Taos The software industry has seen a lot of change over the past many years. There was the mainframe. At some point we moved to client-server. The web gave birth to the three-tier architecture. Eventually there was SOA, and CORBA reared it’s head like a dyslexic snake. There […]
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.
For anyone coming from a Puppet background, one of the first things you’ll learn about Chef is that it emphasizes programming rather than Puppet’s administrative mindset. In other words, mastering Chef takes a commitment to thinking differently. You’ll want to become intimately familiar, first and foremost, with the concept of Ohai and the Chef node object to advance as quickly as possible, and you’ll need to adjust to a series of quirks. Often, your problems will manifest themselves as programmatic rather than administrative, but troubleshooting them will always come down to a matter of using the ingenuity and accumulation of knowledge you already have. Take everything you remember from Puppet, and use it as an overview of concepts to apply to Chef, as a general rule of thumb. Most importantly, never forget, unlike in Puppet where nearly everything is processed on the server and sent to the client to apply locally, EVERYTHING in Chef is client side.