Note: Please go to to access the current RightScale documentation set. Also, feel free to Chat with us!
Home > Guides > Chef Cookbooks Developer Guide > End User > Getting Started > Chef Basics

Chef Basics

What is Chef?

RightScale supports server configuration using the open-source integration framework called Chef. Chef allows an administrator to automate many of the more difficult and mundane management tasks that are normally accomplished through manual commands and custom scripting.

RightScale is an active contributor to the Chef community and has developed many Chef resources and providers. In fact, you can view our own cookbook repositories for yourself directly on GitHub.  ( All of the new ServerTemplates published by RightScale use Chef cookbooks and recipes because it helps us provide a more efficient configuration management solution for launching servers in a variety of cloud infrastructures.  

RightScale's Chef cookbooks are constantly under active development by our engineering teams. We encourage everyone to use our Chef resources, customize them, and make pull requests back to us so that we can incorporate your improvements and make them available to all RightScale users in the Chef community. 

Note: Chef support was first introduced in our September 2009 release, and we have been actively developing Chef cookbooks and recipes ever since.

If you are new to Chef, it's strongly recommended that you read through Opscode's Getting Started with Chef documentation.

Benefits of Chef

There are several benefits of using Chef for configuring servers in the cloud.  Some of the key benefits are listed below.

  • Abstraction - Chef provides an elegant way of abstracting the system-level details from server configuration tasks. When used properly, you'll  have a single code base that supports multiple system configurations without having to generate a lot of the underlying code yourself. Configuration settings are organized into modular components that are easier to customize and reuse across different types of systems. (e.g. CentOS and Ubuntu)
  • Portability - Chef is a cloud-agnostic language.
    • System Configuration - Run Chef recipes on any operating system, platform, or system architecture
    • MultiCloud - Run a Chef recipe on any type of public/private cloud server
    • Instance Size - Run a Chef recipe on any instance regardless of the instance size
  • Create Stateful Servers - Chef is idempotent.
    • i·dem·po·tent [ahy-duhm-poht-nt, id-uhm-] - def. Unchanged when multiplied against itself (in mathematics).
    • Idempotent essentially means that actions on a specified Chef Resource (e.g. server) will result in the (same) desired state. (i.e. You get the same results every time.) For example, when you reboot a server, there is no need to re-install software that is already installed. In fact, installing it again could produce undesired results. Scripts are only executed again if it's necessary to reconfigure the server back to its desired configuration. For example, if MySQL is already installed on the instance and it's rebooted, Chef will recognize that MySQL is already installed (and in its intended state) so it will not try and reinstall MySQL again. Similarly, if a user uses SSH to gain remote access to an instance and either accidentally or maliciously changes a server's configuration, scripts will be re-executed to change the server's configuration back to it's intended state.
  • Leverage Community Contributions - Leverage cookbooks and recipes published by other users in the Chef community, including RightScale. Instead of writing all of your Chef code from scratch, you can reuse or modify existing cookbooks.
  • Independent Source Control - Unlike RightScripts which can only be edited and maintained inside the RightScale dashboard, you can maintain the source code of your Chef cookbook repositories outside of RightScale and maintain a more ideal software development environment where you can check in/out changes, create branches, etc. By using a true source control management system (e.g. GitHub or SVN) for hosting your Chef codebase, you'll also have more granular control of user permissions and version control.
  • Better Organization of Scripts - If you have experience developing RightScripts you know that it can be very difficult to find a particular RightScript because there are no built-in sorting categories. As a result, unique naming conventions are often used to organize and group your RightScripts, which can be very difficult to implement and maintain, especially if multiple developers are contributing to the same code base.


To have a more successful experience using Chef, it's recommended that you have a basic understanding and some experience using the following technologies.


  • GitHub - GitHub is the primary source control management system that is used by the Chef community. RightScale hosts all of its Chef cookbook repositories on GitHub. (  If you plan to develop your own custom Chef cookbooks and recipes, it will be easier for you to use them in the RightScale platform if you store them in your own software repositories on GitHub.
  • RightScale - Any prior experience with the RightScale platform will help you more quickly understand how to use RightScale's ServerTemplates that use Chef cookbooks and recipes instead of RightScripts.  


Chef FAQs

Can I use RightScripts with a Chef-based ServerTemplate that uses cookbooks and recipes?

Yes. Even though the latest ServerTemplates published by RightScale are primarily developed using Chef cookbooks and recipes, you can still use RightScripts with Chef-based ServerTemplates. In fact, it might be easier to use a simple RightScript than a Chef recipe in some use cases.

Do I have to become a Chef expert to use Chef-based ServerTemplates?

No. Of course, a solid understanding of Chef will only make Chef-based ServerTemplates easier to understand and use. However, any user with some scripting experience should be able to use Chef cookbooks and recipes in the context of a ServerTemplate. It's neither expected nor assumed that you will ever need to create your own library of Chef cookbooks and recipes. However, with very little Chef experience, you should be able to use a pre-built Chef-based ServerTemplate as-is or be able to reuse and slightly modify existing cookbooks to satisfy your own needs.

Will RightScale eventually stop supporting RightScripts?

No. RightScripts will always be supported by RightScale. In fact, you may find it easier to accomplish a task with a simple bash RightScript than creating a new Chef cookbook and recipe.

Which version of Chef does RightScale support?

The supported Chef version depends on the version of RightLink that is installed on the machine image. The RightLink version is typically displayed in the name of the RightImage. Typically, the RightImage and the installed RightLink version are the same.

  • RightImage v5.8  (Chef v0.10.10)  Note: The v12.11 LTS/Infinity ServerTemplates use v5.8 RightImages.
  • RightImage v5.7  (Chef v0.9.14.3)
  • RightImage v5.5, v5.6  (Chef v0.8.16)

Can I use my existing Chef cookbooks with RightScale?

Yes. If you have already developed your own library of Chef cookbooks and recipes, you can definitely use them in the RightScale system. Although, you might not be able to use them as-is, with a few minor modifications to your existing cookbooks you'll be able to create custom ServerTemplates that use recipes from your own cookbooks. In order to leverage your existing cookbooks you must meet the following requirements.

  • The ServerTemplate must use one of the newer RightImages (preferably v5.7 and newer) or use a custom image that includes RightLink v5.7 or newer 
  • Each cookbook must have properly formatted Chef Metadata. See Chef Metadata

How do I build a Lightweight Resource Provider (LWRP)?

Although you have access to many Chef Resources if you are using an instance that's launched with a v5.7 RightImage and above, as well as to existing LWRPs that are available in RightScale's own cookbook repositories (e.g. 'sys_firewall' and 'block_device'), you may want to create your own LWRP to abstract a repeated pattern of behavior that's currently undefined or inaccessible. To learn how, see Chef Fundamentals LWRP Introduction.


Glossary of Chef Concepts

Below are some descriptions of the common Chef terms and concepts.

Note: Some traditional Chef features are not supported in RightScale's cloud management platform.

More detailed descriptions of each Chef component can be found on Opscode's documentation wiki (


A software repository is a storage location from which software packages, scripts, etc. can be retrieved. In the Chef community, GitHub is the most commonly used source control management (SCM) system for storing cookbooks. In Chef, a software repository is specifically used to store your Chef cookbooks, resources, and providers and is commonly referred to as a cookbook repository or cookbook repo. And if you are using GitHub, you also might refer to a repository as a GitHub repository or GitHub repo.  


A Chef cookbook repository consists of one or more cookbooks, where each cookbook applies to a specific topic. For example, you may have a cookbook for databases, applications, setup utilities, etc. Each cookbook contains the Chef components (recipes, resources, attributes, libraries, cookbook files, templates, and metadata) that are needed to configure a server.


Recipes are located inside of a Chef cookbook. A recipe is a script written in Chef's domain-specific language (DSL) that will be executed on a running instance. A ServerTemplate consists of scripts that are either RightScripts or Chef recipes. Similar to RightScripts, Chef recipes support variable substitution where inputs (called Chef attributes) allow a user to define values that will be used when the script is executed. A recipe can also contain Chef resources that are located in another cookbook of a referenced repository. 


Attributes are displayed as user-configurable inputs in the RightScale dashboard. Attributes are most commonly used in Chef recipes. In order for attributes to be displayed in the dashboard, they must be properly documented in the Chef metadata (metadata.rb). 


A Chef resource is usually a cross platform abstraction of the thing you're configuring on the host. For example, packages may be installed via apt, yum, or the BSD ports and packages systems, but the package resource abstracts these differences away so that you could use the same recipe to install a package correctly on a variety of systems. Chef's resources are mostly just containers for data with some basic validation functionality. Resources are commonly used in Chef recipes. 


A template is a file written in a markup language that allows one to dynamically generate a file's final content based on variables or more complex logic. Templates are commonly used to manage configuration files with Chef.


Definitions allow you to create new Resources by stringing together existing resources. 


A provider consists of the platform-specific code that will be executed on a server based on its underlying system architecture. Whereas a Chef resource describes the desired task (e.g. install a package), it's the related Chef provider that actually provides the underlying code that's executed to accomplish the task. Instead of creating a single bash script that contains each supported option through a long list of If/Else statements, you can create a single Chef recipe that leverages existing Chef resources and providers that accomplish the same task in a more efficient and scalable manner.


Ohai is a utility that inspects a running instance and discovers relevant system-specific data.


Knife is a command line interface utility that can be used to create and modify cookbooks. For example you can use knife to create new cookbooks on your Chef development machine. 

Data Bags

Data Bags are used to store nested key–value data (like attributes) that are globally available to all of your Chef-based servers. Data Bag data is searchable and can also be loaded directly by name in a recipe.

RightScale supports the "Data Bag" concept by using inputs. Any Chef attribute can be converted into a user-configurable input. Inputs give you more flexibility than Data Bags because you can define values for these inputs in different places to control the level of inheritance. For example, you can define a value for an input that will be inherited by all servers in a deployment or at the ServerTemplate level if you want to set a default value that can be inherited across your account. See the Intermediate 2 Chef Tutorial for an example of how to create and use inputs.


Search allows you to globally query arbitrary data about your infrastructure. It's most commonly used in a recipe via search calls. 

RightScale supports "Search" functionality using tags and environment variables. The added benefit of using tags instead of Search is that you can use them to discover and manipulate servers. (i.e. You can run a script based on a specific tag.) For example, if you want a set of client servers to connect to the master server at boot time, you could add a tag to the master server and run a script on each client server (at boot time) that establishes a connection to the "master" server based on its tag. Currently, tags are deployment-specific, so you can only use tags to affect servers within the same deployment. Similarly, you could also use a cloud or RightScale-specific environment variable as an input (e.g. PUBLIC_IP, RS_SERVER_NAME, etc.) as a predicatable way to find the "master" server and run a script accordingly using variable substitution. The use of tags can also help you isolate the type of information that you want to be searched. Chef's Search feature lets you search for any piece of information about an entire node of clients, which might be a security concern for your business, whereas RightScale tags let you explicitly define which types of information you want to expose. Use tags to limit what values are externally searchable.

Note: In a future release, RightScale will support the ability to use tags globally in your account across multiple deployments.


Environments create different work "environments" for each project or phase of a project such as production, staging, development, and testing, etc. Environments are only supported in Chef v0.10.

RightScale supports the concept of environments with deployments. Create deployments using the RightScale Dashboard or API. Use deployments to manage a group of servers that could be deployed across multiple cloud infrastructures. Define deployment-specific inputs to establish consistent server configurations across all servers within a deployment. Execute scripts across multiple servers within the deployment to perform upgrades, failovers, and other lifecycle management tasks.


Roles define a common set of features across a group of similar nodes (servers). They consist of a name, description, run list of Chef recipes that are executed in order, and a set of node attributes that apply to the recipes. Multiple roles can be used to configure a server. 

RightScale supports the concept of Roles with ServerTemplates. Create a single ServerTemplate that runs a series of recipes to configure a specific type of functional server (e.g. PHP application server) across multiple clouds and operating systems. ServerTemplates also provide a way to include a set of recipes that may or may not be executed over the lifetime of the server to perform various operational tasks so that you can easily change a running server's configuration. For example, instead of having to wait for a reconvergence of your entire system before you can perform a failover to a slave database you can simply run an operational script on-demand. Use a ServerTemplate's operational script list to define actions that are specific to system administrators. ServerTemplates also give you the ability to define acceptable inputs that can be inherited account-wide while also giving you the flexibility override those inputs at the deployment or server level.

You must to post a comment.
Last modified
08:39, 12 Sep 2013



This page has no classifications.



© 2006-2014 RightScale, Inc. All rights reserved.
RightScale is a registered trademark of RightScale, Inc. All other products and services may be trademarks or servicemarks of their respective owners.