Note: Please go to docs.rightscale.com to access the current RightScale documentation set. Also, feel free to Chat with us!
Home > ServerTemplates > Infinity > Supplemental > 3 Tier Deployment Setup (ELB-Tomcat6-MySQL)

3 Tier Deployment Setup (ELB-Tomcat6-MySQL)

Objective

To create a 3-tiered production-like deployment in Amazon EC2 using Amazon's Elastic Load Balancing service and ServerTemplates published by RightScale for launching an Tomcat application.

Note: The tutorial uses RightScale's latest revisions of the v13 Infinity ServerTemplates that use Chef cookbooks and recipes instead of RightScripts.

Table of Contents

  1. Overview
  2. Deployment Setup
  3. Database Setup
  4. Load Balancer Setup
  5. Application Setup
  6. Test the Deployment
  7. Next Steps

Prerequisites

  • Access to add/create/edit DNS records with a supported DNS provider (e.g. DNSMadeEasy, DynDNS, Route53)
  • A paid edition of RightScale.
  • 'designer' 'actor' and 'security_manager' user role privileges are required, although the 'security_manager' user role privilege may not be required if security group with the appropriate firewall permissions already exist.

Overview

Although this end-to-end tutorial was originally designed as a hands-on exercise in an Instructor Led Training course, anyone can follow the tutorial and use it as a learning tool as well. The class environment influences naming conventions, hence we often precede names with initials or names in our examples. (For example, an A Record for John Doe named "jd-www", rather than simply "www"). Be sure to provide enough time for yourself to complete the end-to-end exercise. (Estimate: 1-3hrs) 

This tutorial will demonstrate how to build a common 3-tier website architecture in the cloud using some of RightScale's ServerTemplates. 

  • Amazon Elastic Load Balancing
  • Tomcat Application servers
  • MySQL Database servers

 

diag-3tierELB-v1.png

Disclaimers

  • This tutorial assumes that you are launching all servers into the same Amazon EC2 region. 
  • As a best practice, it's encouraged to deploy over multiple Datacenters / Zones (if supported by the cloud) for high-availability.

Deployment Setup

Create a Deployment

It's recommended that you create a new deployment for each new project or reference architecture that you're going to build because you do not want to accidentally inherit any unknown configuration settings.

See Create a New Deployment. (Requires 'actor' user role privileges.)

Tip: It's recommended that you create a bookmark to the deployment's Servers tab for quick navigation back to the deployment at any time.

Create DNS Records

In a typical 3-tier architecture setup, DNS A records are used to create fully qualified domain names (FQDNs) that map to a particular server or tier of servers. The digram below shows a typical example of a 3-tier website architecture.

For example, the application servers locate the "master" database server by using Master-DB's FQDN (e.g., db-master.example.com), which points to the Master-DB's private IP address. Similarly, front-end web traffic can be routed to a FQDN (e.g. www.example.com) where each load balancer server has a DNS record for that FQDN so that incoming requests are routed to one of the load balancer servers. Since the IP address of an instance in the cloud is often dynamically assigned at launch time, you are required to use a DNS provider that supports dynamic DNS (i.e. the ability to dynamically update the IP address of an A record) for the Master-DB server (at a minimum). You can also use the same DNS provider for creating FQDNs for the load balancer servers. However, since they do not require the use of dynamic DNS, any DNS provider can be used.

TTLs

When you create the DNS records, it's important to set appropriate TTLs to ensure that servers will not stay connected to an old IP address that is no longer assigned to a functional server. For example, the DNS record that points to the "master" database server should have a low TTL to ensure that the application servers will connect to the correct server within a reasonable amount of time. It's strongly recommended that you use a TTL of 60 seconds for the DNS record that points to the "master" database server.

diag-3tier_ELB_DNS-v1.png

You will need to create DNS records for the database servers and a CNAME for the Elastic Load Balancer:

  • Elastic Load Balancer
  • Master Database Server
  • Slave Database Server (optional)


RightScale's ServerTemplates contain scripts that support one of the following DNS providers. Create an account with one of the DNS providers below and set up the A records accordingly.

Create Common Credentials

Prerequisites: Requires 'designer' user role privileges in the RightScale account to create a new credential.

Important!
Only the user who created the credential and any 'admin' users will be able to view and modify an existing credential. 

Credentials are a way of passing sensitive information to a script (as an input) in a discrete manner without making the actual value visible in the Dashboard. As a best practice, many of the ServerTemplates published by RightScale are preconfigured to use certain credentials. It's recommended that you create these common credentials in your own account. If they already exist and apply to a different deployment, you might want to create a new set of credentials to avoid any conflicts. In such cases, it's helpful to use a common prefix to group the credentials together. (e.g. APP1_DBADMIN_USER)

If you try to launch a server where one of the inputs references a credential that does not exist in the RightScale account, you will receive an error message and will not be able to launch the server. Therefore, it's best to create any required credentials before you configure and launch a server. Depending on your cloud provider and backup storage selections, you may want to create additional credentials.

At a minimum, create the following credentials. See Create a New Credential for more information.

Common Credentials for a 3-Tier Architecture

If you are going through a 3-tier tutorial you should create the following credentials with your own values or you can use the example values, if desired.

  • DBADMIN_USER - Username of a database user with administrator privileges. Use this credential for the "Database Admin Username" input.
    • 3 Tier Tutorial: admindb
  • DBADMIN_PASSWORD - Password for DBADMIN_USER. Use this credential for the "Database Admin Password" input.
    • 3 Tier Tutorial: admindb
       
  • DBAPPLICATION_USER - User name of a database user with user-level privileges. Use this credential for the "Database Application Username" input.
    • 3 Tier Tutorial: 1234
  • DBAPPLICATION_PASSWORD - Password for DBAPPLICATION_USER. Use this credential for the "Database Application Password" input.
    • 3 Tier Tutorial: 1234
       
  • DBREPLICATION_USER - Username of a database user with replication permissions on the server. Use this credential for the "Database Replication Username" input.
    • 3 Tier Tutorial: dbrpl
  • DBREPLICATION_PASSWORD - Password for DBREPLICATION_USER. Use this credential for the "Database Replication Password" input.
    • 3 Tier Tutorial: dbrpl
       
  • DNS_USER* - Username that's used to log into your DNS provider and update DNS records. It's commonly used to update the A record with the private IP address of the "master" database server. Use this credential for the "DNS User" input.
  • DNS_PASSWORD* - Password for DNS_USER. Use this credential for the "DNS Password" input.

If you use Amazon Route 53 or Rackspace Cloud DNS as your DNS provider, you do not need to set up separate DNS user name and password credentials because your cloud credentials are used for authentication purposes. 

Remote Object Storage (ROS)

ServerTemplates published by RightScale have built-in support for several remote object storage (ROS) solutions. Valid cloud credentials are required to retrieve "private" files from an ROS container, create a new container, or store files in a container (such as a binary database backup files). It's recommended that you create the following credentials before you start building a deployment for each ROS service you plan to use.

Amazon S3

The following credentials are automatically created for you when you add AWS cloud credentials to a RightScale account. Although, they are available for use when you define your inputs, they will not be listed with the other credentials. (Design > Credentials). Note: AWS credentials are located at the account level (Settings > Account Settings > Clouds). See Sign up for Amazon Web Services (AWS).

  • AWS_ACCESS_KEY_ID - Amazon access key ID for authentication.
  • AWS_SECRET_ACCESS_KEY - Amazon secret key corresponding to AWS_ACCESS_KEY_ID.
Rackspace Cloud Files

See Add Rackspace Open Cloud to a RightScale Account.

  • RACKSPACE_USERNAME - The username used to log into Rackspace's Cloud Control Panel. Use this credential for the "Backup Primary User" and/or the "Secondary Backup User" input if you are using Rackspace Cloud Files for primary and/or secondary backups. 
  • RACKSPACE_AUTH_KEY - The Rackspace account API key. Use this credential for the "Backup Primary Secret" and/or the "Secondary Backup Secret" input if you are using Rackspace Cloud Files for primary and/or secondary backups.
Google Compute Engine
  • GOOGLE_ACCESS_KEY -  (e.g. GO5MTPOCQSPF5MBCOTPO)
  • GOOGLE_SECRET_ACCESS_KEY - (e.g. G2tr2637tr2it/ivVoYi+pVoYw7tr291LXLcx2t+)
Microsoft Azure Blob Storage
  • AZURE_ACCOUNT_NAME - The Blob Storage Account Name. (e.g. myname)
  • AZURE_PRIMARY_ACCESS_KEY -  The Primary Access Key. (e.g. Fdu9hoCOnOznjWN5l2qhMZHaRu9HTtLYOs4ejE5aWzrybL1Q49jrCHTtLYOs4ejE5eymS+ErBGlMYA3mpz3siIg==)
OpenStack Object Storage (swift)
  • SWIFT_ACCOUNT_ID - OpenStack Object Storage (Swift) Account ID. (tenantID:username) (e.g. OSOS123456-1:123456)
  • SWIFT_ACCOUNT_PASSWORD - OpenStack Object Storage (Swift) Account Password. (e.g. 68734787202aecdef123767678asdf72364872asdf468273478237as287df67)
SoftLayer Object Storage

See Set up SoftLayer Object Storage.

  • SOFTLAYER_USER_ID - The username of a SoftLayer User with API privileges. Use this credential for the "Backup Primary User" and/or the "Secondary Backup User" input if you are using SoftLayer Object Storage for primary and/or secondary backups. (e.g. SLOS123456-1:SL123456) 
  • SOFTLAYER_API_KEY - The matching SoftLayer API Access Key for the specified SoftLayer user. Use this credential for the "Backup Primary Secret" and/or the "Secondary Backup Secret" input if you are using SoftLayer Object Storage for primary and/or secondary backups. (e.g. 68734787202aecdef123767678asdf72364872asdf468273478237as287df67)

Software Repositories

Source Control Management (SVN, GitHub, FTP, rsync)

If you are using a source control management (SCM) system to host your application code, you will need to create the appropriate credentials to retrieve your source code from the specified repository.

  • GIT_SSH_KEY - A valid SSH Key for accessing a private repository hosted on GitHub.com. Use this credential for the "Account credential" input. 
     
  • SVN_USERNAME - The SVN username that has access to the specified repository. Use this credential for the "Account name" input.
  • SVN_PASSWORD - Password for SVN_USERNAME. Use this credential for the "Account credential" input.

 

  • FTP_USERNAME - The username that you use to log into the FTP server to access your software repository. Use this credential for the "Account name" input.
  • FTP_PASSWORD - Password for FTP_USERNAME. Use this credential for the "Account credential" input.

Other

rsync

Download application source code from rsync sources.

  • RSYNC_USERNAME - The username to log into the remote host. Use this credential for the "Account name" input.
  • RSYNC_SSH_KEY - If the remote host supports SSH key authentication, create an SSH Key for rsyncing data between servers. Use this credential for the "Account credential" input.

Secure Sockets Layer (SSL)

Database

If you are using the public network to connect to the master database server, it's recommended that you use SSL to encrypt the data being transfered between the master database server and the associated slave and/or application servers. Note: SSL is currently only supported in the Database Manager for MySQL 5.1/5.5 ServerTemplates.

  • MYSQL_SSL_CERT - The name of your CA SSL Certificate.
  • MYSQL_SSL_MASTER_CERT - The name of your Master SSL Certificate.
  • MYSQL_SSL_MASTER_KEY - The name of your Master SSL Key.
  • MYSQL_SSL_SLAVE_CERT - The name of your Slave SSL Certificate.
  • MYSQL_SSL_SLAVE_KEY - The name of your Slave SSL Key.

Create Cloud-specific Resources

EC2

S3

Simple Storage Service (S3) is Amazon's remote object store (ROS) where you can store static files that can be used by EC2 instances in any AWS region. For example, you can store a database dump file in an S3 bucket and then launch an EC2 instance that will retrieve the file from the S3 bucket. S3 buckets are also used to store binary backups of a database. 


Database Tier Setup

If you are setting up a database server for testing purposes or if you do not have your own dump file, you can use the following sample MySQL dump file to complete the tutorial. The sample is a bzip2 compressed file (.bz2) file.

Add a Server

Follow these steps to add a database server to the deployment.

  1. Go to the MultiCloud Marketplace (Design MultiCloud Marketplace > ServerTemplates) and import the most recently published revision of the following ServerTemplate into the RightScale account.
  2. From the imported ServerTemplate's show page, click the Add Server button.
  3. Select the cloud and the deployment for the new server and click Continue.
  4. Next, the Add Server Assistant wizard will walk you through the remaining steps that are required to create a server based on the selected cloud.
    • Server Name - Provide a nickname for your new database server (e.g., mysql-db1). Do not include "master" or "slave" in the name, because a database server's role can change in the future.
    • Select the appropriate cloud-specific resources (e.g. Datacenter/Zone, Security Group, etc.) that are required in order to launch a server into the chosen cloud. The required cloud resources may differ depending on the type of cloud infrastructure. If the cloud supports multiple datacenters/zones, select a specific zone. Later, when you create the other database server you will use a different datacenter/zone to ensure high-availability. For more information, see Add Server Assistant.
    • Important! If you are not using volumes to store the database, you must select an instance type that has disk space that's at least twice as large as your database because LVM snapshots are performed locally on the instance before they are gzipped and saved to the specified ROS location. Also, although these ServerTemplates will work with any instance size, you may experience degraded performance with small instance sizes (such as EC2 micro, Rackspace 256MB etc) due to lack of system resources. We do not recommend smaller instance types for production use.
  5. Click Confirm, review the server's configuration and click Finish to create the server.

Initial Setting of Inputs at the Deployment Level

The following inputs should be set at the deployment level. Go to the deployment's Inputs tab (Manage > Deployments > your deployment > Inputs) and click Edit.

Although you can enter values for missing inputs as text values, it's strongly recommended that you set up credentials for passing sensitive information to scripts such as passwords or any other sensitive data.

RS-MYSQL

Required

Input Name Description Example Value
Backup Lineage The prefix that will be used to name/locate the backup of the MySQL database server. text: mysql_test_lineage
Device Count The number of devices to create and use in the Logical Volume. text: 2
Device Volume Size Size of the volume or logical volume to create (in GB). text: 10
Backup Schedule Enable Enable or disable periodic backup schedule. text: true
Backup Schedule Hour The hour to schedule the backup on. This value should abide by crontab syntax. Use '*' for taking backups every hour. text: *
Backup Schedule Minute The minute to schedule the backup on. This value should abide by crontab syntax. text: 30
MySQL Root Password The root password for MySQL server. cred: MYSQL_ROOT_PASSWORD

 

Advanced

Input Name Description Example Value
MySQL Database Name The name of the application database. text: app_db
MySQL Application Password The password of the application database user.  The Application Username and Password will allow access to the database in a restricted fashion. cred: MYSQL_APP_PASSWORD
MySQL Application Username Username to access the application database. cred: MYSQL_APP_USERNAME
MySQL Database FQDN The fully qualified domain name of the MySQL master database server. text: db.example.com
DNS Secret Key The secret key to access/modify the DNS records.  In our example, this will be set to the ‘Secret Key’ from DNSMadeEasy. cred: DNSMADEEASY_SECRET_KEY
DNS User Key The user key to access/modify the DNS records.  In our example, this will be set to the ‘API Key’ from DNSMadeEasy. cred: DNSMADEEASY_API_KEY
Import Filename Filename of the database dump file to import. text: dumpfile_20140102.gz
Import Secret Key The private key to access the repository via SSH. cred:DB_IMPORT_GIT_KEY
Import Repository URL The repository location containing the database dump file to import. text: git://example.com/dbfiles/database_dumpfiles.git
MySQL Slave Replication Password The replication password set on the master database and used by the slave to authenticate and  connect. If not set, ‘MySQL Root Password’ will be used. cred: MYSQL_REPLICATION_PASSWORD

Launch the Master Database Server

After configuring your deployment inputs, launch your newly configured master database server.

Go to the deployment's Servers tab and launch the database server. When you view the input confirmation page, there should not be any missing values (highlighted in red) for inputs that are required by any of the server's boot scripts. If there are any inputs highlighted in red, cancel the launch and add the missing values at the deployment level before launching the server again. Refer to the instructions in Launch a Server if you are not familiar with this process. Click the Launch (not 'Save and Launch') button at the bottom of the input confirmation page.

Initialize the Master Database Server

Wait for the server to reach the "operational" state before proceeding. To view the status of a script run, go to the “current” server’s Audit Entries tab. Go to the “current” server’s Scripts tab, look in Operational Scripts, and run the following scripts, in order, to initialize the master database server.

  1. rs-mysql::collectd - sets up collectd monitoring for MySQL and adds graphs under the Monitoring tab.
  2. rs-mysql::stripe - creates and attaches the volumes, sets up a striped logical volume, and uses it for the database data location.
    • Variant: rs-mysql::volume - run this instead to use a single volume.
  3. rs-mysql::master - registers it as the “master” database server and assigns appropriate replication privileges and machine tags.  This also creates/updates the DNS record with the IP information of the server.
  4. rs-mysql::dump_import - Retrieves and imports the mysql dump file.  If no dumpfile was set in the inputs, there is no need to run this script. 
  5. rs-mysql::backup - Creates a backup of the volumes holding the database data.  This backup will be used to setup a ‘slave’ database server.

It is strongly recommended to not run scheduled backups on your ‘master’ database server.  Backups involves locking the database and freezing the filesystem.  This will usually cause issues with applications writing to the database.  Backups should only be done on the ‘slave’ database servers.

Final Setting of Inputs at the Deployment Level

Since the Master-DB is up and running, and an initial backup was made, one more input should be set at the deployment level to be used by new Slave-DB servers. Go to the deployment's Inputs tab (Manage > Deployments > your deployment > Inputs) and click Edit.

RS-MYSQL

Required

Input Name Description Example Value
Restore Lineage The lineage name to restore backups. text: mysql_test_lineage

Add a Slave Database Server

Create a slave server in your deployment.

  1. Clone the Master-DB server. See Clone a Server.
  2. Rename the server accordingly. (e.g. mysql-db2) Remember, you do not want to include the word "slave" in the nickname because this server may become the "master" server during a failover scenario. You don't want the server's nickname to potentially cause any confusion.
  3. Under the server's Info tab, click Edit and change the server's availability zone. In order to ensure high availability, it's strongly recommended that you launch the Slave-DB server in a different availability zone as the Master-DB.  Note: Cross-zone data transfer costs may apply.

Launch the Database Server

Make sure the following conditions are true before you launch the second database server.

  • The master database server state is "operational."
  • The initial primary backup of the master database server is 100% complete. You can track the status in the dashboard (Clouds > region > Snapshots). The time required to complete the initial primary backup will vary based on factors such as storage type, volume size, etc.

Because the inputs are configured in the deployment level for slave database servers, there is no need to alter the inputs.

Go to the deployment's Servers tab and launch the “slave” database server. When you view the input confirmation page, there should not be any missing values (highlighted in red) for inputs that are required by any of the server's boot scripts. If there are any inputs highlighted in red, cancel the launch and add the missing values at the deployment level before launching the server again. Refer to the instructions in Launch a Server if you are not familiar with this process. Click the Launch (not 'Save and Launch') button at the bottom of the input confirmation page.

Initialize the Slave Database Server

Wait for the server to reach the "operational" state before proceeding.  To view the status of a script run, go to the “current” server’s Audit Entries tab.  Go to the “current” server’s Scripts tab, look in Operational Scripts, and run the following scripts, in order, to initialize the slave database server.

  1. rs-mysql::collectd - sets up collectd monitoring for MySQL and adds graphs under the Monitoring tab.
  2. rs-mysql::stripe - as a result of ‘Restore Lineage’ being set at the deployment level, restores the volumes from the latest backup, attaches them to the server, re-enables the striped logical volume, and sets it as database data location.
    • Variant: rs-mysql::volume - run this instead if this recipe was used on the master database.  This will restore the single volume if a single volume was used on the master database.
  3. rs-mysql::slave - registers it as a “slave” database server, connects and syncs with the ‘master’ database server using the appropriate replication privileges, and sets machine tags.
  4. rs-mysql::backup - Creates a backup of the volumes holding the database data.
  5. rs-mysql::schedule - Adds the crontab entry for taking backups periodically.

Periodic backups should be done on a slave database since locking a slave database for writing should have little or no impact on applications that should be accessing the master database.  Once the backup completes, the filesystem is unfrozen, and the databases is unlocked, the slave database will catchup with the master.

Test Database Setup (Optional)

If you want to test the status of the "master" and "slave" database servers, see Check Database Status of Master or Slave.


Load Balancer Tier Setup

Creating a new AWS Elastic Load Balancer


Application Tier Setup

Prepare Application Code

The ServerTemplate supports the ability to download your application code either as a tarball (.tgz) from a Remote Object Storage location or checkout the codebase from a software repository.

  • Remote Object Storage (ROS)
    • Amazon S3
    • Rackspace Cloud Files
    • SoftLayer Object Storage
  • Software Repository
    • Git
    • SVN

Remote Object Storage (ROS)

  • Amazon S3 Bucket
  • Rackspace Cloud Files Container
  • SoftLayer Object Storage Container


If you have a tarball of your application, upload it to a Remote Object Storage location as either a 'public-read' or 'private' object. If you are using a 'private' object you must provide valid cloud credentials (as inputs) for authentication purposes in order to properly retrieve the object. For more information see the following tutorials.

Software Repository

  • Git
  • SVN


If you want to checkout your application code from a software repository (e.g. GitHub), you will need to provide your access credentials as inputs later in this tutorial so that a script can be executed to automatically retrieve your application code.

Sample Application

If you need a example application for testing purposes, you can use the application code from the following git repository.

  • Repository URL - git://github.com/rightscale/examples.git
  • Project App root - Set to "No value/ignore" or "Inherit:no value to inherit"
  • Git SSH Key - Set to "No value/ignore" or "Inherit:no value to inherit"
  • Repository Provider - repo_git
  • Branch/Tag - unified_tomcat

Create the Application Tier

You can either add application servers directly into a deployment or create an server array of application servers for autoscaling. 

Import the ServerTemplate

  1. Go to the MultiCloud Marketplace (Design > MultiCloud Marketplace > ServerTemplates) and import the most recently published revision of the following ServerTemplate into the RightScale account.
  2. (Optional) If you expect to make changes to the ServerTemplate, you will need to clone it to create an editable copy.  Click the Clone button and rename the ServerTemplate accordingly. (e.g. My App Server) Before you make any changes to the ServerTemplate, click the Commit button so that the first revision of the ServerTemplate matches the original revision, which will make it easier to perform differentials in the future to see what changes were made to the "original" version. When committing the ServerTemplate you can use a simple commit message. (e.g. Original version. No changes.) If you are actively developing the ServerTemplate, you may find it useful to use the HEAD version of the ServerTemplate to create the application server tier. However, for production environments, you should always use static, committed revisions of a ServerTemplate to launch servers.

Create a Server or Server Array

When you create a server or server array, you will first need to select a deployment and the cloud where the server will eventually be launched into (e.g. AWS us-east). Based on the chosen cloud provider, you will need to complete the configuration process that's specific for that cloud. For example, some cloud providers support features that are unique to their specific cloud. 

  • To create a server, click the Add Server button and complete the steps in the wizard. See Add Server Assistant for details. If you are setting up a multi-tier deployment, it's strongly recommended that you create at least two application servers.
    • The easiest way to create the second server is to clone the first one. Be sure to change the name of the server accordingly (e.g. app2) and its availability zone (if available) under the the Info tab.
  • To create a scalable server array, click the Add Array button and complete the steps in the wizard. See Add Server Array Assistant for details. 

Configure Inputs

The next step is to define the properties of your application server by entering values for inputs. It is best to do this at the deployment level. For a detailed explanation of how inputs are defined and used in Chef recipes and RightScripts, see Inputs and their Hierarchy.

To enter inputs for the Chef recipes that will run on your application servers, open the deployment's Inputs tab and click Edit, then follow the directions below to configure input values. We recommend that you set up credentials for password values and any other sensitive data as shown in the examples.

Note: The following examples and sample values assume that you will connect the application server with RightScale's "Load Balancer" ServerTemplate, which uses HAProxy. If you are using a cloud's load balancing service such as Rackspace Cloud Load Balancing (CLB) or Amazon's Elastic Load Balancing (ELB), please refer to the runbook for proper setup instructions.

APP

Input Name
Description
Example Value

Application Listen Port

The port that the application service listens on to accept requests from the load balancer. If you specify another port than the 8000 (default), be sure to add the port to the "Firewall Rule Port" input and make sure that the security group's settings also allow access (if applicable).

text:  8000

APP_TOMCAT

Input Name
Description
Example Value

War file for ROOT

The path to the war file relative to project repository's root directory. Will be renamed to ROOT.war. (e.g. /dist/app_test.war)

Note: This value should match the value specified for the 'Project App root' input.

text:  /

For the provided sample application:
text: /home/webapps

Database Schema Name Name of the MySQL database to which applications on the server will connect. It is also used to set up the application server's database configuration file.

text:  my_db_schema

For the provided sample application:
text: yourName_schema

DB_MYSQL

Input Name Description Example Value
MySQL Version Specify the version of the MySQL database that the application servers will connect to. (e.g. 5.1, 5.5) text:  5.1

DB

Input Name
Description
Example Value

Database Application Password

Database Application Username

Database username and password to add to the MySQL database server for application access.

cred:  DBAPPLICATION_USER

cred:  DBAPPLICATION_PASSWORD

Database Master FQDN

Fully qualified domain name for the master MySQL database server. Application servers use this input to locate the "master" database server.

text:  master-db.example.com

 

LB

Input Name
Description
Example Value

Load Balancer Provider

Select the type of load balancer (or service) that the application server(s) will connect to. 

  • lb_haproxy - Dedicated load balancer servers launched with RightScale's HAProxy "Load Balancer" ServerTemplate
  • lb_elb - Amazon Elastic Load Balancing (ELB) service
  • lb_clb - Rackspace Cloud Load Balancing (CLB) service

text:  lb_haproxy

For the provided sample application:
text:  lb_haproxy

Virtual Host Names

If you are using an HAProxy load balancer ('lb_haproxy'), specify the virtual host name that will be used by the application server to connect to the correct load balancer server. 

Note: A load balancer can have multiple virtual host names. If a load balancer is serving requests to multiple virtual host names, the virtual host name that the application server will use must be included in the list otherwise it will connect to the "default" virtual host name, which is the first one in the list.

text:  default

For the provided sample application:
text:  default

Load Balance Service ID

Load Balance Service Secret

For CLB, specify the Rackspace username and API key to use for authentication purposes.

For ELB, specify the Amazon access key ID and secret access key for authentication purposes.

cred: RACKSPACE_USERNAME
cred: RACKSPACE_AUTH_KEY

cred: AWS_ACCESS_KEY_ID
cred: AWS_SECRET_ACCESS_KEY

Load Balance Service Name The name of the Amazon Elastic Load Balancer (ELB) or Rackspace Cloud Load Balancer (CLB). text: my-lb-name
Load Balance Service Region

Note: Input only applies to a Rackspace Cloud Load Balancer (CLB).

For a CLB, select the Rackspace region of the Cloud Load Balancer. It's recommended that you create your CLB in a region as close to your application servers as possible.

  • ORD (Chicago)
  • LON (London)
  • DFW (Dallas/ Ft. Worth)
text: ORD

REPO

The values that you use for the repository inputs will depend on where the application code will be retrieved from. The selection for the Repository Provider input will determine which inputs will be used to retrieve the application. Unrelated inputs are ignored.

ALL Repositories (ROS, Git, SVN)

The following inputs are used to retrieve the application from either a Git/SVN software repository or an ROS location (Amazon S3 bucket or Rackspace Cloud Files container). Specify the appropriate inputs based upon the selection for the 'Repository Provider' input.

Input Name
Description
Example Value
Project App root

The destination location where the application code will be placed on the local instance. If you want the application code to be placed in the root directory, use a forward slash (/) otherwise you will need to specify the full path (e.g. /path/to/code). If set to 'ignore' the default location (/home/webapps) will be used. The 'Application Name' input is used to name the destination folder into which the application code will be placed. Apache and Tomcat will look for the application in the specified path.

Note: This value should match the value specified for the 'War file for ROOT' input.

text:  /home/webapps

For the provided sample application:
rext:  /home/webapps

Repository Provider

Specify where the application code should be checked out from.

  • repo_git - Git repository
  • repo_svn - SVN repository
  • repo_ros - Remote Object Store. (Amazon S3 or Rackspace Cloud Files) Select this option to download a tarball (.tgz) of your application code.

text:  repo_ros

For the provided sample application:
text:  repo_git

Action

Specify how the application code will be pulled from the specified repository.

  • pull - standard repository pull
  • capistrano_pull - standard repository pull plus a capistrano deployment style is applied.

text:  pull

For the provided sample application:
text:  pull

Git Repository

Important!
If you are checking out code from a Git repository, specify values for the following inputs.

Input Name
Description
Example Value
Git SSH Key In order to check out application code from a private (not public) Git repository, you must provide the repository's SSH key (e.g. Git SSH Key) for authentication purposes. Set to 'ignore' if you are using an application in a repository that allows 'public-read' access.

cred:  GIT_SSH_KEY

For the provided sample application:
inherit:  no value to inherit

Repository URL The URL that points to the location of the repository that contains the application code. Specify a "read-only" URL. (e.g. git://github.com/username/myapp.git) 

text:  git://github.com/username/myapp.git 

For the provided sample application:
text:  git://github.com/rightscale/examples.git

Branch/Tag

The specific branch/tag/SHA of the specified Git repository that the application code should be checked out from. (e.g. mybranch) Use "master" to retrieve the master branch from the repository.

text:  mybranch

For the provided sample application:
text:  unified_tomcat

SVN Repository

Important!
If you are checking out code from a SVN repository, specify values for the following inputs.

Input Name
Description
Example Value
Repository URL The URL that points to the location of the repository that contains the application code. Specify a "read-only" URL. (e.g. https://mysvn.net/app)

text:  https://mysvn.net/app

SVN Password

SVN Username 

The username and password required to access and retrieve the application code from the specified SVN repository.

cred:  SVN_USER

cred:  SVN_PASSWORD

Branch/Tag The specific branch or tag of the specified SVN repository that the application code should be checked out from. (e.g. mybranch) Use "trunk" to retrieve the main branch from the repository. text:  mybranch
Remote Object Storage (ROS)

Important!
If you are checking out code from a Remote Object Storage (ROS) location, specify values for the following inputs.

Input Name
Description
Example Value
ROS Container

The name of the Remote Object Storage (ROS) container where a tarball (.tgz) of the application code will be retrieved from.

  • Amazon S3 - bucket name
  • Rackspace Cloud Files - container name
  • SoftLayer Object Storage - container name
text:  my-container

ROS Prefix

The prefix that will be used to locate the correct tarball of the application. For example, if you're using 'myapp.tgz' specify 'myapp' as the ROS Prefix.

text:  myapp

ROS Storage Account ID

In order to retrieve a tarball of the application code that's a "private" object within the specified Remote Object Storage (ROS) location, you must provide proper cloud authentication credentials. For security reasons, it's recommended that you create and use credentials for these values instead of entering the text value.

  • Amazon S3 - Amazon Access Key ID (e.g. cred: AWS_ACCESS_KEY_ID)
  • Rackspace Cloud Files - Rackspace login username (e.g. cred: RACKSPACE_USERNAME)
  • SoftLayer Object Storage - SoftLayer Account ID (e.g. cred: SOFTLAYER_USER_ID)
text:  AWS_ACCESS_KEY_ID
ROS Storage Account Provider

 

The Remote Object Storage (ROS) service where the tarball of the application code will be retrieved from.

  • s3 - Amazon S3 
  • cloudfiles - Rackspace Cloud Files (United States)
  • cloudfilesuk - Rackspace Cloud Files (United Kingdom)
  • SoftLayer_Dallas - SoftLayer's Dallas (USA) cloud
  • SoftLayer_Singapore - SoftLayer's Singapore cloud
  • SoftLayer_Amsterdam - SoftLayer's Amsterdam cloud
text:  S3
ROS Storage Account Secret

In order to retrieve a tarball of the application code that's a "private" object within the specified Remote Object Storage (ROS) location, you must provide proper cloud authentication credentials. For security reasons, it's recommended that you create and use credentials for these values instead of entering the text value.

  • Amazon S3 - AWS Secret Access Key (e.g. cred: AWS_SECRET_ACCESS_KEY)
  • Rackspace Cloud Files - Rackspace Account API Key (e.g. cred: RACKSPACE_AUTH_KEY)
  • SoftLayer Object Storage - SoftLayer Authentication Token (e.g. cred: SOFTLAYER_API_KEY)
cred:  AWS_SECRET_ACCESS_KEY

WEB_APACHE

Input Name
Description
Example Value
Application Name

On your application servers, the server subdirectory where your application code files are stored.

If you are using dedicated load balancer servers launched with RightScale's "Load Balancer with HAProxy" ServerTemplate, this value must match the Application Name input for your load balancer servers.

text:  myapp
Multi-Processing Module Set to "worker" for a Tomcat application server. text:  worker

Launch the Server

After configuring your inputs, launch all of the Tomcat application servers. Refer to the instructions in Launch a Server if you are not already familiar with this process.


Test the Deployment

Once all of the servers are operational you can perform the following tests.

Check the Landing Page

If you set up your DNS records and firewall permissions (e.g. security groups) correctly, incoming web requests to your hostname (e.g. www.example.com) will be sent to the Elastic Load Balancer, which will establish a connection with one of the connected application servers.

Based on your DNS records, enter the hostname (FQDN) associated with your load balancer servers into a browser window. (e.g. www.example.com) You should see your application's default landing page. If you are using the sample application from RightScale, you should see the following landing page.

screen-RSLandingPage-v1.png

 


Next Steps

Set up an Autoscaling Application Tier

To replace the static application servers in the deployment (under the deployment's Servers tab) with a scalable server array for dynamically autoscaling the application tier, follow the Add a Scalable Application Server Array to a Deployment tutorial.

Safely Shutdown the Servers

If you completed the tutorial for testing purposes and no longer need the running servers, follow the steps below to safely shutdown the deployment.

  1. Delete or change the DNS A records that point to the ELB load balancing service.
  2. Delete the Elastic Load Balancer.
  3. Terminate the Master and Slave Database Servers. (If you are using volumes, see Terminate Database Servers for proper instructions.)
  4. Terminate the application servers.
  5. Delete the deployment if you do not plan to relaunch the servers in the deployment again.

You must to post a comment.
Last modified
15:29, 24 May 2013

Tags

Classifications

This page has no classifications.

Announcements

None


© 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.