How to Use Chef Attributes?

In the world of Chef, Chef attributes are an important part of defining cookbooks and recipes. Attributes allow you to specify certain details about a particular recipe, such as which platform it is meant for or which cookbook it depends on. Attributes can also be used to override the defaults set by a cookbook author. As we know, Chef attributes are key-value pairs associated with node or role definitions & store data about a node. In this article, I'll share examples that illustrate how these attributes come into play in real-world scenarios. I will also provide examples of how Chef attributes can be used in practice. Finally, we will take a closer look at how attributes operate and how you can use them to your advantage. So let's get started! 

Understanding Chef Attributes 

Attributes are an important part of Chef, and understanding how they work is essential for anyone looking to use this powerful tool. In a nutshell, attributes are properties that can be assigned to cookbooks, recipes, and nodes. These properties can be used to override default settings, and they can also be used to provide information about the node run that is being configured.  

Attributes can be defined in several different ways, and they can be used to specify a wide range of different settings. For example, attributes can be used to set the hostname of a node start or to specify which application should be installed on a node.  

In addition, attributes can also be used to override default settings for a cookbook or recipe. For instance, if a cookbook contains a default setting for the hostname attribute, that setting can be overridden by specifying a different hostname in the attributes list file.  

Attributes are a powerful feature of Chef, and understanding how they work can help you unleash the full potential of Chef. To get the maximum out of it, get certified with the best Chef training courses and witness the power of Chef. 

Chef Attributes Locations 

Chef uses various methods to collect information about the nodes it manages. This information is stored in set attributes, which can be defined in cookbooks, recipes, attribute files, and environments. Attributes can also be assigned to roles, which allows for more granular control over what information is available to Chef client runs.  

All of these methods have their advantages and disadvantages, and the best way to store attributes depends on the needs of the Chef client and the resources that are being managed.  

1. Attribute list files are a good choice for storing static values that do not change often. They are easy to create and maintain, and they can be versioned using tools like Git. However, attribute files can become large and unwieldy if they are not carefully organized.  
2. Recipes are excellent for storing dynamic values that change frequently. It is easier to manage than attribute files, and you can generate attribute values in real-time. It may be more difficult to maintain recipes than attribute files, as they can become complex quickly.  
3. Managing server configuration at scale is made easier with roles. Grouping similar nodes together allow you to apply the same configuration settings to all at once. It is also possible to override settings in recipes and cookbooks using roles. If roles are not well organized, they can be hard to manage and require more maintenance than other methods of storing attributes.  
4. An environment is a great tool for managing the different stages of a server's life cycle. The development environment, for example, could allow changes to be made without disrupting production systems. Environments can also control what version of a cookbook is used on a node start. While environments can be useful for storing attributes, they can be cumbersome to manage if they are not organized well. 

The best way to store set attributes in Chef depends on the needs of the Chef-client and the resources being managed. In general, attribute files are a good choice for static values that do not often change, while recipes are a good choice for dynamic values that change often. Roles are a good choice for managing server configuration at scale, and environments are a good choice for managing different stages of a server's life cycle. 

Types of Chef Attributes  

As a Chef, you'll need to be familiar with the different attribute types that can be used to configure a node run. There are six attribute types that can be assigned to a Chef cookbook: default, automatic, normal, force_default, override, force_override. Each type has its own purpose and use case.  

1. Default

A default attribute is an attribute that does not have a value set on the node. If a default attribute is not set in the default attribute file, the Chef-client will use a nil value for the attribute. You can override the default attributes list just like any other attribute, which can also be set in the default attribute file. 

2. Automatic

An automatic attribute is set by the Chef client node itself during the Chef-client run. These server attributes are typically set based on information gathered from the node, such as the operating system type or platform. Automatic attributes can be overridden like any other attribute, but they cannot be set in the default attribute file. 

3. Normal

This is the most common type of attributes list and is typically used when you want to set a specific value for an attribute on a node start. The value for a normal attribute can be set in the default attribute file, or it can be overridden on a per-node basis. 

4. Force default

The value for this attributes list is always taken from the default attribute file. If the force_default attribute is set on a node, any other values set for that node are ignored. This can be useful if you want to ensure that all nodes in your environment have the same value for an attribute. 

5. Override  

An override attribute will take precedence over any other values that have been set for an attribute, including the default value. This type of attribute is often used when you need to quickly change the value of an attribute on a node run without having to edit the default attribute file. 

6. Force override

A force_override attributes list overrides any other attribute values, whether they are default values or override values. This type of attribute should be used sparingly, as it can make it difficult to track down the source of an attribute value. 

As a Chef, you need to be aware of the different attribute types and how they can be used to configure a node run. By understanding the strengths and weaknesses of each type of attribute, you'll be able to make the best decision for your needs. 

The Sources of Chef Attributes

As mentioned in the previous section, Chef attributes list can come from a variety of locations. Here is in-depth analysis of the sources of Chef attributes.

Chef Attribute Sources in Attribute files 

Attribute files are associated with Chef cookbooks and are collected during compile time. They contain attribute values specific to a cookbook, and can be used to override the default values set in a recipe.   

An attribute file containing an object node is evaluated when a cookbook is run against it. Take a look. 

• In an attribute file called default.rb in apache2's cookbook, the following set attributes are listed:

default['apache']['dir']          = '/etc/apache2' 
default['apache']['listen_ports'] = [ '80','443' ]

• An attribute value can be set on a node with the help of node methods. 

node.default['apache']['dir']          = '/etc/apache2' 
node.default['apache']['listen_ports'] = [ '80','443' ]

• Default attribute in /attributes/default.rb

default['apache']['dir'] = '/etc/apache2'

• Assign a normal attribute to a cookbook

set['apache']['dir'] = '/etc/apache2' 
normal['apache']['dir'] = '/etc/apache2'  #set is an alias of normal.

• Override the attribute in /attributes/default.rb

override['apache']['dir'] = '/etc/apache2'

Chef Attribute Sources in Recipes 

Recipes are also associated with Chef cookbooks, and the attributes list specified in them might be collected during run time as well. This is because recipes can contain conditional statements that determine whether or not an attribute should be included.  

Recipe always requires setting node attributes. The Chef client supports specifying attributes at the node level. There are node start attributes associated with those nodes. In order to use an attribute name, you must precede it with node. Read below. 

• Default attribute in the object node in the recipe

ode.default['apache']['dir'] = '/etc/apache2'

• Normal attribute set in the recipe

node.normal['apache']['dir'] = '/etc/apache2'

• Override attribute in the node object

node.override['apache']['dir'] = '/etc/apache2'

Chef Attribute Sources in Environments 

Attributes list can also be set at the environment level. This is useful if you want to specify different values for the same attribute across multiple environments (e.g. development, staging, production, etc.).

• Default attribute in the /environments/environment_name.rb

default_attributes({ 'apache' => {'dir' => '/etc/apache2'}})

• Override attribute in the /environments/environment_name.rb

override_attributes({ 'apache' => {'dir' => '/etc/apache2'}})

• Default attribute & Override attribute in the Ruby file of the Chef environment

name 'dev' 
description 'The development environment' 
cookbook_versions  'couchdb' => '= 11.0.0' 
default_attributes 'apache2' => { 'listen_ports' => [ '80', '443' ] }

• Default attribute and Override attribute in JSON file of environment

{ 
  "name": "dev", 
  "default_attributes": { 
    "apache2": { 
      "listen_ports": [ 
        "80", 
        "443" 
      ] 
    } 
  }, 
  "json_class": "Chef::Environment", 
  "description": "", 
  "cookbook_versions": { 
    "couchdb": "= 11.0.0" 
  }, 
  "Chef_type": "environment" 
}

• Default attribute and Override attribute in JSON file of environment

{ 
  "name": "development", 
  "description": "The master development branch", 
  "cookbook_versions": { 
    "nginx": "<= 1.1.0", 
    "apt": "= 0.0.1" 
  }, 
  "json_class": "Chef:Environment", 
  "Chef_type": "environment", 
  "default_attributes": { 
  }, 
  "override_attributes": { 
    "nginx": { 
      "listen": [ 
        "80", 
        "443" 
      ] 
    }, 
    "mysql": { 
      "root_pass": "root" 
    } 
  } 
}

Sources of Chef attribute in Roles   

Finally, roles are a way of grouping nodes together based on their function. The server attributes can be specified in roles, and those values will be applied to all of the nodes that are assigned to that role. 

• Default attribute in the /roles/role_name.rb

default_attributes({ 'apache' => {'dir' => '/etc/apache2'}})

• Override attribute in the /roles/role_name.rb

override_attributes({ 'apache' => {'dir' => '/etc/apache2'}})

• Default attribute & Override attribute in the Ruby file of role

name "webserver" 
description "The base role for systems that serve HTTP traffic" 
run_list "recipe[apache2]", "recipe[apache2::mod_ssl]", "role[monitor]" 
env_run_lists "prod" => ["recipe[apache2]"], "staging" => ["recipe[apache2::staging]"], "_default" => [] 
default_attributes "apache2" => { "listen_ports" => [ "80", "443" ] } 
override_attributes "apache2" => { "max_children" => "50" }

• Default attribute and Override attribute in Ruby file of role

name "web_server" 
description "A role to configure our front-line web servers" 
run_list "recipe[apt]", "recipe[nginx]" 
env_run_lists "production" => ["recipe[nginx::config_prod]"], "testing" => ["recipe[nginx::config_test]"] 
default_attributes "nginx" => { "log_location" => "/var/log/nginx.log" } 
override_attributes "nginx" => { "gzip" => "on" }

• Default attribute and Override attribute in JSON file of role

{ 
  "name": "webserver", 
  "Chef_type": "role", 
  "json_class": "Chef::Role", 
  "default_attributes": { 
    "apache2": { 
      "listen_ports": [ 
        "80", 
        "443" 
      ] 
    } 
  }, 
  "description": "The base role for systems that serve HTTP traffic", 
  "run_list": [ 
    "recipe[apache2]", 
    "recipe[apache2::mod_ssl]", 
    "role[monitor]" 
  ], 
  "env_run_lists" : { 
    "production" : [], 
    "preprod" : [], 
    "dev": [ 
      "role[base]", 
      "recipe[apache]", 
      "recipe[apache::copy_dev_configs]", 
    ], 
    "test": [ 
      "role[base]", 
      "recipe[apache]" 
    ] 
  }, 
  "override_attributes": { 
    "apache2": { 
      "max_children": "50" 
    } 
  } 
}

• Default attribute & Override attribute in the JSON file of role

{ 
  "name": "web_server", 
  "description": "A role to configure our front-line web servers", 
  "json_class": "Chef::Role", 
  "default_attributes": { 
    "nginx": { 
      "log_location": "/var/log/nginx.log" 
    } 
  }, 
  "override_attributes": { 
    "nginx": { 
      "gzip": "on" 
    } 
  }, 
  "Chef_type": "role", 
  "run_list": [ 
    "recipe[apt]", 
    "recipe[nginx]" 
  ], 
  "env_run_lists": { 
    "production": [ 
      "recipe[nginx::config_prod]" 
    ], 
    "testing": [ 
      "recipe[nginx::config_test]" 
    ] 
  } 
}

How Do Chef-clients Work with Chef Attributes? 

Attributes are a key part of Chef recipes. They allow you to customize the behavior of your recipes for different situations. For example, you might have a recipe that installs a particular software package. But you might want to install a different version of that software on your development systems than on your production systems. Attributes let you do that. 

Attributes list are defined in Chef cookbooks, and they can be used in any recipe in that cookbook. Attributes can also be used in other cookbooks, if they are defined in a role or an environment. Chef-clients look for set attributes in the following order: 

1. Role-specific server attributes (if the Chef client is run using a role) 
2. Environment-specific attributes (if the Chef-client is run using an environment)  
3. Cookbook attribute files  
4. Default attributes (attributes defined in a "default" attribute file)  
5. Attributes list defined in Ohai (automatically detected system information)  

The precedence order lets you override default values with values that are more specific to a particular situation. For example, you can set a default value for a particular attribute, and then override that value with a role-specific or environment-specific value as needed. This flexibility is one of the things that makes Chef so powerful. Moreover, you can also look to increase your learning curve along with Chef by getting in line with the online DevOps training course and get equipped with other core tools of DevOps.

How Do Chef-clients Work with Different Kinds of Attributes? 

There are two main attribute types that a Chef-client can work with: default and override. Default attributes are defined in a cookbook and are applied to a node start every time that cookbook is run. Override attributes are defined by the user and take precedence over any defaults. A Chef-client will always look for an override attribute first, and if one is not found, it will then look for a default attribute.

 

Attributes list can be declared in either the cookbook's recipe or in an associated attribute file. Attribute files are stored in the cookbook's /attributes directory and have a .rb extension. For example, if a cookbook has a default attribute named "foo" with a value of "bar", that attribute could be overridden by adding the following line to the node's override file: "node['foo'] = 'baz'" This would cause the Chef-client to use the value "baz" for the "foo" attribute when convergence occurs.  

When an override attribute is set on a node run, that value is persisted and will be used again the next time Chef-client runs. In order for an override attribute to be removed, it must be explicitly set to "nil". Once an override attribute has been removed, the Chef-client will revert to using the default value for that attribute. Attributes can also be declared in environment files.  

Environment files are stored in the /environments directory and have a .rb extension. By storing set attributes in environment files, it is possible to group nodes together that share common values for those attributes.  

For example, if there were two environments named "production" and "staging", each with its own overrides for certain attributes, all of the nodes in the "production" environment would use those overridden values while all of the nodes in the "staging" environment would use different values. This provides a way to easily change what values are used for multiple nodes at once.  

Finally, attributes can also be declared in data bags. Data bags are collections of JSON data that are stored in specially named directories within the /data_bags directory. Data bags can store data that is specific to a particular node or can be used to define data that is shared across multiple nodes.  

Attributes declared in data bags take precedence over any other type of attribute (including other data bag values) and are typically used to store sensitive information such as passwords or API keys.  When using data bags to store attributes, it is important to ensure that they are properly protected so that only authorized users can access them.  

The Chef node client will automatically decrypt any encrypted data bags that it uses during convergence, but only if it has been provided with the correct secret key. Encrypted data bags are typically stored in version control systems such as Git so that they can be easily shared between developers while still keeping their contents secure. 

Example of Chef Attribute Precedence over Other Attributes 

In the Chef world, attribute precedence is determined by a cookbook's attribute file, not by the order in which the cookbooks are loaded. Chef cookbooks can have default set attributes, which are applied to nodes that don't have a value for that attribute set yet.

And finally, attributes list can be set in environments, roles, and via Ohai at the time of node convergence. Attributes defined in any of these places will override a cookbook's default attribute values. It's important to understand how all these attribute layers interact to properly manage your Chef update and infrastructure.  

node['platform']  

The node['platform'] refers to the platform on which a given node will be making requests. This attribute is responsible for returning the correct platform information for a given node and has very high precedence.  

This means that it will always override any other platform-related attribute and return the correct information for the node's platform. As a result, this attribute is essential for ensuring that a node makes requests to the correct platform. 

node['platform_version'] 

The node['platform_version'] is the version of the platform that the node is running on. This attribute is used by Chef to determine which platform specific cookbooks to use. For example, if a node is running on Ubuntu 14.04, then the 'platform_version' attribute would be set to '14.04'.  

Cookbooks that are specific to Ubuntu 14.04 would then be used instead of cookbooks that are generic to all versions of Ubuntu. The 'platform_version' attribute has a higher precedence than some attributes, so it will always be used first when choosing which cookbooks to use. 

node['ipaddress'] 

The node['ipaddress'] attribute is a string that contains the IP address of the node. The attribute is set by the ohai plugin and is used by the Chef-client to populate the object node attributes. The attribute is also used by recipes to resolve hostnames and by the search engine to index nodes. 

node['macaddress']   

The node['macaddress'] attribute is used to set the mac address for a node run. This attribute has a higher precedence than any other mac address attributes, including the 'normal' and 'default' attributes.  

This means that if you set the node['macaddress'] attribute, it will override any other mac address attributes that have been set for the node. This can be useful if you want to ensure that a particular mac address is used for a node start , regardless of other settings. 

node['fqdn']   

The node['fqdn'] attribute specifies the fully qualified domain name of a node. This attribute is used by various Chef cookbooks to generate platform-specific URLs and email addresses. The value of this attribute is determined by first checking for the presence of a 'domain' attribute, and then using the node's hostname if no 'domain' attribute is found.  

As a result, the 'fqdn' attribute has a higher precedence than the 'domain' attribute when determining the fully qualified domain name of a node. 

node['hostname']

The node['hostname'] is an automatic attribute generated by Chef when a node run is first created. It contains the hostname of the node. Automatic attributes list have the lowest precedence of all attribute types, so if there is an attribute with the same name that is defined in another location (such as a default or override attributes file), that attribute will take precedence over the automatic attribute. 

node['domain']

The node['domain'] refers to an attribute that takes precedence over other attributes. This means that when multiple attributes are assigned to a node, the node will use the value of the domain attribute first. This can be useful when you want to override the values of other attributes for a particular node.  

You can also use the 'domain' attribute to specify a default value for an attribute.Finally, it is important to note that setting the 'domain' attribute does not change the precedence of other attributes; it only affects how the node resolves conflicts between multiple values for an attribute. 

node['recipes']

The node['recipes'] attribute is an array of recipes that should be applied to the node. The recipes in the array will be applied in the order they are specified. If a recipe appears in multiple places in the array, it will be applied multiple times. This can be useful for ensuring that a particular recipe is always run after another recipe.  

For example, if you have a recipe that installs a package and another recipe that configures the package, you can ensure that the configure recipe is always run after the install recipe by adding both recipes to the node['recipes'] array. 

node['roles']  

The node['roles'] is an attribute that Chef uses to manage role-based configuration data. This attribute has a higher precedence than other attributes, which means that it will take precedence over other attributes when applying configurations. This ensures that role-based configurations are applied correctly and consistently across all nodes in a Chef server.  

Node['roles'] is also used to determine the order in which roles are applied to nodes. This attribute is typically set by a Chef client run or a manual Chef-apply. When a node run does not have a 'roles' attribute, the default behavior is for the Chef client to apply all roles to the node in the order they are listed in the run list. 

node['ohai_time']  

At the top of the hierarchy is the node['ohai_time'] attribute, which represents the last time Ohai was run on the node. This value is used by Chef to determine if any attribute values have changed since the last run, and if so, which values should be applied.  

Other attributes list further down the hierarchy include cookbook defaults, role defaults, environment defaults, and override attributes. In general, values closer to the top of the hierarchy will take precedence over values lower down, but there are some exceptions to this rule.  

How to Use Chef Attributes in Chef Recipe & Chef Templates? 

Attributes are an important part of Chef recipes and templates. By default, attributes are set to nil, which means they have no value. In order to use them, you must first set a value for the attribute. We will help you get through the use of attributes in Chef Recipe and Templates with examples below. 

Chef Recipe Example

node.default['webserver']['time']= '2PM' 
myname = node['webserver']['clientwork'] 
file "/opt/marico.txt" do 
 content "Come to Marico- From #{name}" 
end 
file "/opt/marico.txt" do 
 content "Come to Marico- #{node['webserver']['time']}" 
end 
Chef Template Example H3 
Step 1: Adding Template 
sahil@laptop:~/Chef-repo $ subl cookbooks/<Cookbook Name>/recipes/default.rb   
template '/tmp/message' do  
   source 'Test.erb'  
   variables(  
      hi: 'Testing',  
      world: 'David',  
      from: node['fqdn']  
   )  
end

Step 2: Adding ERB Template file

sahil@laptop:~/Chef-repo $ subl cookbooks/<Cookbook Name>/templates/default/test.erb  
<%- 2.times do %>  
<%= @hi %>, <%= @world %> from <%= @from %>!  
<%- end %>

Step 3: Uploading the modified cookbook to the Chef server

sahil@laptop:~/Chef-repo $ knife cookbook upload <Cookbook Name> 
Uploading my_cookbook [0.1.0] 
Step 4: Running the Chef Client node 
user@server:~$ sudo cat /tmp/message 
Hello, David from Wipro.vm! 
Hello, David from Wipro.vm!

For more information about attributes, check out KnowledgeHut’s Chef Training Courses now.

Conclusion

Now we know, Chef attributes provide a way to set and modify the behavior of your Chef recipes. They can be used as part of recipe or role definitions. You can use them to define default values for settings, control run-time behavior, or specify dependencies between recipes. 

By understanding how Chef attributes work, you can create more robust and maintainable recipes that are easier to read and understand. We’ve looked at some examples of how Chef attributes can be used to improve your Chef recipes. I'm curious to hear about specific situations where others have found Chef attributes particularly useful. Feel free to share your insights in the comments below!