|Table of Contents|
Long Term Support
Stable, tested ServerTemplate assets
Configures a dedicated Tomcat application server with Apache. The ServerTemplate contains scripts and inputs that allow an application server to connect to various load balancing solutions such as Amazon's Elastic Load Balancing (ELB), Rackspace's Cloud Load Balancers (CLB), or a server launched with RightScale's 'Load Balancer with HAProxy' ServerTemplate.
The ServerTemplate supports multiple clouds and is commonly used as part of a three-tier website architecture. It also includes iptables management for clouds that do not support cloud-level firewall services like security groups.
Note: For a complete list of the ServerTemplate's features and support, view the detailed description under its Info tab.
The ServerTemplate contains scripts that support the retrieval of application code from the following locations:
The application code will be placed on the local instance in a location that is based upon the values specified for the following inputs.
In the example above, the root directory for the application code will be stored in: /home/webapps/myapp
In a typical web architecture, application servers need to securely connect to both the database and a load balancing service. The diagrams and scenario below will explain how an application server will connect to the different tiers.
In all clouds, regardless of whether they support security groups or not, Iptables is used to set IP-specific port permissions, which provides better firewall permission control than only using security groups because access permissions are IP-specific (not group-specific).
For example, the database server will only listen for requests from servers defined in its Iptables configuration file. Remember, in most cloud infrastructures, you typically cannot control what private IP address is assigned to an instance. (e.g. EC2, instances are randomly assigned a private IP address at launch time.)
Before an application (e.g. PHP) can perform an action on a database (e.g. create a new record), the application server(s) must first be granted access at the network-level before it can successfully make an application-level request.
Once the database server has updated its permissions to allow access between the application and database tiers, the application will be able to connect the database using the required information. For example, the application will locate the "master" database server using the 'Database Master FQDN' input (e.g. master-db.example.com). The application will access the database, which is defined by the 'Database Schema Name' input by using the username and password of a database user that has database access privileges, which is specified by the 'Database Application Username' and 'Database Application Password' inputs.
The following scenario will explain how iptables and tags are used to configure secure firewall permissions in the cloud.
If you need to open other ports on an application server besides the default TCP ports (8000), you must create the appropriate rules using the "Firewall" inputs, as described in the Base ServerTemplate for Linux (Chef) (v13.5 LTS) - Runbook documentation.
Note: For more information about iptables, refer to the Linux supporting documentation for this tool.
By default, the retrieved WAR file is retrieved from the specified ROS container or software repository, renamed ROOT.war and saved to the same directory as the application's root directory, which is specified by the 'Project App root' input (default: /home/webapps). However, you can use the 'War file for ROOT' input to store the WAR file in a different location relative to the application's root directory.
© 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.