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 a PHP 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
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.
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.
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.
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.
You will need to create DNS records for the database servers and a CNAME for the Elastic Load Balancer:
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.
Prerequisites: Requires 'designer' user role privileges in the RightScale account to create a new credential.
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.
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.
* 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.
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.
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).
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.
Download application source code from rsync sources.
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.
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 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.
Follow these steps to add a database server to the deployment.
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.
|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|
|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|
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.
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.
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.
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.
|Input Name||Description||Example Value|
|Restore Lineage||The lineage name to restore backups.||text: mysql_test_lineage|
Create a slave server in your deployment.
Make sure the following conditions are true before you launch the second database server.
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.
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.
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.
If you want to test the status of the "master" and "slave" database servers, see Check Database Status of Master or Slave.
Follow these steps to add a load balancer server to the deployment.
The next step is to define the properties of your application 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.
|Application Name||The name of the application. This name is used to generate the path of the application code and to determine the backend pool in a load balancer server that the application server will be attached to. Application names can have only alphanumeric characters and underscores.||text: example|
Application Repository URL
The repository location to download application code..
|Application Repository Revision|| |
The revision of application code to download from the repository.
|Virtual Host Name/Path||The virtual host served by the application server. The virtual host name can be a valid domain/path name supported by the access control lists (ACLs) in a load balancer. Ensure that no two application servers in the same deployment having the same application name have different vhost paths. Example: http:://www.example.com, /index||text: http://www.example.com, /index|
Now that you have finished defining server details, you are ready to launch a server in the cloud with the new settings. Click the server's Launch button.
Review the inputs that you set at the Inputs confirmation page and click Launch.
Once all of the servers are operational you can perform the following tests.
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.
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.
If you completed the tutorial for testing purposes and no longer need the running servers, follow the steps below to safely shutdown the deployment.
© 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.