3 Tier Deployment (11H1)

Create Cloud Resources

Use the following instructions to create a security group, an SSH key, and the Elastic IPs (EIPs) necessary for this tutorial. Collectively these are referred to as cloud resources.

Important! You must create the cloud resources in the specific AWS region (e.g. US East, US West, ect.) where you will launch your servers. This tutorial uses the US-East region.

First, you need a security group. You can use an existing one (if you have one) or simply create a new one.

Important! You must create the following cloud resources (security group, SSH key, and Elastic IPs) in the specific AWS region (e.g. US-East, US-West, etc.) where you will launch servers. In this tutorial, we launch servers in the US-East region.

Create Your Security Group

To create your security group, see Create a New EC2 Security Group.

Tips:

• Initially, use a single security group. If you are interested later, you can modify your deployment to use a layered security group approach to increase security.
  Note: Using a single security group is not considered a best practice for a production environment. In a production environment, the best practice is to create different security groups for each layer of your web architecture.
• Open the following ports: 22 (SSH) and 80 (HTTP). Use 0.0.0.0/0 CIDR notation for both ports. Optionally, you can also open port 443 for SSL (HTTPS) communication.
• Enable ICMP so that you can run ping tests. Use Type: -1 and Code: -1 for IPs 0.0.0.0/0.
  Note: Leaving ICMP enabled in a production environment is not recommended as this protocol presents a potential security risk.

After you have created your security group, add it to itself for all protocols (TCP/UDP/ICMP) and ports.
Important! When you add a security group, you must manually enter the name of the security group. Do not use the default name. In this case, the name is going to be the name of the new security group you are creating. You cannot achieve the same results using the “default” group. For more information, see Add a Security Group to Itself.

In the following example, the security group name is “production” and it has the following port permissions. The final list of permissions for your security group should look similar.

Create a new SSH Key

If you don’t have one already, you need to create a new SSH key. Even if your deployment uses strictly RightLink-enabled images, which do not require SSH to communicate, you need to use SSH to connect to your servers for testing and debugging purposes during this tutorial.

To create your SSH Key, see Create an SSH Key.

Create Elastic IPs

You will need two Elastic IP Addresses (EIPs) for your front-end load balancers. Name the EIPs appropriately (‘my-lb1’ and ‘my-lb2’). Be sure to record your EIP names and the associated IP addresses. You’ll need this information later in the tutorial.

To create your EIPs, see Create Elastic IPs (EIP)

Create S3 Buckets

Create two S3 buckets, one for the sample application file and one for your database dump file (and subsequent snapshots). Later in the tutorial, you will configure the Inputs for your ServerTemplates to point to these files. When servers are launched from the ServerTemplates, the servers access the files and create application and database servers.

To create the S3 buckets, see Create a New S3 Bucket.

Download the Sample Application and Database Files

To download the sample application and database dump file, click the following links. Make sure that the filenames are not modified by your operating system or browser when you download and save the files. Sometimes, extra characters are added to the filenames or the file extensions are changed or missing. The files must have the correct names to work.

• Sample PHP application: myapp.tgz
• MySQL database dump file: myapp_prod_dump-200804161345.gz

Upload the application and database files

Upload the application and database dump files to their respective S3 buckets. After you upload a file, you need to refresh the browser window to view the file in the S3 bucket.

Note: When you upload a file to an S3 bucket, its access permissions are automatically set to “private” and can only be accessed with your AWS account credentials. Our scripts can use your AWS account credentials to access the files if they are located inside your AWS account buckets, even when the files are “private”. However, if you are using files stored in S3 buckets that do not belong to your AWS account, you must change the file permissions to “public-read”. You can do this by updating the file permissions from the drop-down menu.

Configure Your DNS Records

The 11H1 ServerTemplates support the use of multiple DNS solutions including DNSMadeEasy, DynDNS, and Route 53. The information required for your ServerTemplates varies depending on the DNS solution you choose. The instructions that follow are for DNSMadeEasy. However, you can use these same steps to configure one of the other providers.

First, log into your DNSMadeEasy (DME) account.  Then use the following information to create “A Records” for your Master and Slave Database Server and for your two Load Balancers.

For your Master Database Server:

• Create an A Record and name it something simple. For example, your initials followed by “masterdb” (e.g. John Doe would be “jd-masterdb”).
• Give the record any legal, temporary IP address (e.g. 1.2.3.4). The actual value doesn’t matter since it is only a placeholder address that will be replaced later. 
• Set the time-to-live (TTL) to 60 seconds (e.g. TTL=60).
• Be sure to check the Dynamic DNS option. This allows the RightScripts to dynamically replace the temporary IP address (1.2.3.4 set above) with the actual IP address of the cloud server after it boots up.
• Leave the password blank (if prompted).
• Double click on the name of your newly-created A record and record the DDNSID of the Master Database Server.
   

For your Slave Database Server:

• Name it similarly to the Master Database Server (e.g. jd-slavedb).
• Set the same parameters that you did for your Master. You can use the same temporary IP address (1.2.3.4) for this server. The IP address will be replaced in the event that you need to promote the Slave database.
• Record the DDNSID of the Slave Database Server.
   

For your first load balancer (Load Balancer One):

• Create an A Record in your domain (e.g. “my-www”). For this basic example, the fully qualified domain name would be: my-www.example.com.
• Set the IP address to the first EIP you created earlier in the tutorial. See Create Elastic IPs (EIP).
• Uncheck DDNS.
• Leave the password blank (if prompted).
• Set the TTL to 1800 (TTL=1800). Since this is a load balancer it is appropriate to use a longer TTL.

For your second load balancer (Load Balancer Two):

• Create an A Record in your domain (e.g. “my-www”). You must use the same name that you used for the first load balancer.
• Set the IP address to the second EIP you created earlier in the tutorial. See Create Elastic IPs (EIP).
• Uncheck DDNS.
• Leave the password blank (if prompted).
• Set the TTL to 1800 (TTL=1800). Since this is a load balancer it is appropriate to use a longer TTL.
   

Important! The only difference between the records for the Load Balancers is that the records have different Elastic IPs (EIPs).

The final records should look similar to the following screenshot.

Configure RightScale Credentials

Create the Credentials from the following list in the RightScale Credentials store. Creating Credentials is very simple to do (Design > Credentials), but quite easy to get wrong by entering the wrong values or by misusing the Credentials later on in this tutorial. Incorrect Credential names or values are common errors.

To create your Credentials, follow the instructions in Create Credentials for Common Inputs. Refer to the following table for guidance on setting the Credential values correctly.

Warning! The following values are examples only. Please provide your own unique values for these credentials to avoid using identical credentials as other users of this tutorial.

• DBAPPLICATION_USER - Enter the username that the application uses to access the database. For the example application in this tutorial, set this to "1234".
• DBAPPLICATION_PASSWORD - Enter the password that the application uses to access the database. For the example application in this tutorial, set this to "1234".
• DNS_USER - Enter the username that is used to access your DNS records with your chosen DNS solution.
• DNS_PASSWORD - Enter the password that is used to access your DNS records with your chosen DNS solution.

• DBADMIN_USER - Enter the username of the database administrator. For the example database in this tutorial, set this to "admindb."
• DBADMIN_PASSWORD - Enter the password of the database administrator. For the example database in this tutorial, set this to "admindb."
• DBREPLICATION_USER - Enter the username used for database replication. The ServerTemplates use this value later. For the example database in this tutorial, set this to "dbrpl."
• DBREPLICATION_PASSWORD - Enter the password used for database replication. For the example database in this tutorial, set this to "dbrpl."

Create the Database Servers

Database Manager with MySQL 5.0/5.1 Database Setup

Create Load Balancers

Import the RightScale Load Balancer with Apache/HAProxy - 11H1 ServerTemplate from the MultiCloud Marketplace (Design > MultiCloud Marketplace > ServerTemplates). Select the ServerTemplate for the 11H1 Compatibility Release. When possible, always read a ServerTemplate's description in the MultiCloud Marketplace. The descriptions contain helpful information.

Because you should not have to customize this ServerTemplate, there is no need to clone and rename it. Simply leave the Input values as they are, they will get set correctly later at the Deployment level.

Add two load balancers to your Deployment.

Tips:

• First you must select the cloud where you are going to launch your servers. Choose the same cloud/region where you created your SSH key,
  Elastic IP, and Security Group, otherwise you will not be able to select and use those cloud resources when defining the server
• Use the ServerTemplate you just imported
• Use the SSH Key and Security Group you created earlierUse your first EIP for one load balancer, use your second EIP for the other load balancer.
• For high availability purposes, launch the load balancers into different Availability Zones from each other. Typically, you'll want to use the same zones as the database servers so that each zone will contain a load balancer and a database server.
• Use the default settings for the rest of the settings.

Configure Inputs

Set the following inputs at the deployment level.

Application

DNS

Load Balancer

Launch the Load Balancers

Launch both of your load balancers. There should be no missing Inputs, nor should you have to override any of the Inputs.

Once the load balancers are operational, your Deployment includes:

• Operational load balancers running Apache and HAProxy on the frontend
• Operational Master and Slave Database Servers on the backend
• A Server Array for Application Servers; these servers are not yet operational
• If you check your DNS provider account, you should see the following:
  • The A Records for the database servers point to the database server’s Private IP addresses
  • The A Records for the load balancers point to the Elastic IP (EIP) addresses of the servers. In the RightScale Dashboard, the Public IP addresses of the load balancers should match their assigned EIP addresses. When an instance is first launched, it is assigned a random IP address during the boot up phase. However, once the server becomes operational, the Public IP address is assigned its specified EIP.
  • No A Records that are still pointing to placeholder IP addresses (e.g. 1.2.3.4).

Clone and Customize the Application ServerTemplate

Before you create a server array that will serve as the application tier of the 3-tier deployment, you must first customize the ServerTemplate that you will use to launch each application server in the array. In this example, we're going to use a ServerTemplate for hosting a PHP application.

Go to Design > MultiCloud Marketplace > ServerTemplates. Find and import the PHP5 App Server – 11H1 ServerTemplate. If possible, read the ServerTemplate description.

After you import the ServerTemplate, clone it so that you can make changes to its scripts. Change the name of the ServerTemplate to something descriptive, perhaps including your initials or first name.

By default, the ServerTemplate is configured to pull the application code from an SVN repository. If you are using the example application in this tutorial, we instructed you to upload the example application to an S3 bucket. Because of this, you need to make a minor change to the ServerTemplate so that it can get the application code from this location. The next steps add a new RightScript to the ServerTemplate that checks out the application code from S3. The steps also delete the default RightScript that checks out the code from SVN.

Go to Design > MultiCloud Marketplace > RightScripts. Find and import the WEB Application s3 code checkout – 11H1 RightScript.

Add the script to your ServerTemplate as a Boot Script. Drag the new S3 code checkout script and place it before the WEB Application svn code checkout – 11H1 script. To do this, use the Arrow icon that appears on the right at the end of the script line to drag and drop the script into the appropriate position.

Delete the WEB Application svn code checkout – 11H1 script from the ServerTemplate.

Create a New RightScript

After you launch the all of the servers, we recommend you perform a quick test of the load balancers to see how incoming requests are sent to the application servers in a rotating fashion.

Important: It's important that the OPT_SESSION_STICKINESS input is set to "false" in order for the test to work properly. You will set this Input when you configure the Deployment's Inputs in a later step.

To perform the load balancing test, you need to create a new RightScript that installs a few basic HTML files that are used to test your load balancers. As always, try to name things in a descriptive manner (e.g. Load Balancer Test). In the script text box, copy and paste the following Bash code snippet:

#!/bin/bash -ex
cat > /home/webapps/$APPLICATION/current/hc.html << EOF
OK
EOF
cat > /home/webapps/$APPLICATION/current/servername.html << EOF 
<html><body><center><h1>This is server <font color="blue"> 
EOF
cat /var/spool/ec2/meta-data/instance-id >> /home/webapps/$APPLICATION/current/servername.html
cat >> /home/webapps/$APPLICATION/current/servername.html << EOF 
</font></h1></center></body></html>
EOF

After you paste the code into the script text box, click the Identify action button. You should see that one Input was discovered in the code called, APPLICATION, which is actually used by other scripts and is already defined at the Deployment level. As a best practice, whenever you create a new RightScript, you should provide a helpful tooltip description for the value that should be entered for an Input (e.g. “Name of the application”). Leave the “Value type” of the script set to “Any” so that you can enter a text value when setting the Input.

Look over the RightScript to make sure the formatting looks correct. Click Save when you are ready to save your new RightScript. Since you are testing this Deployment for the first time, do not commit the script and leave it as a HEAD version so that you can make changes later if necessary.

Add your new script as a Boot Script to your ServerTemplate. Since you are adding a private script that you have not published, you will be able to find the script using the 3-column selector under the “Unpublished” category. Place your new script before the LB Application to HAProxy connect – 11H1 boot script.

Important! The placement of your script before the LB Application to HAProxy connect – 11H1 script is critical.

The cloned ServerTemplate’s Scripts tab should look like the following screenshot.

Create and configure a scalable Server Array

Now that you've customized the ServerTemplate for your Application Servers to pull the application code from an S3 bucket and added a new script for testing the load balancers at the end of the tutorial, you are ready to create and configure a Server Array for horizontally auto-scaling the application tier.

First, you need to create a new alert-based Server Array. Go to Manage > Arrays and perform the  following steps that follow.

• Use the appropriate action button from the top of the Arrays page to create the array in the correct cloud\region for your Deployment (e.g. New AWS US-East).
• Select your Deployment so that the new Server Array is associated with the correct Deployment.
   

Note: A Server Array must be associated with a particular Deployment; a Deployment can have multiple Server Arrays associated with it.

• Leave the array “inactive” for now.
• Select your cloned ServerTemplate (you will find it in the “Unpublished” category) use the cloud resources you created earlier: the same SSH Key, Security Group, and so on.
• Change the following parameters for the Server Array. Leave the rest of the parameters set to their default values.
  • Minimum = 2 servers
  • Maximum = 5 servers
  • Resize Up by = 3
  • Resize Down by = 1
  • Resize calm time = 8

Click Save when ready.

Note: You should receive a message that your server array was successfully created. However, you may also receive a warning similar to the one that follows. Receiving this message is not a problem because you are going to clean up the remaining inputs soon.

"Some of the Input parameters for boot scripts are missing. Please update them to launch instances successfully."

Now that you’ve set up how the Server Array will automatically grow and shrink, the next step is to configure when the array changes size by defining the appropriate Alert specifications. There are actually two different ways to set up auto-scaling for this example. The most important thing to keep in mind is that any server that you think needs to be able to vote for grow/shrink actions must have the appropriate Alert specifications for triggering auto-scaling. Remember, a server can inherit Alert specifications from the ServerTemplate or Server Array levels. Because you might use the cloned application ServerTemplate in other Deployments, we’re going to add the Alert specifications at the Server Array level.

You need to add two new Alert specifications to trigger auto-scaling. Under the Server Array’s Next Alerts tab, you can add your new specifications to the existing Alert specifications that were inherited from the ServerTemplate. For this tutorial, you can use the suggested parameters that follow, but when you set up your own custom Deployment, you will want to pick appropriate metrics and thresholds that make sense for auto-scaling your own application. 

• Scale Up:If cpu-0/cpu-idle.value < ‘30’ for 5 min, then vote to grow array by setting the tag to the name of your server array. The example uses the tag ‘3tier’.

• Scale Down: If cpu-0/cpu-idle.value > ‘80’ for 5 min, then vote to shrink array by setting the tag ‘3tier’.
   

The server array's Next Alerts tab should now list two new alerts and look like the following screenshot:
 

Configure Inputs

Before launching your application servers, you must set the following inputs at the deployment level.

Important!  Be sure to use the same values for inputs that you used when you set up the database servers.

Tips: 

• Remember to hover over the blue Info icon () in the Dashboard for a description of each Input.
• Although many Inputs are displayed, most of them have already been set at the ServerTemplate level. If an Input has already been set, the Dashboard shows the Input’s value, the ServerTemplate from which the value was inherited, and the RightScript(s) that use the Input.
• When making multiple edits, make sure to click Save occasionally to avoid losing your work.

Application

Cloud

Database

Load Balancer

Enable and Launch the Application Server Array

Now that you have operational load balancers on the frontend that are ready to accept requests, and master and slave database servers on the backend, you are ready to start up the server array to run your application. Typically, you might want to launch a test server before you enable the entire array. The Launch action button allows you to manually launch a single server instance into an array. If you are using this tutorial as a learning tool, simply enable the server array.

Navigate back to the top level of your Deployment and select the server array name (this will be a hyperlink). Click the Enable action link on the Info tab (see the Status field). Because you set the Server Array’s Default Min Count to 2, two new servers will be automatically launched into the array.  By default, resize actions are displayed in the Events pane.  It may take a few minutes before the new servers are actually launched because RightScale's elasticity daemon evaluates server arrays every minute or so.

After you enable the array, the Events pane should show the two servers in your array coming up. You may have to wait a few minutes before the new servers are actually launched because RightScale's elasticity daemon evaluates server arrays every minute or so.

Verify the Application Servers in the Load Balancing Pool

To see the Application Servers that are available to your Load Balancers, use SSH to log into one of the Load Balancer Servers and view the contents of the HAProxy configuration file. The configuration file is located on the servers at /etc/haproxy/haproxy.cfg.

In the RightScale Dashboard, navigate to your Deployment and click the SSH icon next to one of the Load Balancer Servers. After you are connected to the server, go to the /home/haproxydirectory (cd/home/haproxy). Use the less command to view the contents of the rightscale_lb.cfgfile (less rightscale_lb.cfg).

Scroll to the bottom of the file using the spacebar. You should see entries similar to the following for each application server in the load balancer pool.

server i-9c8859f1 10.203.85.169:8000 check inter 3000 rise 2 fall 3 maxconn 255

server i-8a8859e7 10.204.97.84:8000 check inter 3000 rise 2 fall 3 maxconn 255

Note: The file maps the AWS ID of the servers in the array to their internal, private IP addresses. If you examine the private IP addresses, you can see that traffic to these servers is routed over port 8000 (10.203.85.169:8000). To allow communication between servers, this port must be open in the Security Group to which the Server Array belongs. For the purposes of this tutorial, that’s not important since all servers are in the same Security Group and can talk to each other because you added the Security Group to itself. However, if you required additional security, you might need to take this fact into consideration. For example, you might want to create separate Security Groups for each layer in your architecture (e.g. load balancers, application servers, and database servers). This approach provides additional control and server isolation. For more information, see Configuring Multiple Security Groups for a Multi-Tiered Deployment.

Verify the HA Proxy Status

You can use the HAProxy Status page to check the status of the Application Servers in the load balancing pool. The page is located off of the main URL for the Deployment at haproxy-status (e.g. http://my-www.example.com/haproxy-status). 

When you access the page, you will see the Application Servers in the pool. The load balancers will only establish client connections with "green" application servers that have passed the health check test (HEALTH_CHECK_URI). Application servers that are highlighted in "red" will not receive any traffic because it is not in a serviceable state. For example, the server is still booting up or it was unable to properly connect to the load balancer servers because the firewall permissions are not set up properly.  

Note: The operational servers shown in the status table should have the same server IDs displayed in the servername.html page that you checked earlier.

Verify Round-Robin Load Balancing

Use the following instructions to verify that your Load Balancer Servers are properly sending requests to the Application Servers in your Server Array in a round-robin fashion.

Earlier in the tutorial you created a RightScript to install the servername.html page on each of the Application Servers in the Server Array (see Create and configure a scalable Server Array). This is a simple page that shows which server in the array is responding to the request. The servername.html page is located directly off of the main URL for your Deployment and should be something like http://my-www.example.com/servername.html. 

To test that your load balancing is working correctly and that requests are being sent to each of the servers in your array, open a browser and access the servername.html page. The page displays the unique AWS ID for the server responding to the request. Take note of the ID and then refresh your browser. Again take note of the server ID.

You should see that each page request gets handled by a different server in the array. For example, if you had two servers in the array, you might see something like the following:

• This is server i-8a8859e7
• This is server i-9c8859f1
• This is server i-8a8859e7 (...)

This test confirms thatrequests are getting routed through your Load Balancers and that responses are coming back from your Application Servers in round-robin fashion.

Note: Due to some differences in how some browsers cache pages, it's recommended that you perform this test using Firefox.

Verify which Application Servers are in the Load Balancer Pool

You can also perform a quick test using SSH to see which application servers are connected to your load balancer.

• SSH into one of the load balancers and view the HAProxy configuration file /etc/haproxy/haproxy.cfg
  • At the Deployment's show page, click on the SSH icon next to one of the load balancers.
  • Type the following UNIX commands:
    • cd /home/haproxy/
    • less rightscale_lb.cfg
• Scroll to the bottom of the return message (spacebar) and you should see entries for each application server in the load balancer pool, similar to the following:

        server i-9c8859f1 10.203.85.169:8000 check inter 3000 rise 2 fall 3 maxconn 255
        server i-8a8859e7 10.204.97.84:8000 check inter 3000 rise 2 fall 3 maxconn 255

This shows a mapping of the Resource ID of the array servers with their Internal, Private IP Address. You can see that traffic to these servers is routed over port 8000. Hence this port must be open in the security group that the server arrays belong to. For the purposes of this tutorial that's not important, since all servers are in the same security group and can talk to each other as we added the security group to itself. However, if you required additional security, you might need to take this fact into consideration. For example, you might want to create separate security groups for each layer in your site architecture (e.g. load balancers, application server, database servers) for additional control and server isolation. See Configuring Multiple Security Groups for a Multi-Tiered Deployment.

Verify Auto-scaling of Application Servers

Follow the Adding Httperf Load Tester tutorial to launch an HTTP Perf Server that you can use to send traffic to your Deployment and trigger a scale up action that will launch additional Application Servers into the Server Array. When you run the script to send traffic, be sure to set the PERF_SERVER1 Input parameter to the main URL for your Deployment (my-www.example.com).

After a few minutes of running the traffic generating script, you should start to see a scale up action in the Events pane of the RightScale Dashboard. The Events will show additional servers being added to the Server Array. Likewise, when you stop the traffic generation script, the Events pane will show servers being terminated as the array scales down.

View the Contents of the Database

• Time and interest permitting, SHH into the Master Database Server and view the contents of the database manually. To do this, use the MySQL commands in the graphic below.

  Note: Remember to use your database schema name, which may not be “photo_demo_production” as seen in the following screenshot.
   

Perform a Complete End-to-End Test

To check if the database is communicating with the Application Server correctly, create a new RightScript called ‘3TierTestScript’ and copy and paste the following PHP.

#!/bin/bash -ex
cat > /home/webapps/$APPLICATION/current/3tier.php << EOF

<html>
 <head>
  <title>Application Node and MySQL Table Viewer</title>
 </head>
<body bgcolor="#C0C0C0">

<center><h1>Instance Resource ID: <font color="blue">
EOF

cat /var/spool/ec2/meta-data/instance-id >> /home/webapps/$APPLICATION/current/3tier.php

cat >> /home/webapps/$APPLICATION/current/3tier.php << EOF
</font></h1>
EOF
cat >> /home/webapps/$APPLICATION/current/3tier.php << EOF
<center><h1>Availability Zone: <font color="blue">
EOF
cat /var/spool/ec2/meta-data/placement-availability-zone >> /home/webapps/$APPLICATION/current/3tier.php

cat >> /home/webapps/$APPLICATION/current/3tier.php << EOF
</font></h1>
EOF
cat >> /home/webapps/$APPLICATION/current/3tier.php << EOF
<center><h1>Security Group(s): <font color="blue">
EOF
cat /var/spool/ec2/meta-data/security-groups >> /home/webapps/$APPLICATION/current/3tier.php


cat >> /home/webapps/$APPLICATION/current/3tier.php << EOF
</font></h1>

<h1>Below is the contents of the Database</h1>

<?php
\$dbhandle = mysql_connect("$MASTER_DB_DNSNAME", $DBADMIN_USER, $DBADMIN_PASSWORD);
if (!\$dbhandle)
  {
  die('Could not connect: ' . mysql_error());
  }
mysql_select_db("$DB_SCHEMA_NAME", \$dbhandle);

\$result = mysql_query("SELECT * FROM phptest");
?>

<table border='1'>
<tr>
<th>ID</th>
<th>Firstname</th>
<th>Lastname</th>
</tr>

<?
while(\$row = mysql_fetch_array(\$result))
  {
  echo "<tr>";
  echo "<td>" . \$row['id'] . "</td>";
  echo "<td>" . \$row['firstname'] . "</td>";
  echo "<td>" . \$row['lastname'] . "</td>";
  echo "</tr>";
  }

echo "</table><br/>";

mysql_close(\$dbhandle);?>

<form action="insert.php" method="post" style="width:440px;">
<fieldset>
<legend>Add a Record</legend>
ID: <input type="text" name="id"><br>
Firstname: <input type="text" name="firstname"><br>
Lastname: <input type="text" name="lastname"><br>
<input type="Submit">
</fieldset>
</form><br/>


<form action="delete.php" method="post" style="width:440px;">
<fieldset>
<legend>Remove a Record</legend>
ID: <input type="text" name="id"><br>\
<input type="Submit">
</fieldset>
</form>

</center>
</body>
</html>
EOF

cat > /home/webapps/$APPLICATION/current/insert.php << EOF
<?php
\$dbhandle = mysql_connect("$MASTER_DB_DNSNAME", "$DBADMIN_USER", "$DBADMIN_PASSWORD");
if (!\$dbhandle)
  {
  die('Could not connect: ' . mysql_error());
  }
mysql_select_db("$DB_SCHEMA_NAME", \$dbhandle);

\$sql="INSERT INTO phptest (id, firstname, lastname)
VALUES
('\$_POST[id]','\$_POST[firstname]','\$_POST[lastname]')";

if (!mysql_query(\$sql,\$dbhandle))
  {
  die('Error: ' . mysql_error());
  }
echo "1 record added";
echo "<br />";
echo "<a href=\"3tier.php\">Click here to return to previous page.</a>";

mysql_close(\$dbhandle);
?>

EOF

cat > /home/webapps/$APPLICATION/current/delete.php << EOF
<?php
\$dbhandle = mysql_connect("$MASTER_DB_DNSNAME", $DBADMIN_USER, $DBADMIN_PASSWORD);
if (!\$dbhandle)
  {
  die('Could not connect: ' . mysql_error());
  }
mysql_select_db("$DB_SCHEMA_NAME", \$dbhandle);

\$sql="DELETE FROM phptest WHERE id = ('\$_POST[id]')";

if (!mysql_query(\$sql,\$dbhandle))
  {
  die('Error: ' . mysql_error());
  }
echo "1 record deleted";
echo "<br />";
echo "<a href=\"3tier.php\">Click here to return to previous page.</a>";

mysql_close(\$dbhandle);
?>

EOF

After you've pasted this into the RightScript, click the Identify action button to retrieve the Inputs.

• Enter values for the following Inputs: APPLICATION, DBADMIN_PASSWORD, DBADMIN_USER, DB_SCHEMA_NAME, and MASTER_DB_DNSNAME. The values for these are already defined for the Deployment. Refer to the Set Deployment-Level Inputs section earlier in this tutorial.
• Uncheck the box for the "_POST" Input. The "$_POST" variable in the PHP script is not an actual Input.

Then click the Save action button.

When you are ready, click the Save action button to save the new script.

Now go back to your Deployment and access the attached Server Array. Under the array’s Scripts tab, use the Any Script option to run the new RightScript on all the servers in the array. Select the script entitled “3TierTestScript” from within the Unpublished section. When prompted for the servers that you want to run the script against, select the run on all action button. The script reuses the Inputs that you've already defined so the appropriate credentials and values are automatically pre-selected on the Input confirmation screen. Click the Run action button to run the script.

Open a browser and access the 3tier.php page off of the main URL for the Deployment (e.g. my-www.example.com/3tier.php). After you access the page, refresh your browser a few times. With each refresh you should see a simple page that shows the Application Server in the array that is responding to the request as well as the contents of the database. Enter some new entries to the database and you should see the user table reflect your additions.