If you are currently a Chef developer who is familiar with Chef concepts and the Chef Client/Server model, but are new to RightScale, you may want to learn about which Chef-specific features are supported and unsupported by RightScale. The following Chef-specific features are not supported by RightScale as-is because their functionality is supported using different RightScale methodologies.
If you have an existing library of custom Chef cookbooks and recipes that you want to use in the RightScale platform with ServerTemplates, you will need to remove any Chef features that RightScale does not natively support.
This document will explain how the functionality of the unsupported Chef features listed above are supported in a slightly different way in the RightScale platform.
The information below explains how RightScale provides the same level of functionality of the unsupported Chef features using certain RightScale concepts.
|Define the final state of a launched server||Yes||Yes. A ServerTemplate's list of boot scripts defines scripts that are automatically executed in sequence when an server is launched. When all of the boot scripts are successfully executed, the server is a fully functional server.|
|Execute select operational scripts at runtime, on-demand||No. Any changes to a role(s) will be applied to all nodes (servers).||Yes. Use a ServerTemplate's list of operational scripts to define scripts that can be executed at runtime by system administrators to perform modifications or upgrades on a single server or group of servers.|
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.
|Roles can be defined for different environments||Yes|| |
Yes. The same ServerTemplates can be used across multiple deployments (e.g. production, staging, etc.) where inputs can be used to differentiate functionality depending on the environment.
|Use different cookbook versions for different environments||Yes||Yes. Supported with built-in ServerTemplate version control.|
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.
|Define global inputs||Yes||Yes. Predefine a ServerTemplate's inputs with default values that can be inherited accross an account.|
|Define different values on a per node (server) basis||No. The same value must be used by all nodes or group of nodes.||Yes. Use the input hierarchy rules to override inputs at the deployment or server levels.|
|Search||Yes||No. (Use Tags instead. See below for details.)|
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.
See Understanding Inputs.
|Perform global queries across an entire account||Yes|| |
No. Perform queries across a single deployment.
Note: The next dashboard release will support the ability to perform global queries across all deployments.
|Scope query to environment||Yes (However, you must build recipes that are specific to a particular use case.)||Yes. Perform transparent queries that do not require any changes to your Chef code.|
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.
In a traditional Chef architecture, you can either manage you own Chef Server or use a Hosted Chef setup where the Chef client servers connect to a Chef Server managed by Opscode.
However, if you are using Chef-based ServerTemplates to launch servers with the RightScale management platform, a Chef Server is not required because the management of a Chef client server is performed by its RightLink agent, which communicates with the RightScale core platform to orchestrate all aspects of a server's configuration. In order to properly use Chef cookbooks and recipes in a ServerTemplate, you must use one of the latest RightImages (that includes RightLink v5.7 or newer).
RightScale uses all of the standard Chef plugins except for the 'cloud' plug-in. RightScale overrides Opscode's 'cloud' plug-in with our own version, which is installed with RightLink when you launch a server using the latest RightImages (v5.7 and above). Details about RightScale's 'cloud' plug-in can be found in our RightLink repository on GitHub (https://github.com/rightscale/right_...b/chef/plugins).
RightScale supports the following cloud attributes:
RightScale's 'cloud' plug-in does not currently support the following attributes, which are supported by the Opscode's version.
© 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.