Deployments

New

To create a deployment, specify the following parameters:

• Nickname - Provide a nickname to help identify the deployment.
• Description - Provide a helpful description of the deployment.

Index

A Deployment consists of a cluster or group of Servers that work together and share common Input variables and cloud configurations. In a Deployment, you can manage a group of Servers in the same way that you would manage a single Server. You can define common Input variables, execute RightScripts on some or all Servers, as well as create multiple Server environments for production, development, staging, and maybe even failover scenarios. For example, a typical web site deployment consists of two front-end application servers and two back-end, master/slave database servers. At the Deployment level, you can see all of the Servers, the Inputs that are being used, as well as where the values are being inherited from. To learn more about inputs and the inheritance rules that apply, see Inputs and their Hierarchy.

- -

Show

A Deployment consists of a cluster or group of Servers that work together and share common Input variables and cloud configurations. In a Deployment, you can manage a group of Servers in the same way that you would manage a single Server. You can define common Input variables, execute RightScripts on some or all Servers, as well as create multiple Server environments for production, development, staging, and maybe even failover scenarios. For example, a typical web site deployment consists of two front-end application Servers and two back-end, master/slave database Servers. At the Deployment level, you can see all of the Servers, the Inputs that are being used, as well as where the values are being inherited from. To learn more about inputs and the inheritance rules that apply, see Inputs and their Hierarchy.

Action Buttons

• Clone - Create an exact duplicate of the definition of your Deployment. The data that is stored on Servers in your Deployment will not be copied over when you clone a Deployment. You are simply cloning the definition of that Deployment so that you can launch a duplicate setup at a later time or modify its configuration accordingly. Any associated Server Arrays will also be cloned.
• Archive - Archive a Deployment whenever you wish to remove a rarely used Deployment from the main view. An archived Deployment is not deleted; it is relocated to the bottom of the page under "Archived Deployments."
• Delete - Permanently delete a Deployment. You can 'lock' a Deployment to prevent accidental deletion.
• Add Server - Add a new server to the deployment.
• Add Array - Add a new array to the deployment.
• Edit - Change a Deployment's title, description, or specify the default availability zone for launching instances (Default: any)

History tab

The History tab provides detailed information about all terminated instances of a deployment including launch date/time, termination date/time, runtime length, instance ID, and more.

Volumes tab

The Volumes tab lists the Elastic Block Store (EBS) volumes that are currently attached to Servers in your Deployment. To create or attach an EBS volume to a Server or to see the volumes that will be attached at boot-time, when a Server is launched, navigate to a Server's Volumes tab.

Audit Entries tab

The Audit Entries tab shows a detailed, historical record for all server activity within a deployment. Audit entries are created for virtually all actions, such as launching and terminating instances, as well as commands that are executed on instances to perform operations such as script execution or performing database backups. These log files will be one of your most useful tools for troubleshooting problems. Click the link in the Summary column to view a detailed audit entry. You can either view the audit entry in a "structured view" where information is sorted by actions or in "raw output view" where information is displayed as a typical, plain text log file. Click a timestamp to highlight any audit entries that were created at that particular time to see what took place before and after that audit entry. To view audit entries across the entire RightScale account, see Report -> Audit Entries.

Scripts tab

The Scripts tab shows a consolidated list of all RightScripts that are used by one or more Servers in the Deployment. When a RightScript is run, the script will be executed on running Servers that contain the RightScript. At the Deployment level you can either run a RightScript on select Servers or all Servers. Typically, you will need to run a boot or operational script when Input values have been modified and you need to pass those new Input values to your running Servers. In such cases, you need to execute one of the RightScripts that contains that Input value. Remember, multiple RightScripts can reference the same Input variable. You can freeze software repositories. When you freeze software repositories at the Deployment level, the changes will affect all Servers in the Deployment. By default, the preference is set to "Inherit" (i.e. It will inherit the repository preferences that are defined at the ServerTemplate level.) Similar to Inputs, repositories that are frozen at the Deployment level will override software repository preferences defined at the ServerTemplate level. There are three different types of RightScripts (and the ability to run 'Any Script'):

• Boot - Scripts that are executed at boot time when a Server is launched. Boot scripts are typically used for setup purposes such as software installations. Boot scripts can also be run during a Server's runtime.
• Operational - Scripts that are not run during the boot phase, but are available for on-demand execution on a running Server. Operational scripts are typically used for performing one-time actions on a Server. For example, restarting Apache, SVN code updates, or promoting a Slave-DB server to become the new Master-DB.
• Decommission - Scripts that are executed during the decommissioning phase when a Server is terminated. Decommission scripts can also be run during a Server's runtime.
• Any - Select and run any RightScript that's available in your account's local collection on select/all Servers in a Deployment. This feature is useful for running a script that's currently not listed in the ServerTemplate. Input parameters will not be prepopulated in the input confirmation screen. If a script is not available in your local collection, you may need to import it from the MultiCloud Marketplace. (Chef Recipes are not supported.)

Changes tab

The Changes tab shows an exhaustive changelist log of all changes made to the deployment. For example, changing the deployment name or an input value. Since, multiple users can have access to an account, you may need to determine who made specific changes to your deployment in order to properly assign blame/praise to the correct person.

Inputs tab

The Inputs tab displays a consolidated list of all inputs that are used by one or more servers in the deployment. You can see the current input parameters that are being used and it's being inherited from. Typically, most servers inherit their input values from their ServerTemplates. However, input values defined at the deployment level take precedence over any input values defined at the ServerTemplate level. When you edit and define input values at the deployment level, they will be inherited by ALL servers in the deployment and will overwrite any input values that are inherited from ServerTemplates. Similarly, inputs that are defined at the individual server level will overwrite input values that are defined at either the ServerTemplate or deployment levels. It's useful to define inputs at the deployment level if you have multiple deployments that are using the same ServerTemplate revision. For instance, you may want to configure your 'staging' deployment to use the same templates as your 'production' deployment, except you want to use a different database or SVN repository. Usually inputs are used in more than one RightScript. If you're creating your own private RightScripts, remember to use distinct input variable names otherwise, you may unintentionally define incorrect values for these inputs. For inputs that have predefined dropdowns, you can check the "override dropdown" box to manually enter a text value that you would like to use instead. There are five types of inputs:

• Inherit - Select which value to inherit.
• Ignore - The input value will be ignored. No value will be defined for this input variable. This is only for optional inputs, and may not be applied to a required input.
• Env - Choose one of the predefined environment variables. We've defined several environment variables for EC2 and RightScale.
• Text - Enter a valid value.
• Cred - Select one of the credentials that you've previously created and defined.
• Key - Select an SSH key value. Only SSH keys that contain key material will be listed.

The following action buttons exist on the Deployments -> Inputs tab:

• Edit - Edit Inputs at the Deployment level.
• Download CSV of External References - Exports all Input information at the Deployment level to a CSV file so you can view and report on it from an Excel spreadsheet. The following fields are exported: Input Name, Server Name, Unique Server ID, RightScript/Chef Recipe that uses the Input, Phase (boot, operational or decommission), Input Value, Source (where the Input was defined).

Alerts tab

The Alerts tab shows an overview of all alerts and alert escalations. Unlike the Alerts tab at the Dashboard view, the Alerts tab for a deployment only displays alert information that's related to a specific deployment. The Overview section provides a real-time view of all alerts that are enabled (active) within the deployment along with the current state of each alert. The Alert Escalations sections lists the ones that can be associated with alerts in the deployment. Alert Escalations can either be configured to be available for a specific deployment or all deployments.

• Enabled - The number of alerts (not servers) that are active (enabled) and are currently being monitored. Only the enabled alerts on running servers will be shown. Once an alert is triggered, the associated alert escalation will be called and its actions will be run in sequence. A green ball denotes that there are no triggered alert conditions on any of your running servers. A red ball denotes a triggered server alert condition. A red ball will be shown for each triggered alert. When an alert is triggered, it will be listed below along with the associated alert escalation that was called, the state of the alert (true=enabled; false=quenched/disabled) and the length of time (min/hour/day) that the same alert condition has been triggered (i.e. the alert condition still exists; the alert escalation's actions have not resolved the alert condition). You can also view/edit the alert, as well as change the state of the alert on a running server if you want to prevent a triggered alert from calling an alert escalation by quenching the alert (1hr off / 24hr off) or disabling it by making it inactive.
• Quenched - The number of alerts on running instances that have been temporarily quenched (disabled) (i.e. 1hr off, 24hr off).
• Inactive - The number of alerts on running instances that have been turned off (disabled).

Click the icon, to view an alert's error message. Click the "Show" link to view more detailed information about each alert that is triggered.

Info tab

The Info tab shows the description and tags for the deployment.

Action Buttons

• Edit - Edit the description of the deployment.
• Edit Tags - Create tags to use for servers to address other servers within the deployment.

Xref tab

The Xref tab cross-references and displays all uses of input variables in the deployment across all existing servers and RightScripts. It also calculates and shows the final value for each input variable according to the inheritance rules. The table is useful for finding inconsistencies within your inputs or for determining why a particular input is being defined a certain way.

Server Defaults tab

The Server Defaults tab lists the cloud components that are available for configuring as default settings for servers in your deployment. These defaults can also be set at the account level.

Fields

• Cloud - Select the cloud to set server defaults that will be used to launch servers within the deployment. You may set different server defaults for each cloud.
• Instance Type - Set the instance type (size) to be used as a default. You also have the option to inherit the instance type used in the Account Server Defaults.
• SSH Key - Select the SSH Key to be used as a default. You also have the option to inherit the SSH Key used in the Account Server Defaults.
• Security Group(s) - Select the Security Group to be used as a default. You also have the option to inherit the Security Group used in the Account Server Defaults.
• Datacenter - Select the regional datacenter in the cloud to be used as a default. You also have the option to inherit the datacenter used in the Account Server Defaults.

Monitoring tab

The Monitoring tab displays real-time graphical data for all servers in your deployment. By default, the 'cpu-overview' and 'interface if_packets-eth0' graphs are displayed, which show you status of your server's resources and incoming/outgoing data (packet) traffic. To view other detailed graphs, you will need to navigate to the Monitoring tab of a particular server. Note: Graphs will only appear on servers where monitoring is enabled. To enable monitoring, you will need to Set up collectd. To view other detailed graphs, you will need to navigate to the Monitoring tab of a particular server or deployment.

Cluster Monitoring provides a simple and efficient means to browse through monitoring data for Deployments consisting of many Servers. Customers with hundreds or even thousands of Servers in a Deployment will find this feature very useful. You can specify a subset of Servers to Cluster Monitor in your Deployment based on the Server name, ServerTemplate name, or Tag. Select the Add Cluster Monitor action link on our Deployments Monitoring tab to filter, apply and view Cluster Monitoring graph data.

Edit

You can edit the following parameters of a RightScale Deployment:

• Nickname - Provide a nickname to help identify the Deployment.
• Description - Provide a helpful description of the Deployment.
• Default Availability Zone - Select the Availability Zone that will be preselected by default when a new Server is added to the Deployment.
• Default VPC Subnet - Select the VPC Subnet that will be preselected by default when a new Server is added to the Deployment. (Only visible if VPC is enabled)
• Default Placement Group - Select the Placement Group that will be preselected by default when you add CCI instances to the Deployment. EC2 Placement Groups are specific for Amazon's High Performance Computing (HPC) service where you can launch Compute Cluster Compute Instance Types (CCI).