Rails FrontEnd Server

Objective

To create a basic Rails deployment using the Rails FrontEnd server template.  The tutorial will show you how to configure a 4-instance setup with two loadbalanced frontends and a redundant MySQL database backend. After you have completed this intial setup, we will show you how to customize your deployment to fit your particular needs.

NOTE: This tutorial only applies to Premium accounts.  If you have a Developer account and would like to upgrade, please contact sales@rightscale.com.

Overview

pic1.gifIn order to create a high-availbility loadbalanced webserver solution on EC2 we have created front-end server templates 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 concepetual 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 avilable 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 minium 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.

pic2.gif

This tutorial is divided into 3 Steps:

Step 1: Add FrontEnd Rails ServerTemplate to the Production deployment
Step 2: Define Input parameters
Step 3: Launch the server

 

Step 1: Add FrontEnd Rails ServerTemplate to the Production deployment

Before you begin this tutorial, you should have already completed the Deployment Setup and MySQL Database Setups tutorials.

NOTE: 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 variables and screenshots may vary accordingly.

Go to Manage -> Deployments and click on the Production deployment. 

Next, we will add two frontend application servers using the same ServerTemplate. 

Click the Add Server button.

05-rails_add_server_button.gif

If you are a pay edition user, you have access to some of our premium ServerTemplates.  Select the latest Rails FrontEnd ServerTemplate from the RightScale list. Nickname the first server, FrontEnd-1. Use the production SSH key and Security Group that you already created. Select the Elastic IPs from the previous Create Elastic IPs (EIP) for each frontend.  Click Add

11-rails_launch_eip.gif

Repeat this process and add another server using the same template, but call it FrontEnd-2 and select the other Elastic IP.

You should now have two Rails FrontEnd servers and two database servers in your Production deployment.

11-rails_server_list2_eip.gif

 

Step 2: Define Input parameters

Now you need to define the input parameters for your Rails production deployment.   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. 

Click on the deployment's Inputs tab.

Although the list of inputs are listed alphabetically, it will be easier to understand how to properly set each input if we describe them together in their various groups.  In the next step we will describe each input and how to properly set the parameters.

Click Edit.  Use the links to the Inputs reference page to complete each section of input parameters.  The suggested values will be highlighted in yellow.

Input Parameters

    1. Apache 
    2. Application 
    3. AWS Credentials
    4. Database
    5. DNS
    6. EBS
    7. HAProxy
    8. Monitoring
    9. Rails
    10. Misc

Once you've configured all of the input parameters, click Save.

Below is a screenshot of the completed list of inputs:

13-rails_complete_input_list.gif

 

Step 3: Launch the server

Now that you've defined all of the required input parameters, you are now ready to launch the server.

 

----------------------

Did you find this document helpful?  Please feel free to leave us a comment below.  We're always looking for ways  to improve our documentation.  Thanks!

 

Tag page
Viewing 4 of 4 comments: view all
I think you may need to add a step about how to set the DNS ID on each of the front-end servers.

As I understand it, you will use the DNS IDs that were created when you set up the DNSMadeEasy account (from the two records named fe1). edited 00:04, 1 May 2008
Posted 00:04, 1 May 2008
With regards to this input - 'RAILS_ENV - Rails environment. Select Env from the pulldown menu. Select production.' - you actually need to select 'text' from the pulldown menu and enter either 'production', 'deployment', or 'testing'. The Env menu is actually a list of variables provided by AWS.
Posted 17:57, 1 May 2008
can you clarify the difference/use of the boot script "RightScript LB mongrels to local HA proxy connect v1" and the operational script "RightScript LB mongrels to HA proxy connect v3".

Am I correct that after boot, the mongrels on the app server will be seen only by the local haproxy, and that you need to run the operational script on all app servers each time a new app server is added to the array?
Posted 01:26, 26 Oct 2008
The difference is that the "RightScript LB mongrels to local HA proxy connect v1" only connects the mongrels to the local box whereas the "RightScript LB mongrels to HA proxy connect v3" connects to every machine pointed at by the LB_HOSTNAME paramater.

You do not need to run this as an operational script on the dedicated application servers, as this is done automatically in the boot and decomission process. However, if you are running combined load balancer/application server instances and you want to cross-connect your servers, then you will need to do this.

Thanks for your post:)
Posted 20:10, 25 Nov 2008
Viewing 4 of 4 comments: view all
You must login to post a comment.