Deployment - Concepts

About Deployments

What is a RightScale Deployment?

A RightScale Deployment consists of a group of Servers that work together. A typical web site Deployment consists of two front-end application Servers and two back-end, master/slave database Servers.

Go to Manage > Deployments. Deployments represent the highest level view of your account. You can create and clone Deployments, start and stop all servers in a Deployment, define Deployment-wide Input variables, and much more.

Select a specific Deployment to see more specific information.

There are a variety of tabs that provide more detailed information about all aspects of a Deployment.

• Servers - Provides a high-level overview of all servers of a deployment. Select a server to view more specific information including its Public/Private DNS name, ASW id, instance type, and more.
• Inputs - List of input variables that are defined at the deployment level. If a server is running and you want to change its inputs, run a script under the “Scripts” tab.
• Monitoring - View real-time graphical data for any server in your deployment.
• Scripts - List of all RightScripts that are used by one or more servers in the deployment.
• Volumes - List of Elastic Block Store (EBS) volumes.
• Alert Escalations - List of alert escalations and their associated deployments.
• Audit - Shows the audit trail for all the servers in the deployment. Audit records reflect user triggered actions, boot activity, as well as any automatic actions that are performed by RightScale.
• History - Provides detailed information about all terminated instances of a deployment including launch date/time, termination date/time, runtime length, instance ID, and more.
• Xref - 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.
• Changes - A changelist log of all changes made to the deployment. (For example, changing the deployment name.)

Benefits of Using Deployments

Define Common Input Parameters

Deployments provide a useful way of managing a common group of instances. For example, if you set common input parameters at the deployment level, all servers in the deployment will inherit the same parameters unless they are overwritten at the server level. (Input parameters that are defined at the deployment level will overwrite the values that are defined at the ServerTemplate level. It's useful to define common input parameters at the deployment level for all servers such as AWS and database credentials. You cannot define Inputs for the Default deployment. You can only define deployment-wide inputs for a deployment that you create.

Multiple Deployments

Deployments are especially useful for creating unique or identical work environments. Remember, deployments are free; you only have to pay for server usage. Therefore, you might want to use deployments to organize custom server environments (production, staging, testing, backup, marketing, etc.). Each deployment can have different users with different permission rights. See Create a Staging Deployment.

Clone Deployments

The ability to instantly clone a deployment with one click is a very simple, but very powerful feature. Now you can create an exact copy of an existing deployment. For example, clone your staging deployment for your quality assurance team so they can perform GUI and regression tests without impacting the developers' environment. Create a clone of your production-ready deployment as a backup that will be ready to launch in a different availability zone if problems arise. See Designing Failover Architectures on EC2. Remember that in the cloud you are not limited by hardware resources and can create working environments that are always available for you on demand.

Lock a Deployment

You should lock a deployment in order to prevent a deployment from being deleted. It also prevents servers from being removed from a deployment, but it does not prevent a user from adding servers or performing actions on any existing servers, such as launching/stopping servers.

Additional Considerations

• Each Amazon EC2 deployment must use the same AWS Credentials (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY).

Lock Down an Entire Deployment

Overview

You should lock down your running production Deployment to protect it from inadvertent actions, and guarantee that future launches of Servers use the exact same software and configurations. This will provide predictable, repeatable results for the future. Note this goes beyond simply locking the Deployment, as discussed below.

Freeze the Repository

Freeze the software repository for all ServerTemplates used by your Deployment.

• Navigate to the ServerTemplate > Repos tab
• Although you can pick and choose which repositories to freeze, selecting them all is common practice (simple and effective). Tip: Click the checkbox in the OS Distribution Repositories table header to select all.
  • Select the Frozen radio button, then select the appropriate date to freeze the repos at.. Important! - Although you can select current, it is not considered best practice. It is better to set the date when you know the ServerTemplate was no longer in flux, and has produced a solid running Server.
  • click the Apply action button when ready

!!info*Note:* It is likely that you will need to repeat this process for more than one ServerTemplate used by your Deployment.

Commit HEAD revisions

Commit all HEAD revisions of all ServerTemplates and RightScripts that your Deployment uses.

• Navigate to the Deployment you wish to lock down
• Check the Servers in your Deployment to see if they are using HEAD revision ServerTemplates. If so, select the ServerTemplate and...
• Click the Commit action button
  • Enter a descriptive Message
  • Each RightScript in the ServerTemplate that is a HEAD revision is flagged. There is a checkbox that is selected by default to commit HEAD RightScripts too.
  • Click the Commit action button when ready
• A new revision of the ServerTemplate is created

!!info*Reminder:* Your Deployment may have more than one HEAD revision ServerTemplates. For example, your application Servers and front end Load Balancers may use customized ServerTemplates. If so, remember to commit those ServerTemplates in a similar manner.

Lock the Deployment and Servers

• Navigate to the Deployment. Lock it by selecting the lock icon next to its name.
• Select each individual Server in the Deployment and lock it as well.

Shutdown and Restart (if needed)

If this is a new Deployment that (after proper development and testing) is ready to be launched in a production environment, you may need to shut it down and restart it as a final test. For example, if you have made several iterative changes to a Server, ServerTemplate or RightScript, and finally got things just right, and have committed all HEAD revisions, the temptation may be to leave that Server running. This is not a great idea. It is recommended that you shutdown and then start up the entire Deployment using the newly committed revisions as a final test before locking it. This will guarantee that future restarts are favorable, as well as protect you from someone else making changes to a running HEAD revision.

Shutting Down a Multi-Tiered Deployment

Overview

Whether or not your RightScale-managed Deployment in the cloud is designed to scale or not, it is very common to configure it with multiple tiers. For example, the following three tiers are typical:

1. Front-end tier that services (and load-balances) requests
2. Middle application tier
3. Back-end database tier

There are two common configurations of the above multi-tiered Deployment model as well. One has the first two tiers completely separate; that is, tier one is strictly for load balancers, and tier two is strictly for the application (usually a scalable Server Array with a minimum instance count of two). The other combines your application and front-end services for two Servers (and adds a scalable Server Array as well).

In this example, the application is being served by both the FrontEnd Servers and Servers in the Server Array.

In this example, the application is only being served by Servers in the Server Array.

Depending on your specific configuration, how you shut down or start up your Deployment could differ somewhat.

The key for determining the order in which to shut down or start up your Deployment components is dependencies--for example, what do the Servers running your application depend on to start up or shut down correctly?

Disclaimer

Because each specific application and Deployment for that application is different, there is not a strict set of rules for shutting down or starting up a multi-tiered Deployment that applies in every scenario. For that reason, please consider the information in this document as guidelines (and not strict rules).

Remember to implement reboot-safe RightScripts (and/or Chef Recipes), and test out your Boot- and Decommission-phase scripts thoroughly.

Shutting Down

!!warning*Important!* Rarely (if ever) will you shut down an entire production Deployment. However, you may want to shut down an entire staging or test Deployment at night or over a weekend to save on usage costs.

Shutting down a multi-tiered Deployment is usually more straightforward than starting it back up. A common shutdown order by tier is as follows:

• Shut down the front-end load balancer tier first. This will prevent future requests--which may or may not require additional computation at the application (middle) tier and read/write actions on the database tier--from being serviced.
• Shut down the application tier. If you are using a scalable Server Array, remember to disable the array first. If you forget to do this and terminate all running instances, new instances will automatically be launched (in accordance with the minimum count for Servers in your Array).
• Once the application tier has shut down, shut down the database tier.

Starting Up a Multi-Tiered Deployment

Overview

Whether or not your RightScale-managed Deployment in the cloud is designed to scale or not, it is very common to configure it with multiple tiers. For example, the following three tiers are typical:

1. Front-end tier that services (and load-balances) requests
2. Middle application tier
3. Back-end database tier

There are two common configurations of the above multi-tiered Deployment model as well. One has the first two tiers completely separate; that is, tier one is strictly for load balancers, and tier two is strictly for the application (usually a scalable Server Array with a minimum instance count of two). The other combines your application and front-end services for two Servers (and adds a scalable Server Array as well).

In this example, the application is being served by both the FrontEnd Servers and Servers in the Server Array.

In this example, the application is only being served by Servers in the Server Array.

Depending on your specific configuration, how you shut down or start up your Deployment could differ somewhat.

The key for determining the order in which to shut down or start up your Deployment components is dependencies--for example, what do the Servers running your application depend on to start up or shut down correctly?

Disclaimer

Because each specific application and Deployment for that application is different, there is not a strict set of rules for shutting down or starting up a multi-tiered Deployment that applies in every scenario. For that reason, please consider the information in this document as guidelines (and not strict rules).

Remember to implement reboot-safe RightScripts (and/or Chef Recipes), and test out your Boot- and Decommission-phase scripts thoroughly.

Starting Up

Although your specific application and Deployment could have certain dependencies that dictate a different start order, the following is typically considered best practice for a start order of a multi-tiered Deployment.

• Begin by starting up your database tier.
  • First start your master database.
  • Once operational, you will want to restore from the most recent backup and update your DNS entries. This is done for you when you run the operational RightScript: DB EBS restore and become master (See the scripts Info tab and the contents of the RightScript itself for additional details.)
  • Note: The last thing this RightScript does is start a backup. Let the snapshot finish before booting your Slave Server(s). See Clouds > CloudName > EBS Snapshots (Status == 100% Completed)
  • Boot your slave (or slaves, if you have them). Remember that the Input specifying to initialize the slave at boot (e.g. INIT_SLAVE_AT_BOOT) should be set to false for the master, and true for the slave(s).
• Start the Servers in your load balancing tier.
  • Note: If you have any ancillary Servers you should start them now as well before starting your application Servers. For example, caching Servers (memcached) or load testers (httperf).
• Start your application tier Servers (or Server Array)

!!warning*Important!* Several other considerations may come into play, depending on your specific situation and context:

• If some time has elapsed since you last shut down your Deployment you probably discarded your EIPs in order to save on costs. Don't forget you will have to create new EIPs and replace the old ones previously used by your Load Balancers as well as update DNS A Record information.
• If you start your application Servers before your load balancers are on line, you will need to manually run an operational (or any script) to register the application Servers with your load balancers. If they are not registered with the load balancers than they will not be able to service incoming requests. An example boot or operational RightScript that does this for Deployments using HAproxy to load balance is: LB app to HA proxy connect.