Cookbook best practices

Question

In chef training, I see conflicting patterns for cookbook wrappers. For instance.

Some cookbooks use default.rb, while others use customize.rb for overrides.

attributes/default.rb attributes/customize.rb 

What is the practice?

In addition, some cookbook wrappers have options such as those in the recipes / default.rb file:

 normal['foo']['bar'] = 42 

While others have

 default['foo']['bar'] = 42 

And some have

 node.set['foo']['bar'] = 42 

In addition, some cookbooks use characters and other strings.

 ['foo']['bar'] [:foo][:bar] 

Which style should I use?

Refresh

It seems that the chef has issued an official style guide that addresses at least part of the issue (for example, the character against the lines). https://docs.chef.io/ruby.html#

Answer 1

I have not seen any official best practice regarding how to redefine attributes in wrapper cookbooks, I think you need to choose a style and as long as all your cookbooks match your organization, you should be good. What follows my opinions.

---

Attribute File

First, we used the attribute file separation style similar to that described in this format attributes/customize.rb . However, we found it much easier to just save all the attributes in attributes/default.rb , especially since our attributes remain under 50 lines of code.

Override Priority

We always use the lowest attribute priority when redefining attributes in our cookie wrapper book. We adhere to default whenever possible, because the order of priority dictates your cookbook. default wins over wrapped cookbooks by default .

Attribute Access Style

Most cookbooks you see there use the string access format.

 default['foo']['bar'] = 42 

In fact, there is a power rule , which specifically prevents the use of access to characters. Foodcritic also recommends using a consistent style to access attributes . If you're deciding on a style, keep in mind that the community has pretty much defined the string access format.

However, there is another way. The attributes in the chef are not Hash , they are actually Mash . Mash supports access to attributes as methods, therefore:

 default.foo.bar = 42 

We prefer this syntax because it is more compact.

However, be careful, as Tejay Cardon points out , Chef did this with method_missing so that you might run into problems if the attribute name matches the name of the current (or future) method of the node object. We are the foreword to all of our cookbooks with our name, so clashes are unlikely, but when we redefine the community cookbooks, we may run into problems. Fortunately, testing should catch any such omissions.

Warning note

Overriding attributes in a heap wrapper book will not work in unexpected ways, especially when using string interpolation. This is very well explained in this blog post . The main thing is if the cookbook defines attributes as:

 default['version'] = '1.0' default['url'] = "http://example.com/#{node['version']}.zip" 

And in your wrapper cookbook, you override version :

 default['version'] = '2.0' 

default['url'] will still be http://example.com/1.0.zip , not http://example.com/2.0.zip , as you would expect. This is because the url attribute is interpolated until your redefinition occurs. The blog post goes deep and offers a potential solution.

Wrap up

At the end of the day, there are several ways to do something at the Chef, and the community is still ripening. There are some recommendations for writing reusable cookbooks, etc., but the practice is still evolving.

The best you can do is try different styles and find out which one is best for you and your team. After you decide on a style, I would suggest writing a style guide (I used this Angular style guide as inspiration ). You can also apply style guides using custom food rules . We have had success with this approach.

Answer 2

There are very few ways of excellence there, unfortunately, but there are a few issues that need to be taken care of.

Attribute loading order

Attribute files are loaded (Executed) in a very specific, albeit not very clear, order.

• The necessary cookbooks are resolved based on the list and metadata for each cookbook listed on the list and all dependencies.
• After the list of collected cookbooks has been compiled, they are arranged in lexicographic format.
• Attribute files from each cookbook are then ordered lexicographically.
• Execution begins with a list, however, if an include_attribute statement is encountered, this attribute file will be immediately executed (and removed from the list so that it does not run a second time.)

This is important because if the same attribute is set at the same level, i.e. default more than one attribute file, then the last executable will determine which value wins. __ Always always include the attribute_attribute file from your cookie library at the top of the attribute file for your shell wrapper. Then set the attributes to the default level (so that they can be more easily overridden elsewhere).

One of these things is not like the rest.

Normal attributes (node.set or node.normal) are a funny beast. They persist between passing the chef. Therefore, when you set a normal attribute, it will stick until you delete or change it. Sometimes it’s good, for example, uuid that you want to remember, but sometimes it is an unexpected side effect.

Style

characters and strings and methods oh my.

There is much debate about the access styles of node.attribute , node[:attribute] and node['attribute'] . Just read on foodcritic 001 if you want to see both sides of the coin. In my opinion, node['attribute'] won the majority of culinary community developers, but this is a pretty subtle majority. node.attribute frowned almost universally because it could have evil side effects. Ultimately, you use what you like best, but if your cookbooks in the library are reasonably consistent, I suggest you follow their agreement.

Where to override

Personally, I try to never set an attribute outside the attribute file. This too often leads to headaches. It’s just easier to store all attributes in attribute files, so you can easily track them. But there are times when you either cannot do this in the attribute file, or it just makes sense in the recipe. As with most program rules, you just need to weigh the sequence with what seems right.