Tomcat FrontEnd Server
Objective
To create a basic TomCat deployment using RightScale's TomCat FrontEnd ServerTemplate.
Table of Contents
Prerequisites
- This tutorial only applies to RightScale accounts using one of the paid editions. If you have a free edition account and would like to upgrade, please contact sales@rightscale.com.
- Before you begin this tutorial, you should have already completed the Deployment Setup and MySQL Database Setups tutorials. (This tutorial concentrates on the front end of a deployment. Although it requires a configured and running MySQL back end database, it does not matter if it a MySQL-S3 or MySQL-EBS setup. The required Input parameters and screenshots may vary accordingly.)
Overview
The tutorial will show you how to configure a 4-instance setup with two load balanced frontends and a redundant MySQL database backend. After you have completed this initial setup, we will show you how to customize your deployment to fit your particular needs.
In order to create a high-availability loadbalanced webserver solution on EC2 we have created front-end ServerTemplates that run HAProxy. This is a high-reliability software load balancer that automatically checks the health of your application and decides whether to forward traffic to a particular server based on these health checks. To provide extra functionality, we also run Apache in front of HAProxy, which allows you to serve static pages locally and establish SSL connections with only a slight increase in latency. To the right is a conceptual overview of the flow of user traffic.
As you can see, user traffic comes into your application through Apache on port 80. Apache decides which pages to serve directly and which pages to forward to HAProxy (on port 85 by default). Since HAProxy has a list of application servers and is constantly performing health checks, it knows which servers are available to handle requests. It then proxies these requests to an appropriate server. Once an application server receives the request, it generally communicates with the backend database.
This tutorial will show you how to setup the minimum deployment requirements for a high availability site. The setup consists of a redundant Master/Slave MySQL setup and a pair of loadbalanced frontends that also serve as application servers. See the diagram below for details.
Steps
Note: Ignore the revisions of the ServerTemplates and scripts in the screenshots below. As a best practice, always import the latest revision of the specified component that's available in the MultiCloud Marketplace for a given Compatibility Release (e.g. 11H1).
Import the ServerTemplate
The first step is to import the ServerTemplate that you're going to use to configure your Front End Servers.
Go the RightScale Component MultiCloud Marketplace. (Design -> MultiCloud Marketplace) Find and import the most recent version of the "Tomcat6 Front End" ServerTemplate to your account's 'Local' collection.
Customize ServerTemplate to get Application
By default, the ServerTemplate is designed to pull your application code from an SVN repository. However, you can use a different script to pull your application code from a tarball stored in an S3 bucket. Depending on the script that will be used to retrieve your application, different inputs will need to be defined.
SVN Repository
No changes to the ServerTemplate are required.
S3 Bucket
To pull the application code from an S3 bucket, you will need to modify the ServerTemplate's list of Boot Scripts so that it pulls the application code from an S3 bucket instead of an SVN repository. To make this change, you will need to replace the ServerTemplate's code checkout scripts.
- Import the "WEB Application s3 code checkout" RightScript from the MultiCloud Marketplace
- Go to the Scripts tab of the cloned ServerTemplate
- Under the Boot Scripts section, click the Add Script button, and add the "WEB Application s3 code checkout" RightScript. (Tip: Publisher is "RightScale")
- Drag and Drop the newly added script from the bottom of the list so that it's below the "WEB Application svn code checkout" RightScript.
- Delete the "WEB Application svn code checkout" RightScript.
Add FrontEnd Servers to the Production Deployment
Go to the ServerTemplate that you're going to use to create your Servers and click the Add to Deployment button.
Select the cloud where the Server will be launched. (e.g. AWS US-East)
- Deployment - Select the "Production" Deployment.
- ServerTemplate - Keep the [Inherit from ServerTemplate] option.
- Cloud - Selected cloud will be displayed.
- MultiCloud Image - Keep the default [Inherit from ServerTemplate] option or select a specific MCI that you would like to use.
- Nickname - Provide a nickname for the Front End Server that you're going to create. (e.g. my-fe1)
- Instance Type - Keep the default [Inherit from MultiCloud Image] option or select a supported instance type based on the selected MCI.
- SSH Key - Select the SSH Key that will be used by the Server. Select your "Production" SSH Key.
- Security Group - Select the Security Group that will be used by the Server. Select your "Production" Security Group.
- Availability Zone - Select which Availability Zone the instance will be launched in. Add the first Front End Server into the same availability zone as your Master-DB server.
- Elastic IP - Since this is a public facing Front End Server, select the first Elastic IP that you reserved earlier in the Create Elastic IPs (EIP) tutorial.
For high availability purposes you should have two Front End Servers across two different availability zones. The easiest way to create another Front End Server is to simply clone the first one that you just created.
Click on the nickname link of the Front End Server that you just created. Click the Clone button.
Change the following information on your cloned Server:
- Rename the Server (e.g. my-fe2)
- Change the Availability Zone so that it matches the zone of the Slave-DB (e.g. us east-1b)
You should now have four Servers in your Production Deployment. The Deployment now has all two tiers spread across two different availability zones for failover and recovery purposes. For example, if there is a failure in one zone, you still have a running server of each tier running in another zone.
If you chose to use a cloned ServerTemplate that you modified to create the Front End Servers, you may notice that you're using Server that are using HEAD versions. It's useful to use HEAD versions for development and test purposes. However, once you deploy Servers in a production environment, you should always commit the ServerTemplates and use static "locked down" revisions.
Define Inputs
Depending on whether you're pulling your application code from an SVN repository or an S3 bucket, you will need to define different inputs. As a best practice, you should define these missing inputs at the Deployment level so that these same values will be inherited by any additional Application Servers that are launched in the Deployment or Server Array.
Now you need to define the Input parameters for your Deployment. Click on the deployment's Inputs tab. As a best practice, we recommend defining Input parameters at the Deployment level.
By defining Inputs at the Deployment level, you can view and define all Input parameters that need to be set for all Servers in your Deployment in one place. Use the following guidelines to help you properly configure inputs.
- Novice users should read Understanding Inputs.
- View Input Types for descriptions of each type. (Ignore, Env, Text, Array, Cred, Key)
- View List of Environment Inputs to see an exhaustive list of all Environment Inputs ("Env").
- As a general guideline to determine what Inputs you will need to edit:
- Manage > Deployments > YourDeployment > Inputs
- Look over all the Inputs, paying particular attention to "unset" Inputs (although in some instances you may need to override values set at the ServerTemplate level). See Inheritance of Inputs.
- Input names preceded with "OPT_" usually indicate an optional Input, and you may be able to leave it blank.
Notice that most inputs already have default values that were set at the ServerTemplate level. Inputs will be inherited from a ServerTemplate unless they are defined at the Deployment or Server level.
When you are ready to set your Input values, click Edit. Once you have configured all of the Inputs click Save.
Use the input's hover text 
to view its description and determine what value should be set.
SVN Repository
- APPLICATION
- DB_SCHEMA_NAME - Be sure to use the same value that you used for this input when you created your volumes so that the Application will be able to connect to the appropriate database.
- HEALTH_CHECK_URI - If you do not have a Health Check page, select 'ignore'.
- LB_HOSTNAME
- SVN_APP_REPOSITORY
- WEBSITE_DNS
S3 Bucket
- APPLICATION
- APPLICATION_CODE_BUCKET
- APPLICATION_CODE_PACKAGE
- AWS_ACCESS_KEY_ID
- AWS_SECRET_ACCESS_KEY
- DB_SCHEMA_NAME - Be sure to use the same value that you used for this input when you created your volumes so that the Application will be able to connect to the appropriate database.
- HEALTH_CHECK_URI - If you do not have a Health Check page, select 'ignore'.
- LB_HOSTNAME
- WEBSITE_DNS
Warning: If you want HAProxy to perform health checks on your web site, remember to include the health-check file in your application bundle. If you do not do this, you will receive errors similar to the following in your log file:
"GET /health_check.jsp HTTP/1.0" 404 1003 "-" "-"
For more information on this, please see the Health Check Page.
Launch the Servers
Now that you've defined all of the required Input parameters, you are now ready to launch the Servers. Since you defined all of the required inputs at the Deployment level, you can launch both of them at the same time.
Go to the Deployment's Servers tab. Check the Front End Servers and use the Launch action.
- © Copyright 2015 RightScale Technical Support