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. (https://github.com/rightscale/) 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.
There are several benefits of using Chef for configuring servers in the cloud. Some of the key benefits are listed below.
To have a more successful experience using Chef, it's recommended that you have a basic understanding and some experience using the following technologies.
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.
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.
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.
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.
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.
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.
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 (http://wiki.opscode.com/display/chef/Core+Components).
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 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.
© 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.