Reader small image

You're reading from  Mastering Chef

Product typeBook
Published inJun 2015
Reading LevelIntermediate
Publisher
ISBN-139781783981564
Edition1st Edition
Languages
Tools
Right arrow
Author (1)
Mayank Joshi
Mayank Joshi
author image
Mayank Joshi

Mayank Joshi works for Indix as a DevOps engineer. He has worn many hats during his 10-year long career. He has been a developer, a systems analyst, a systems administrator, a software consultant, and for the past 6 years, he has been fascinated with the phenomenal growth witnessed in cloud environments and the challenges of automation associated with the hosting of the infrastructure in such environments. Prior to Indix, he worked for start-ups such as SlideShare, R&D organizations such as CDAC, and even had a stint at a highly automated chemical plant of IFFCO.
Read more about Mayank Joshi

Right arrow

Chapter 8. Attributes and Their Uses

As we've seen so far, any machine (henceforth referred to as node) can be described through Chef by means of recipes, roles, and environment that it is associated with. However, throughout all this there are a few properties associated with a node as well. A node will have properties such as name, IP address, kernel, FQDN, OS type, and so on, associated with it. All these properties help in defining a system in a more meaningful way. The more properties are associated with a node, the better the quality of its definition. Some of these properties are tightly coupled to the system—for example, OS type, kernel, IP address, and so on—while some are abstract in nature. For example, we might have different kinds of web applications in our setup, some related to finance and others perhaps related to HR. All these applications may be deployed on different machines and they all use the same underlying technology stack; hence, they all have a common role, say...

Attribute naming


This can be confusing for some people, especially those who aren't coming from the Ruby world. You looked up two different cookbooks and, in one of them, you found something like the following in the attributes file:

default[:app][:user] = "web-admin"

On the other hand, the other cookbook had something like the following:

default['app]['user'] = "web-admin"

These are two different styles of specifying the keys in a Ruby hash. In one, you are making use of symbols; in the other, you are using strings. You can choose either of these but, for the sake of sanity, try to be consistent. There are some pitfalls in using either approach and there are some inherent benefits too. For example, symbols are immutable and are allocated just once, which is a performance gain. On the other hand, they can be pretty irritating if you are trying to include stuff such as hyphens in their names. If symbols confuse you, stick with strings or vice-versa.

Note

One of the popular lint tools called Foodcritic...

Different types of attributes


Chef provides six different types of attributes, as listed in the following table:

Different sources of attributes


An attribute can be defined at multiple places and it is very important to declare an attribute at the right place with right precedence order. During a chef-client run, attributes are collected from the following different sources:

  • Nodes (collected by Ohai at the start of each chef-client run)

  • Attribute files (associated with cookbook) are collected during compile time

  • Recipes (associated with cookbook. The attributes specified in the recipes might be collected during run time as well

  • Environments

  • Roles

The life cycle of an attribute can be understood by the following sequence of steps:

  1. Developer writes attributes in the attribute file, recipe, role, or environment.

  2. The concerned code is pushed to the Chef server.

  3. During the chef-client run, Ohai collects all the automatic attributes from the node.

  4. The chef-client will pull node object from the chef-server, which will in turn bring in the normal attributes that are persistent.

  5. The chef-client will update the cookbook...

Attribute precedence


Attributes are always applied by the chef-client in the following order:

  1. The default attribute specified in a cookbook attribute file.

  2. The default attribute specified in a recipe.

  3. The default attribute specified in an environment.

  4. The default attribute specified in a role.

  5. The force_default attribute specified in a cookbook attribute file.

  6. The force_default attribute specified in a recipe.

  7. The normal attribute specified in a cookbook attribute file.

  8. The normal attribute specified in a recipe.

  9. The override attribute specified in a cookbook attribute file.

  10. The override attribute specified in a recipe.

  11. The override attribute specified in a role.

  12. The override attribute specified in an environment.

  13. The force_override attribute specified in a cookbook attribute file.

  14. The force_override attribute specified in a recipe.

  15. The automatic attribute collected during the Ohai run.

The last attribute in this list has highest precedence and it's the one that dictates the value associated with an attribute...

Attribute whitelisting


So, you've got this whole bunch of attributes that have been collected from all different sources and now a final list of attributes has been prepared by the chef-client after applying the precedence order. However, you might not want each and every attribute to persist on the Chef server and this is where we can make good use of whitelisting capabilities. We can specify a whitelist of a set of attributes that we want to be saved by a node. This whitelist can be specified in client.rb. A whitelist is a hash that specifies attributes that need to be saved.

Each attribute type has to be whitelisted separately. Each attribute type—automatic, default, normal, and override—may define whitelists by using the following settings in the client.rb file:

Attribute type

Description

default

This attribute is reset upon the start of every chef-client run and has the lowest attribute precedence. A cookbook should make the most use of the default attributes.

force_default

Say you've specified the same default attribute in role and environment along with a cookbook, and you want to ensure that the attribute in the cookbook takes precedence. In order to do so, one must make use of the force_default attribute type.

normal

A normal attribute is never reset and persists with the node object. It has higher precedence over the default attribute.

override

An override attribute has higher precedence over the default, force_default, and normal attributes. It can be defined in a recipe, role, or environment.

force_override

Similar to the force_default attribute, the force_override attribute specified in a recipe takes precedence over...

Summary


This brings us to the end of our journey in the world of attributes. We've learned about different kinds of attributes and the different sources from which attributes are collected. We've also learned about whitelisting of attributes and touched upon the use of Ohai for collection of automatic attributes. For more details about attributes, refer to http://docs.getchef.com/essentials_cookbook_attribute_files.html. In the next chapter, we'll dive deep into Ohai and its plugin ecosystem. We'll also see how to go about writing custom Ohai plugins.

lock icon
The rest of the chapter is locked
You have been reading a chapter from
Mastering Chef
Published in: Jun 2015Publisher: ISBN-13: 9781783981564
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
undefined
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $15.99/month. Cancel anytime

Author (1)

author image
Mayank Joshi

Mayank Joshi works for Indix as a DevOps engineer. He has worn many hats during his 10-year long career. He has been a developer, a systems analyst, a systems administrator, a software consultant, and for the past 6 years, he has been fascinated with the phenomenal growth witnessed in cloud environments and the challenges of automation associated with the hosting of the infrastructure in such environments. Prior to Indix, he worked for start-ups such as SlideShare, R&D organizations such as CDAC, and even had a stint at a highly automated chemical plant of IFFCO.
Read more about Mayank Joshi

Setting

Description

automatic_attribute_whitelist

This can be used to specify a hash that whitelists the automatic attributes and prevents non-whitelisted attributes from being saved. If a hash is empty, no attribute is saved...