Note: Please go to docs.rightscale.com to access the current RightScale documentation set. Also, feel free to Chat with us!
Home > ServerTemplates > Archive > 11H1 > Tutorials > Rails Application Server

Rails Application Server

Objective

To configure and launch Rails application servers that will automatically connect to any running Load Balancer Servers and the Master-DB Server.

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 one of the MySQL Database Setups tutorials.  It also assumes that you're using dedicated servers for load balancing that you set up using the Load Balancer Setups tutorial.  This tutorial concentrates on the application tier of a typical website Deployment. 

Overview

In order to create a high-availability load-balanced webserver solution in the cloud, RightScale has published dedicated load balancer ServerTemplates that run HAProxy. It's a software load balancer with high reliability 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, Apache is also run 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 site/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.

diag-RailsApp-v1.gif

 

 

This tutorial will show you how to set up the middle application tier of a high-availability Deployment.  See the diagram below for details.

diag-3tier-v1.png

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 application servers.

Go the RightScale Component MultiCloud Marketplace.  (Design -> MultiCloud Marketplace)  Find and import the most recent version of the "Rails App Server" ServerTemplate to your account's 'Local' collection.

Since you're probably going to make any changes to this ServerTemplate, you'll need to clone it to create an editable version.  Click the Clone button to create an editable (HEAD) copy of the ServerTemplate.

Customize ServerTemplate to get Application

Now that you have an editable ServerTemplate, you can customize it according to your application's requirements.  Perhaps you need to write a couple new scripts that will install custom software or perform various actions at runtime or decommissioning phases.  By default, the ServerTemplate is designed to pull your application code from an SVN repository. 

Note: At this time, you can only pull your application code from an SVN repository. If you need to pull your application code from an S3 bucket instead, check the MultiCloud Marketplace to see if a similar script is available for use. The script may be compatible and work correctly even though it's not officially a part of your chosen Compatibility Release.

The required inputs that you need to define later in this tutorial will depend on the scripts that are added/removed from the ServerTemplate. 

Add Application 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 Application Server that you're going to create.  (e.g. my-app1)
  • 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 Application Server into the same availability zone as your Master-DB server.
  • Elastic IP - Since you do not use EIPs for Application Servers, select the "-None-" option.

 

For high availability purposes you should have two Application Servers across two different availability zones.  The easiest way to create another Application Server is to simply clone the first one that you just created. 

Click on the nickname link of the Application Server that you just created.  Click the Clone button.

Change the following information on your cloned Server:

  • Rename the Server (e.g. my-app2)
  • Change the Availability Zone so that it matches the zone of the Slave-DB (e.g. us east-1b)


You should now have six Servers in your Production Deployment.  The Deployment now has all three 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. 

Notice that the Application Servers are using HEAD versions of the cloned ServerTemplate because you might need to make additional changes later on.  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.

screen-ListServersRails-v1.png

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. 

screen-InputCallouts-v1.png

  • 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:
    • ManageDeploymentsYourDeployment 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 File:15-References/Tables/Dashboard_Icons/wiki_icon_info.gif to view its description and determine what value should be set. 

SVN Repository
  • APPLICATION
  • DB_HOST_NAME
  • 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 Servers will be able to connect to the appropriate database.
  • RAILS_ENV
  • RAILS_VERSION
  • SVN_APP_REPOSITORY

Launch the server

Now that you've defined all of the required Input parameters, you are now ready to launch the Application 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 Application Servers and use the Launch action.

screen-LaunchServersRails-v1.png

In a few minutes you'll have all three tiers of your application running in the cloud!

Next, you might want to set a scalable Server Array for autoscaling your application tier. See Set up Autoscaling using Voting Tags for more information.

You must to post a comment.
Last modified
14:16, 7 Oct 2014

Tags

Classifications

This page has no classifications.

Announcements

None


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