Home > ServerTemplates > v12.11 LTS > Supplemental > 3 Tier Deployment Setup (HAProxy-PHP-MySQL)

MindTouch
Copyright (c) 2006-2014 MindTouch Inc.
http://mindtouch.com

This file and accompanying files are licensed under the MindTouch Master Subscription Agreement (MSA).

At any time, you shall not, directly or indirectly: (i) sublicense, resell, rent, lease, distribute, market, commercialize or otherwise transfer rights or usage to: (a) the Software, (b) any modified version or derivative work of the Software created by you or for you, or (c) MindTouch Open Source (which includes all non-supported versions of MindTouch-developed software), for any purpose including timesharing or service bureau purposes; (ii) remove or alter any copyright, trademark or proprietary notice in the Software; (iii) transfer, use or export the Software in violation of any applicable laws or regulations of any government or governmental agency; (iv) use or run on any of your hardware, or have deployed for use, any production version of MindTouch Open Source; (v) use any of the Support Services, Error corrections, Updates or Upgrades, for the MindTouch Open Source software or for any Server for which Support Services are not then purchased as provided hereunder; or (vi) reverse engineer, decompile or modify any encrypted or encoded portion of the Software.

A complete copy of the MSA is available at http://www.mindtouch.com/msa

3 Tier Deployment Setup (HAProxy-PHP-MySQL)

Table of Contents
  1. 1. Objective
  2. 2. Prerequisites
  3. 3. Overview
  4. 4. Deployment Setup
    1. 4.1. Create a Deployment
    2. 4.2. Create DNS Records
    3. 4.3. Create Common Credentials
    4. 4.4. Create Cloud-specific Resources
      1. 4.4.1. Linux
      2. 4.4.2. Amazon Web Services (EC2 and S3)
      3. 4.4.3. CloudStack
  5. 5. Database Tier Setup
    1. 5.1. Upload the Database Dump File
    2. 5.2. Create a Database Server
    3. 5.3. Configure Inputs
      1. 5.3.1. Set Inputs at the Deployment Level
      2. 5.3.2. Block Device
      3. 5.3.3. DB
      4. 5.3.4. SYS_DNS
    4. 5.4. Launch the Database Server
    5. 5.5. Initialize the Master Database Server
    6. 5.6. Disable Scheduled Primary Backups
    7. 5.7. Set Up the Database
    8. 5.8. Create a Primary Backup
    9. 5.9. Enable Scheduled Primary Backups
    10. 5.10. Add a Slave Database Server
    11. 5.11. Launch the Slave Database Server
    12. 5.12. Initialize the Slave Database Server
    13. 5.13. (Optional) Update the DNS Record for the Slave Database Server
    14. 5.14. Test Database Setup (optional)
  6. 6. Load Balancer Tier Setup
    1. 6.1. Create a Load Balancer Server
    2. 6.2. Create another Load Balancer Server
    3. 6.3. Configure Inputs
      1. 6.3.1. LB
      2. 6.3.2. WEB_APACHE
    4. 6.4. Launch the Server
    5. 6.5. Configure DNS Records
  7. 7. Application Tier Setup
    1. 7.1. Prepare Application Code
      1. 7.1.1. Remote Object Storage (ROS)
      2. 7.1.2. Software Repository
      3. 7.1.3. Sample Application
        1. 7.1.3.1. Git Repository
        2. 7.1.3.2. Tarball (.tgz)
    2. 7.2. Create the Application Tier
      1. 7.2.1. Import the ServerTemplate
      2. 7.2.2. Create a Server or Server Array
    3. 7.3. Configure Inputs
      1. 7.3.1. APP
      2. 7.3.2. DB_MYSQL
      3. 7.3.3. DB
      4. 7.3.4. LB
      5. 7.3.5. PHP
      6. 7.3.6. REPO
        1. 7.3.6.1. ALL Repositories (ROS, Git, SVN)
        2. 7.3.6.2. Git Repository
        3. 7.3.6.3. SVN Repository
        4. 7.3.6.4. Remote Object Storage (ROS)
      7. 7.3.7. WEB_APACHE
    4. 7.4. Launch the Server
  8. 8. Test the Deployment
    1. 8.1. Check the Landing Page
  9. 9. Shutting Down
  10. 10. Post Tutorial Steps

Objective

To create a 3-tiered production-like deployment from scratch using ServerTemplates published by RightScale for a PHP application.

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

Table of Contents

  1. 1. Objective
  2. 2. Prerequisites
  3. 3. Overview
  4. 4. Deployment Setup
    1. 4.1. Create a Deployment
    2. 4.2. Create DNS Records
    3. 4.3. Create Common Credentials
    4. 4.4. Create Cloud-specific Resources
      1. 4.4.1. Linux
      2. 4.4.2. Amazon Web Services (EC2 and S3)
      3. 4.4.3. CloudStack
  5. 5. Database Tier Setup
    1. 5.1. Upload the Database Dump File
    2. 5.2. Create a Database Server
    3. 5.3. Configure Inputs
      1. 5.3.1. Set Inputs at the Deployment Level
      2. 5.3.2. Block Device
      3. 5.3.3. DB
      4. 5.3.4. SYS_DNS
    4. 5.4. Launch the Database Server
    5. 5.5. Initialize the Master Database Server
    6. 5.6. Disable Scheduled Primary Backups
    7. 5.7. Set Up the Database
    8. 5.8. Create a Primary Backup
    9. 5.9. Enable Scheduled Primary Backups
    10. 5.10. Add a Slave Database Server
    11. 5.11. Launch the Slave Database Server
    12. 5.12. Initialize the Slave Database Server
    13. 5.13. (Optional) Update the DNS Record for the Slave Database Server
    14. 5.14. Test Database Setup (optional)
  6. 6. Load Balancer Tier Setup
    1. 6.1. Create a Load Balancer Server
    2. 6.2. Create another Load Balancer Server
    3. 6.3. Configure Inputs
      1. 6.3.1. LB
      2. 6.3.2. WEB_APACHE
    4. 6.4. Launch the Server
    5. 6.5. Configure DNS Records
  7. 7. Application Tier Setup
    1. 7.1. Prepare Application Code
      1. 7.1.1. Remote Object Storage (ROS)
      2. 7.1.2. Software Repository
      3. 7.1.3. Sample Application
        1. 7.1.3.1. Git Repository
        2. 7.1.3.2. Tarball (.tgz)
    2. 7.2. Create the Application Tier
      1. 7.2.1. Import the ServerTemplate
      2. 7.2.2. Create a Server or Server Array
    3. 7.3. Configure Inputs
      1. 7.3.1. APP
      2. 7.3.2. DB_MYSQL
      3. 7.3.3. DB
      4. 7.3.4. LB
      5. 7.3.5. PHP
      6. 7.3.6. REPO
        1. 7.3.6.1. ALL Repositories (ROS, Git, SVN)
        2. 7.3.6.2. Git Repository
        3. 7.3.6.3. SVN Repository
        4. 7.3.6.4. Remote Object Storage (ROS)
      7. 7.3.7. WEB_APACHE
    4. 7.4. Launch the Server
  8. 8. Test the Deployment
    1. 8.1. Check the Landing Page
  9. 9. Shutting Down
  10. 10. Post Tutorial 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 groups 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. 

  • (HAProxy) Load Balancing servers
  • PHP Application servers
  • MySQL Database servers

 

diag-3tierNoArray-v1.png

Disclaimers

  • This tutorial assumes that you are launching all servers into the same cloud infrastructure. 
  • 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

Prerequisites: Requires 'actor' user role privileges in the RightScale account.

The first step is to create a new deployment for the project. It's not recommended that you use the "Default" deployment or an existing deployment for new development because you do not want to accidentally inherit any unknown configuration settings. Therefore, it's recommended to always create a new deployment when you start a new project. Be sure to use a unique and descriptive nickname for each deployment. (e.g. My Project Name)

  1. Go to Manage > Deployments. Click New and provide the following information:
    • Nickname - User-defined name for the deployment. 
    • Description - A short, internal-only description of the deployment.

Tip: Most users find it useful to create a bookmark in the left-hand pane of the dashboard that links to the deployment's Servers tab.

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.

In this type of architecure, 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.

Note: If you are using Rackspace's Cloud DNS service, you must use a TTL of 300 seconds because that is the lowest allowable TTL. Be sure to change the 'Database DNS TTL Limit' input from 60 (default) to 300.

diag-3tier_ga-v4.png

You will need to create DNS records for the following servers:

  • Each Load Balancer Server
  • 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.

Note: 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.

Note: If you are going through the 3-tier tutorial and are using the provided sample application and database files for testing purposes, use the sample "3 Tier Tutorial" values highlighted below.

  • 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 as your DNS provider, you do not need to set up separate DNS user name and password credentials because your AWS credentials are used for authentication purposes. 

Amazon S3

If you are using Amazon S3 to store binary database backups or retrieve a "private" file from an S3 bucket, you will need to use the following AWS credentials. Fortunately, these credentials are automatically created when AWS credentials are added to a RightScale account. Although, they are available for use when you define your inputs, they will not be listed under Design > Credentials.
Note: AWS credentials are located under Settings > Account Settings > Clouds.

  • 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

If you want to use Rackspace Cloud Files for storing binary database backups, you will need to create the following credentials.

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

 

SoftLayer Object Storage

If you want to use SoftLayer's Object Storage for storing binary database backups, you will need to create the following credentials. 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)

 

Source Control Management (SVN, GitHub)

If you are using a source control management (SCM) system to host your application code, you will need to create the following 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 "SSH Key" input. 
     
  • SVN_USERNAME - The SVN username that has access to the specified repository. Use this credential for the "SVN username" input.
  • SVN_PASSWORD - Password for SVN_USERNAME. Use this credential for the "SVN password" input.

 

Secure Sockets Layer (SSL)

If you are using SSL to support HTTPS access, you should create credentials for any of the following values that apply. See How do I create an SSL certificate for my web server?

  • LB_STATUS_USERNAME - Optional user name to require in order to log in to the HAProxy status report page.
  • LB_STATUS_PASSWORD - Optional password corresponding to LB_STATUS_USERNAME.
  • SSL_CERTIFICATE - Contents of the X.509/PEM-format SSL server certificate used for enabling HTTPS communications.
  • SSL_CERTIFICATE_CHAIN - The certificate authority (CA) certificate chain associated with the server certificate used to set up HTTPS communications.
  • SSL_CERTIFICATE_KEY - The SSL server certificate's private key, in PEM format.
  • SSL_PASSPHRASE - If required by an SSL certificate, you must provide the passphrase so Apache can start.

Create Cloud-specific Resources

Prerequisites: Requires 'actor' user role privileges in the RightScale account to create SSH Keys and Elastic IPs, and 'security_manager' privileges to create security groups.

Each cloud infrastructure is unique and requires different resources in order to launch a server in their cloud. Depending on the type of cloud infrastructure that you're going to use to launch servers, you will find it useful to create some of the required cloud-specific resources beforehand so that you can select them in the "Add Server Wizard" when you add servers into a deployment. Cloud resources are also cloud-specific. For example, you cannot launch an EC2 instance in the 'us-east' region with an 'us-west' security group. 

Warning!
If you are following a standard 3-tier tutorial for testing and demonstration purposes only, you can create a single security group with the following permissions. If you are building a 3-tier deployment for a production environment, you should consider using more robust security group settings. See Configure Multiple Security Groups for a Multi-Tiered Deployment.

Linux

At a minimum, the security group should contain the following firewall permissions. Note: Port 443 is only required for SSL support (HTTPS).

screen_12h1-SecGroupALL_v1.png

Amazon Web Services (EC2 and S3)

EC2

  • Create a New SSH Key You are required to select an SSH Key when you launch an EC2 instance. Although it can be used to establish a remote connection with the instance, Server Login Control is used instead.
  • Create a New EC2 Security Group Although you can use the same security group for all servers in the same region, you may want to consider creating separate security groups for each tier of your site architecture for additional security. See Configuring Multiple Security Groups for a Multi-Tiered Deployment.
  • Create Elastic IPs (EIP) If you are launching load balancer servers in EC2, it's recommended that you use Elastic IPs for your public facing load balancer servers if you're using RightScale's "Load Balancer" ServerTemplates. Typically, you will have two load balancers for redundancy purposes. You must create an Elastic IP for each load balancer.

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. 

If S3 is not activated for your AWS account, please sign-up for the service now. (http://aws.amazon.com/s3/)

CloudStack


Database Tier Setup

Upload the Database Dump File

The ServerTemplate contains scripts that can retrieve a MySQL database dump file from a Remote Object Storage (ROS) location such as an Amazon S3 bucket or a Rackspace Cloud Files container. Create a new bucket/container and upload your database dump file. The file can remain a 'private' object because your cloud credentials can be used (as inputs) for authentication purposes to retrieve the file. Make sure the uploaded file maintains the .gz file extension.

Warning! The filename of the MySQL dump file cannot contain a dash (-) in its prefix name. For example, if your dump file is named, 'my-app-201205030022.gz', you must manually rename it to be 'my_app-201205030022.gz' where you use an underscore (_) to replace the dash, otherwise the script (do::do_dump_import) that imports the database dump file into the instance will fail.


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 gzip (.gz) file.

app_test-201109010029.gz

Create a Database 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 Database Manager for MySQL 5.1 or Database Manager for MySQL 5.5ServerTemplate into your RightScale account.
  2. From the imported ServerTemplate's show page, click the Add Server button.
  3. Select the cloud for which you will configure a server. 
  4. Select the deployment for the new server.
  5. 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. SSH Key, 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.
  6. Click Confirm, review the server's configuration and click Finish to create the server.

Configure Inputs

The next step is to define the properties of your database server or servers by entering values for inputs. It is simplest and 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.

The inputs that you need to provide values for will depend on which options you're going to use. The ServerTemplate is very flexible and supports a variety of different configurations. You will need to provide the necessary values as inputs based on which options you want to use.

  • Where will the contents of the database be stored?
    • On volumes attached to the instance.
    • On the local/ephemeral drive - Ignore all "Block Device" inputs.
  • If you're using volumes, are you going to use a stripe?
    • Yes - Use a stripe of multiple volumes.
    • No - Use a single volume. 
    • INPUTS: Block Device Mount Directory (1), Nickname (1), Number of Volumes in the Stripe (1), Total Volume Size (1)
  • Are you building a master-slave database setup with replication?
    • Yes
    • No
    • INPUTS: Database Master FQDN, Database Master DNS Record ID, Database Slave FQDN, Database Slave DNS Record ID, Database Replication Password, Database Replication Username
  • What are you going to use to take "primary" backups of the database?
    • Snapshots
    • Binary Dumps to a ROS container (e.g. S3 bucket or Cloud Files container)
    • INPUTS: Backup Primary Secret (default), Backup Primary User (default), Primary Backup Storage Cloud (default)
  • Are you going take "secondary" backups of the database? If yes, which ROS provider will you use?
    • Amazon S3
    • Rackspace Cloud Files
    • INPUTS: Secondary Backup Storage Cloud (default), Secondary Backup Secret (default), Secondary Backup User (default), Secondary Backup Storage Container (1)
  • Which DNS provider are you using for dynamic DNS at the database level?
    • DNS Made Easy
    • DynDNS
    • Amazon Route 53
    • Cloud DNS
    • INPUTS: DNS Service Provider, DNS Password, DNS User

Set Inputs 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.

Rackspace only
If you use Rackspace for your database servers and backup storage (i.e., Cloud Files) the storage-related Chef recipes will use Rackspace Service Net (SNET) by default. SNET is Rackspace's internal private networking service for optimized communication between Rackspace Cloud Servers and Cloud Files. If SNET is not supported in your Rackspace environment, you must set the "Rackspace SNET Enabled for Backup" input to false; otherwise, all backup and restore operations that rely on Cloud Files will fail.

 

Block Device

If the cloud supports the use of block devices (e.g. AWS EBS Volumes, CloudStack volumes, etc.), it's strongly recommended that you use block devices to store the contents of the MySQL database. Backups of the database will be stored as snapshots.

If the cloud does not support block devices (e.g. Rackspace), you must use a Remote Object Store container (e.g. Rackspace Cloud Files container) the contents of the MySQL database will be stored locally on the instance's ephemeral drive. Backups of the database will be stored as binary dump files to the specified storage container.

Required

Input Name Description Example Value
Number of Volumes in the Stripe (1) To use striped volumes with your databases, specify a volume quantity. The default is 1, indicating no volume striping. Ignored for clouds that do not support volume-based storage (e.g. Rackspace First Generation). text:  1
Total Volume Size (1)

Specify the total size, in GB, of the volume or striped volume set used for primary storage. If dividing this value by the stripe volume quantity does not yield a whole number, then each volume's size is rounded up to the nearest whole integer. For example, if "Number of Volumes in the Stripe" is 3 and you specify a "Total Volume Size" of 5 GB, each volume will be 2 GB.

If deploying on a CloudStack-based cloud that does not allow custom volume sizes, the smallest predefined volume size is used instead of the size specified here. This input is ignored for clouds that do not support volume storage (e.g., Rackspace).

Important! The value for this input does not describe the actual amount of space that's available for data storage because a percent is reserved for taking LVM snapshots. Use the 'Percentage of the LVM used for data (1)' input to control how much of the volume stripe is used for data storage (default: 10%). Be sure to account for additional space that will be required to accommodate the growth of your database over time.

text:  10
Percentage of the LVM used for data (1) The percentage of the total Volume Group extents (LVM) that is used for data storage. The remaining percent is reserved for taking LVM snapshots.  (e.g. 90% for data storage and the remaining 10% for overhead and snapshots)

WARNING: If the database experiences a large amount of writes/changes, LVM snapshots may fail. In such cases, use a more conservative value for this input. (e.g. 50%) Be sure to adjust the 'Total Volume Size (1)' input accordingly.
text: 90%

 

Optional

Input Name Description Example Value

Primary Backup Secret (default)

Required cloud credential to store a file in the specified ROS location. If you are using Amazon EC2, leave this value set to "No value/Ignore" because primary backups will be saved as snapshots.

  • Amazon S3 - No value/Ignore
  • 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)
  • swift - Authentication Token (string)

No value/Ignore

cred:  RACKSPACE_AUTH_KEY

Primary Backup User (default)

Required cloud credential to store a file in the specified ROS location. If you are using Amazon EC2, leave this value set to "No value/Ignore" because primary backups will be saved as snapshots.

  • Amazon S3 - No value/Ignore
  • Rackspace Cloud Files - Rackspace login username (e.g. cred: RACKSPACE_USERNAME)
  • SoftLayer Object Storage - SoftLayer Account ID (e.g. cred: SOFTLAYER_USER_ID)

No value/Ignore

cred:  RACKSPACE_USERNAME

Secondary Backup Storage Cloud (default)

 

The cloud provider of the specified ROS container where the secondary backup will be stored.

  • 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:  cloudfiles

Secondary Backup Secret (default)

Required cloud credential to store a file in the specified ROS location.

  • 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)
  • swift - Authentication Token (string)

cred:  AWS_SECRET_ACCESS_KEY

cred:  RACKSPACE_AUTH_KEY

Secondary Backup User (default)

Required cloud credential to store a file in the specified ROS location. 

  • 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)

cred:  AWS_ACCESS_KEY_ID

cred:  RACKSPACE_USERNAME

Secondary Backup Storage Container (1) Name of Amazon S3 bucket or Rackspace Cloud Files container to use for secondary backups. text:  mysqlbackups
Block Device Mount Directory (1) For cloud providers supporting volume-based storage, the mount point for your backup volume or volumes. (Default is /mnt/storage.) Ignored for clouds that do not support volume-based storage (e.g. Rackspace). text:  /mnt/storage
Nickname (1) For cloud providers supporting volume-based storage, the nickname will be used to name the created volumes and snapshots along with an epoch timestamp. (e.g. data_storage-201203100927) By default, this input is set to 'data_storage' however it's recommended that you create a nickname that describes your application or deployment, which will make it easier to identify the created volumes and snapshots. This input is ignored for clouds that do not support volume-based storage (e.g. Rackspace). text:  my_deployment

DB

Input Name Description Example Value

Database Admin Password

Database Admin Username

Username and password of a database user with administrator privileges. The admin username and password are used for tasks that require administrator access to the database.

cred:  DBADMIN_PASSWORD

cred:  DBADMIN_USER

Database Application Password

Database Application Username

Username and password of a database user with user-level privileges. The application username and password allow the application to access the database in a restricted fashion.

cred:  DBAPPLICATION_PASSWORD

cred:  DBAPPLICATION_USER

Database Backup Lineage

The name associated with your primary and secondary database backups. It's used to associate them with your database environment for maintenance, restore, and replication purposes. Backup snapshots will automatically be tagged with this value. (e.g. rs_backup:lineage=mysqlbackup) Backups are identified by their lineage name.

Note: For servers running on Rackspace, this value also indicates the Cloud Files container to use for storing primary backups. If a Cloud Files container with this name does not already exist, one will automatically be created.

text:  mysqlbackup
Database Master FQDN Fully qualified domain name for the master database server. text:  master-db.example.com
Database Master DNS Record ID

The record ID or hostname used to identify your master database server to your DNS provider. See Deployment Prerequisites (Linux) for more information.

Examples:

  • DNSMadeEasy: 1234567  (Dynamic DNS ID)
  • Route53: Z3DSDFSDFX:master-db.example.com
  • DynDNS: db-master.example.com
  • CloudDNS: 3334445:A-1234567  (<Domain ID>:<Record ID>)
text:  1234567
Database Slave DNS Record ID (Optional) The record ID or hostname used to identify your slave database server to your DNS provider. See Deployment Prerequisites (Linux) for  more information. text:  2233445

Database Replication Password

Database Replication User

Username and password of a database user with replication permissions on the MySQL server. The replication username and password are used for replication between the "master" and "slave" database servers.

cred:  DBREPLICATION_PASSWORD

cred:  DBREPLICATION_USER

Database DNS TTL Limit The specified TTL limit of the database servers' dynamic DNS records. It's recommended that you use a low TTL for your database servers DNS records to promote quick failovers. The default is set to 60 (seconds). If you are using Rackspace's CloudDNS service for Rackspace cloud servers, set this value to 300 (which is the lowest allowable TTL for CloudDNS).

text: 60

text: 300 (CloudDNS only)

SYS_DNS

Input Name Description Example Value
DNS Service Provider

Select the DNS provider that you used to create the DNS records for the database servers.

  • DNSMadeEasy
  • DynDNS
  • Route53 (Amazon Route 53)
  • CloudDNS
text:  DNSMadeEasy
DNS Password

The password used to log into your DNS provider. 

  • DNSMadeEasy - DME Password
  • DynDNS - DynDNS Password
  • Amazon Route 53 - AWS Secret Access Key
  • Rackspace CloudDNS - Rackspace Password
cred:  DNS_PASSWORD

DNS User

The username used to log into your DNS provider. 

  • DNSMadeEasy - DME Username
  • DynDNS - DynDNS Username
  • Amazon Route 53 - AWS Access Key ID
  • Rackspace CloudDNS - Rackspace Username

cred:  DNS_USER

CloudDNS region

If 'CloudDNS' is the chosen 'DNS Service Provider', select the appropriate cloud region based on the location of the Rackspace cloud servers.

Note: This input is ignored unless you are using CloudDNS.

text:  Chicago

Launch the Database Server

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

  1. Go to the deployment's Servers tab and launch the database server. When you view the input confirmation page, there should not be any required inputs with missing values.  If there are any required inputs that are missing values (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. Because there are no required inputs that are missing values for any boot scripts, you can click the 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 you run a script to initialize the database server.

  1. Go to the "current" server's Scripts tab and run the db::do_init_and_become_master operational script to initialize it as the "Master" database server.
    screen-InitBecomeMaster-v2.png
  2. You can go to the "current" server's Audit Entries tab to track the status of the operation.


The script performs the following actions:

  • Registers it as the "master" database server and assign appropriate replication privileges.
  • For cloud providers with volume support, create and mount either a single volume or group of striped volumes for data storage.
  • Creates a database backup to primary storage.
  • Schedules a cron job to run backups to primary storage once per day on the server. (For information on modifying the default backup schedule, see the Database Manager for MySQL 5.1/5.5 Runbook.)
  • Updates the dynamic DNS record for the "Master" database with your DNS provider. The DNS record will be updated with the server's private IP address. 
    Warning! If using Amazon Route 53 as your DNS provider, ensure that the TTL (time to live) is set to 60 seconds for each DNS record. Using a different TTL value will cause the db::do_init_and_become_master script to fail. If you are using Rackspace's Cloud DNS service, the DNS record's TTL and the value specified for the 'Database DNS TTL Limit' input must match. (e.g. 300)

Disable Scheduled Primary Backups

Since you have not loaded an actual database onto the server there is no reason to create a primary backup of the database.

Go to the "current" server's Scripts tab and run the db::do_primary_backup_schedule_disable operational script to disable your scheduled backups (cron jobs). 

Later, once you have imported your database you will reverse this action and enable continuous backups.

Set Up the Database

After initializing the master database server and disabling scheduled backups, you will need to add your database (or databases) and records to it.

  1. Go to the "current" server's Scripts tab and run the db::do_dump_import operational script to import a MySQL dump file from an ROS location.


Note: If you use a previous backup snapshot instead of a MySQL dump file or initialize a blank MySQL database, refer to the Database Manager for MySQL 5.1/5.5 Runbook for instructions.

Input Name Description Example Value
Dump Container Name of Amazon S3 bucket or Rackspace Cloud Files container with the MySQL dump file to import upon server startup. text:  mysqldumps
Dump Schema/Database Name

Name of the MySQL database schema to restore from the MySQL dump file identified by the "Dump Prefix" input. This name is set when you import the dump file into MySQL. The name is only defined within the MySQL instance and not within the actual dump file. As a result the name is somewhat arbitrary but should be descriptive.

Important!
Be sure to record this value. You will need to specify this value again when you set up the application server tier so that they can  connect to the correct database schema.

text:  my_db_schema
Dump Prefix

The prefix of the MySQL dump file (without the associated .gz extension) to retrieve from the Amazon S3 bucket or Rackspace Cloud Files container specified in "Dump Container." You can specify either the entire file name including the timestamp or just the file prefix without the timestamp, which selects the most recent dump file with that prefix.

Example: If your dump file is named "mydb-201112202212.gz," you could specify either "mydb-201112202212" or "mydb."

If you are using the attached sample MySQL dump file (app_test-201109010029.gz), use "app_test" as the value.

text:  app_test

Dump Storage Account ID

 

Required cloud credential to retrieve a private file from the specified ROS location. Set to 'Ignore' if the file is publicly accessible.

  • 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)

cred:  AWS_ACCESS_KEY_ID

cred:  RACKSPACE_USERNAME

 

Dump Storage Account Secret

Required cloud credential to retrieve a private file from the specified ROS location. Set to 'Ignore' if the file is publicly accessible.

  • 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)
  • swift - Authentication Token (string)

cred:  AWS_SECRET_ACCESS_KEY

cred:  RACKSPACE_AUTH_KEY

Dump Storage Account Provider

The remote object storage provider where your MySQL dump file is stored.

  • 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

Create a Primary Backup

You are now ready to create the first primary backup of the database. You will need a completed backup in order to initialize a slave database server.

  1. Go to the "current" server's Scripts tab and run the db::do_primary_backup operational script to manually generate a primary backup of your database server.

Enable Scheduled Primary Backups

It is now safe to enable continuous backups of the database server.

  1. Go to the "current" server's Scripts tab and run the db::do_primary_backup_schedule_enable operational script.


For more information about configuring and modifying your scheduled backup policy, see the Database Manager for MySQL 5.1/5.5 Runbook.

Add a Slave Database Server

Although you can run MySQL in single-server mode and having a separate slave server for replication purposes is not required, this is strongly recommended for failover purposes. 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 Slave 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. If you are using a cloud that supports snapshots for backups, 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.


You are now ready to launch a "slave" database server for failover and redundancy purposes. 

  1. Go to the deployment's Servers tab and launch the server that will be the slave database server. There should be no missing inputs. 

Initialize the Slave Database Server

Wait for the server to reach the "operational" state before initializing it as a "slave" of the master database server.

  1. Go to the "current" server's Scripts tab and run the db::do_primary_init_slave operational script.


The script performs the following actions:

  • Assigns the "slave" role to the server.
  • Uses the most recently completed database backup (default) to initially populate the database in order to reduce the time needed for the slave to become in-sync with the master.
  • Sends a request to the master server to allow connections from the slave server's private IP address and opens the default MySQL client port (TCP port 3306) on the master server's firewall (i.e., iptables) for this purpose.
  • Schedules a cron job to run primary backups of the database. 

(Optional) Update the DNS Record for the Slave Database Server

If you created a DNS record for the slave database server, you can set a value for the Database Slave DNS Record ID input and run the db::do_set_dns_slave_private_ip operational script.

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

Create a Load Balancer Server

Follow these steps to add a load balancer server to the deployment.

  1. Go to the MultiCloud Marketplace (Design > MultiCloud Marketplace > ServerTemplates) and import the most recently published revision of the Load Balancer with HAProxy ServerTemplate into the RightScale account.
  2. From the imported ServerTemplate's show page, click the Add Server button.
  3. Select the cloud for which you will configure a server. 
  4. Select the deployment into which the new server will be placed.
  5. 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 load balancer server (e.g., lb1). 
    • Select the appropriate cloud-specific resources 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 load balancer server you will use a different datacenter / zone to ensure high-availability. For more information, see Add Server Assistant.
    • If you are using Elastic IPs (AWS EC2 only), select an Elastic IP.
  6. Click Confirm, review the server's configuration and click Finish to create the server.

Create another Load Balancer Server

For production environments, it's strongly recommended that you have at least two load balancer servers (preferably in different availability zones or datacenters) for redundancy purposes. The easiest way to create a second load balancer is to simply clone and modify the first load balancer server.

  1. Go to the show page of the load balancer server that you just created and click the Clone button.
  2. Change the name of the server accordingly. (e.g. lb2)
  3. Under the Info tab, click Edit.
  4. Select a different zone/datacenter and Elastic IP (if applicable).

Configure Inputs

The next step is to define the properties of your load balancer server or servers by entering values for inputs. As a best practice, you should define required inputs for the servers 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 load balancers, open the deployment's Inputs tab, click Edit, and use the following settings to configure input values. We recommend that you set up credentials for password values and any other sensitive data as shown in the examples.

LB

Input Name
Description
Example Value
Virtual Host Names

Comma-separated list of host names for which the load balancer will answer website requests and forward to the correct backend pool of application servers. This value is used to name backend server pools. A single entry of any name, e.g. 'default' or 'applistener', will mimic basic behavior of one load balancer with one pool of application servers. 

If you are using multiple virtual host names, the first entry will be the default backend and will answer for all host names that are not listed. Typically, you will specify hostnames for each load balancing pool. (e.g. app1.example.com,app2.example.com)

Note: Application servers can only provide a single host name and will join server pool backends using this name (for example, default, www.mysite.com, api.mysite.com, default.mysite.com).

Single vhost:
text:  default

Multiple vhosts:
text: app1.example.com,app2.example.com

Health Check URI

Relative URI (resource path), including the preceding forward slash, pointing to the health-check page on your application servers. For example, /hlthchk378923.html points to the file hlthchk378923.html in the application directory on your application servers. During the testing phase, you may leave this input set to the default (/) value, indicating that health check pages are not included on the application servers.

For the DotNetNuke 3 tier example, use 'text:/Default.aspx

text:  /

Use Session Stickiness Leave this value set to "true" to enable session persistence (stickiness). In this case, the load balancer will route client requests made in the same session to the same application server, via a cookie. Set to "false" to disable session stickiness, in which case the load balancer routes each new client request to the next available application server, regardless of session.

text:  true

For the 3-tier tutorial, use:
text:  false

Status Page Password

Status Page Username

Username and password (if required) to access the HAProxy status report page, which is accessible from the URI set in Status URI.

cred:  LB_STATUS_PASSWORD

cred:  LB_STATUS_USERNAME

Status URI

Relative URI (resource path) pointing to the HAProxy status report page. If you use the default value (/haproxy-status) you can append this value to the hostname or public DNS/IP address for your load balancer to access the status report—for example, http://example.com/haproxy-status or http://192.123.123.12/haproxy-status.

text:  /haproxy-status

WEB_APACHE

Input Name
Description
Example Value
Application Name On your application servers, the server subdirectory where your application code files are stored. This must match the Application Name input for your application servers. text:  myapp
Multi-Processing Module Set to the value matching the application servers that your load balancer will connect to: "prefork" for PHP servers, or "worker" for Rails, Apache Tomcat, and stand-alone application servers. text:  prefork
SSL Certificate Contents of the X.509/PEM-format SSL server certificate used for enabling HTTPS communications.

cred:  SSL_CERTIFICATE

SSL Certificate Chain The certificate authority (CA) certificate chain associated with the server certificate used to set up HTTPS communications.

cred:  SSL_CERTIFICATE_CHAIN

SSL Enable Set to "true" to enable SSL ('https').
Set to "false" to disable SSL. (default)
text:  false
SSL Certificate Key The SSL server certificate's private key, in PEM format.

cred:  SSL_CERTIFICATE_KEY

SSL Passphrase If required by an SSL certificate, you must provide the passphrase so Apache can start.

cred:  SSL_PASSPHRASE

Launch the Server

  1. Go to the deployment's Servers tab and launch all of the load balancer servers. When you view the input confirmation page, there should not be any required inputs with missing values.  If there are any required inputs that are missing values (highlighted in red) at the input confirmation page, cancel the launch and add values for those inputs 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.

    Note: Remember that as a best practice for building high-availability sites, you should have two load balancers that you launch in different availability zones or data centers.

Configure DNS Records

If you are using Elastic IPs or already know the public IP addresses that will be used by the load balancer servers, you might have already set up the DNS records for the load balancing tier. However, if you do not know the public IP addresses that will be assigned to the load balancer servers, you must manually set up the DNS records after the servers have been launched. Once the servers become operational (and have been assigned their respective public IP addresses), create or update the DNS records with your DNS provider. Each load balancer server should have its own DNS record with the same hostname (e.g. www.example.com) that points to its public IP address.

The DNS records for the HAProxy load balancing tier should direct traffic from the associated hostname (FQDN) (e.g. www.example.com) to the application servers in its load balancing pool.


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. If the code is in a private repository, you may need to generate an SSK key (e.g. GitHub SSH Key) for authentication purposes and create a credential (Design -> Credentials) to store the sensitive value.

Sample Application

Git Repository

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

  • 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
  • Repository URL - git://github.com/rightscale/examples.git
  • Branch/Tag - unified_php
Tarball (.tgz)

If you prefer to use a tarball instead, download the file below and upload it into your own remote storage container. (e.g. S3 bucket)

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 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, click Edit, and use the following instructios to configure the 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 PHP Application Server 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

 

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_PASSWORD

cred:  DBAPPLICATION_USER

 

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 Balance 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

PHP

Input Name
Description
Example Value
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

PHP module packages To optionally install additional PHP modules besides the default PHP 5.3 packages installed by the ServerTemplate recipes, specify package names here in a comma-separated list. Package naming conventions will differ depending on your Linux distribution; for example, they include a php53u prefix for CentOS and php5 prefix for Ubuntu. text:  php53u-mysql,php53u-pecl-memcache

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 PHP will look for the application in the specified path.

text:  /

For the provided sample application:
No value / ignore

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.

For the provided sample application from ROS:
text:  repo_ros

For the provided sample application from GitHub:
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 private 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 from GitHub:
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 from GitHub:
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 from GitHub:
text:  unified_php

SVN Repository

Important!
If you are checking out code from an 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.

For the provided sample application from ROS:
text:  phptest

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 Leave this input set to the default, "prefork": the valid value for a PHP server. text:  prefork

Launch the Server

After configuring your inputs, launch all of the PHP 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 one of the load balancer servers. HAProxy will then take the request and forward it to one of the application servers in its load balancing pool.

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 PHP application from RightScale, you should see the following landing page.

screen-RSLandingPage-v1.png

 


Shutting Down

You may find the need to perform some clean up, either to minimize costs, or to perform the tutorial again from a clean slate. Follow these high level steps to do so:

  • Terminate the Load Balancers.
  • Terminate the Master and Slave Database Servers. (If you are using volumes, see the Database Manager for MySQL 5.1/5.5 Runbook for proper instructions.)
  • Delete the Deployment.
  • Delete the two EIPs (if applicable and they no longer need to be preserved)
  • Delete the one cloned ServerTemplate for the Application Servers that you created.
  • Delete the SSH Key.
  • Delete the Security Group(s).
  • Delete all Credentials (unless you are sharing your account or Deployment with others who might still be using them).
  • Delete all four DNS A records (if applicable)
  • Delete the application and database dump files from the ROS containers
  • Delete the ROS containers (e.g. S3 bucket)

Post Tutorial Steps

You must to post a comment.
Last Modified
15:18, 24 May 2013

Tags

Classifications

This page has no classifications.

Announcements

None

Glossary | 用語용어 Site Map | Site Help Community Corporate Site Get Support Dashboard Login
Doc Feedback Product Feedback Resources MultiCloud Marketplace Forums

Dashboard Status


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