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
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.
This tutorial will show you how to set up the middle application tier of a high-availability Deployment. See the diagram below for details.
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).
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.
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.
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)
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:
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.
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.
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.
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.
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.
© 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.