HomeBlogDevOpsHow to Use Chef Attributes?

How to Use Chef Attributes?

18th Jan, 2024
view count loader
Read it in
13 Mins
In this article
    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.

    Attribute Sources

    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 attributesThe 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": [ 
      "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": [ 
        "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": [ 
      "description": "The base role for systems that serve HTTP traffic", 
      "run_list": [ 
      "env_run_lists" : { 
        "production" : [], 
        "preprod" : [], 
        "dev": [ 
        "test": [ 
      "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": [ 
      "env_run_lists": { 
        "production": [ 
        "testing": [ 

    How DChef-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 DChef-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.

    Setting attributes in attribute files

    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 runthat 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.

    Attribute precedence

    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.  


    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. 


    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. 


    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. 


    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. 


    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. 


    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. 


    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. 


    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. 


    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. 


    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}" 
    file "/opt/marico.txt" do 
     content "Come to Marico- #{node['webserver']['time']}" 
    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'  
          hi: 'Testing',  
          world: 'David',  
          from: node['fqdn']  

    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. 


    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!

    Frequently Asked Questions (FAQs)

    1What are attributes in Chef?

    Attributes are one of the core concepts in Chef. They are used to describe node-specific data that can be used by recipes and/or templates. Attributes can be defined in a cookbook (via an attributes file or a recipe), in an environment, or in a role. Attributes can also be set directly on a node, using the node's "normal" attribute declarations; these will override any other attribute values set via cookbooks or roles. 

    Attributes have three primary purposes in Chef: 

    • To override the default values set by a recipe (or Template).  
    • To make information available to Recipes and Templates.  
    • To provide information about a node that can be used for search.  

    Attributes are very flexible - they can be used for any purpose that fits into one of the three categories above.  

    2How do I create an attribute file in Chef?

    In order to create an attribute file, you will first need to create a new file with a ".rb" extension. You can do this using any text editor. Once you have created the file, you will need to add the following code:  

    default["cookbook_name"]["attribute_name"] = "attribute_value"  

    replacing "cookbook_name" with the name of the cookbook that contains the recipe you wish to override and "attribute_name" with the name of the variable you wish to override. The "attribute_value" will be used to set the value of the variable. Once you have added the desired code to the file, save it and then upload it to your Chef server. 

    3How do Chefs create the environment?

    In order to create the ideal environment for a Chef-managed server, the attribute files for each node must first be populated with the correct values. These values are then used by the Chef-client to generate the required configuration for each node. The attributes can be modified at any time, and the changes will be applied when the Chef-client next runs. 

    Once the attribute files have been correctly configured, the next step is to create the Chef role. A role defines a set of tasks that need to be carried out on a node, and it can be assigned to one or more nodes.  

    Once roles have been created, they need to be added to the run list for each node. The run list is a queue of tasks working on a node run, and it is processed by the Chef-client when it runs. By correctly configuring attributes and roles, Chefs can easily maintain a consistent environment across all of their nodes. This helps to prevent configuration drift, which can lead to instability and errors. 


    Abhresh Sugandhi


    Abhresh is specialized as a corporate trainer, He has a decade of experience in technical training blended with virtual webinars and instructor-led session created courses, tutorials, and articles for organizations. He is also the founder of Nikasio.com, which offers multiple services in technical training, project consulting, content development, etc.

    Share This Article
    Ready to Master the Skills that Drive Your Career?

    Avail your free 1:1 mentorship session.

    Your Message (Optional)

    Upcoming DevOps Batches & Dates

    NameDateFeeKnow more
    Course advisor icon
    Course Advisor
    Whatsapp/Chat icon