Note: Please go to to access the current RightScale documentation set. Also, feel free to Chat with us!
Home > ServerTemplates > v13.5 LTS > ST > Load Balancer with HAProxy (v13.5 LTS) > Load Balancer with HAProxy (v13.5 LTS) - Tutorial

Load Balancer with HAProxy (v13.5 LTS) - Tutorial


Table of Contents    

Long Term Support

Stable, tested ServerTemplate assets

  ►  Tutorial


To set up an HAProxy load balancer server or servers in a public or private cloud environment.


  • You must log in under a RightScale account with "actor" and "library" user roles in order to complete the tutorial.
  • For Amazon EC2, CloudStack, and other clouds that support security groups, you must have a security group defined with TCP port 22 open for SSH access, the appropriate web port (80 for HTTP or 443 for HTTPS) open for client access, and any other port and protocol access required by your load balancers. Also, remember that iptables is installed by default on all servers, as described under Security below.
  • We strongly recommend that you set up credentials for password values and any other sensitive data included as Chef recipe inputs.
  • You can use this ServerTemplate to distribute traffic to any application server listening on port 8000 (e.g. Apache+PHP, Tomcat, IIS, JBoss).
  • If you are deploying on the Rackspace cloud, you can choose to use Rackspace's Cloud Load Balancing (CLB) as an alternative to setting up HAProxy load balancer servers.


This tutorial describes the steps for launching one or more HAProxy load balancer servers in the cloud, using the HAProxy ServerTemplate published by RightScale. However, in a typical three-tier server architecture there are two dedicated load balancer servers, which is necessary to support redundancy and failover for client communications.

For a technical overview of this ServerTemplate, see Load Balancer with HAProxy (v13.5 LTS).

Create Credentials

Although the Load Balancer ServerTemplate does not assume that any specific predefined credentials exist, we recommend that you set up the following credentials if you need to enter any of the following input values. This ServerTemplate assumes that all of these credentials are setup if you want to use the desired functionality that these inputs depend on.

  • LB_STATUS_USERNAME - Optional user name to require in order to log in to the HAProxy status report page.
  • LB_STATUS_PASSWORD - Optional password corresponding to LB_STATUS_USERNAME.
  • SSL_CERTIFICATE - Contents of the X.509/PEM-format SSL server certificate used for enabling HTTPS communications.
  • SSL_CERTIFICATE_CHAIN - The certificate authority (CA) certificate chain associated with the server certificate used to set up HTTPS communications.
  • SSL_CERTIFICATE_KEY - The SSL server certificate's private key, in PEM format.
  • SSL_PASSPHRASE - If required by an SSL certificate, you must provide the passphrase so Apache can start.

For information on setting up credentials, see Create a New Credential.

Create Elastic IPs (AWS only)

If you are launching HAProxy load balancer servers in EC2, it's recommended that you use Elastic IPs. Typically, you will have two load balancers for redundancy purposes. If you haven't already done so, create an Elastic IP for each load balancer. Be sure to create the Elastic IPs in the AWS region (e.g. 'us-east') where you intend to launch the load balancer servers. See Create Elastic IPs (EIP).


Add a Server

Follow these steps to add a load balancer server to the deployment.

  1. Go to the MultiCloud Marketplace (Design > MultiCloud Marketplace > ServerTemplates) and import the most recently published revision of the Load Balancer with HAProxy (v13.5.x) ServerTemplate into the RightScale account.
  2. From the imported ServerTemplate's show page, click the Add Server button.
  3. Select the cloud for which you will configure a server. 
  4. Select the deployment into which the new server will be placed.
  5. Next, the Add Server Assistant wizard will walk you through the remaining steps that are required to create a server based on the selected cloud.
    • Server Name - Provide a nickname for your new load balancer server (e.g., lb1). 
    • Select the appropriate cloud-specific resources that are required in order to launch a server into the chosen cloud. The required cloud resources may differ depending on the type of cloud infrastructure. If the cloud supports multiple datacenters / zones, select a specific zone. Later, when you create the other load balancer server you will use a different datacenter / zone to ensure high-availability. For more information, see Add Server Assistant.
    • If you are using Elastic IPs (AWS EC2 only), select an Elastic IP.
  6. Click Confirm, review the server's configuration and click Finish to create the server.

Create another Load Balancer Server

For production environments, it's strongly recommended that you have at least two load balancer servers (preferably in different availability zones or datacenters) for redundancy purposes. The easiest way to create a second load balancer is to simply clone and modify the first load balancer server.

  1. Go to the show page of the load balancer server that you just created and click the Clone button.
  2. Change the name of the server accordingly. (e.g. lb2)
  3. Under the Info tab, click Edit.
  4. Select a different zone/datacenter and Elastic IP (if applicable).

Configure Inputs

The next step is to define the properties of your load balancer server or servers by entering values for inputs. As a best practice, you should define required inputs for the servers at the deployment level. For a detailed explanation of how inputs are defined and used in Chef recipes and RightScripts, see Inputs and their Hierarchy.

To enter inputs for the Chef recipes that will run on your load balancers, open the deployment's Inputs tab, click Edit, and use the following settings to configure input values. We recommend that you set up credentials for password values and any other sensitive data as shown in the examples.


Input Name Description Example Value
Load Balance Pools

Comma-separated list of URIs or FQDNs for which the load balancer will create server pools to answer website requests. The last entry will be the default backend and will answer for all URIs and FQDNs not listed here. A single entry of any name (for example, default) will mimic basic behavior of one load balancer with one pool of application servers. This will be used for naming server pool backends.

Note: Application servers can provide any number of URIs or FQDNs to join corresponding server pool backends (for example,,, /serverid, default).



For the 3-tier tutorial, use:
text: default

Health Check URI

Relative URI (resource path), including the preceding forward slash, pointing to the health-check page on your application servers. For example, /hlthchk378923.html points to the file hlthchk378923.html in the application directory on your application servers. During the testing phase, you may leave this input set to the default (/) value, indicating that health check pages are not included on the application servers.

text:  /

For the DotNetNuke Windows 3 tier example, use:

text: /Default.aspx

Use Session Stickiness Leave this value set to "true" to enable session persistence (stickiness). In this case, the load balancer will route client requests made in the same session to the same application server, via a cookie. Set to "false" to disable session stickiness, in which case the load balancer routes each new client request to the next available application server, regardless of session.

text:  true


For the 3-tier tutorial, use:
text:  false

Status Page Password

Status Page Username

Username and password (if required) to access the HAProxy status report page, which is accessible from the URI set in Status URI.



Status URI

Relative URI (resource path) pointing to the HAProxy status report page. If you use the default value (/haproxy-status) you can append this value to the hostname or public DNS/IP address for your a load balancer to access the status report—for example, or

text:  /haproxy-status


Input Name Description Example Value
Load Balancing Algorithm

Defines which load balancing algorithm is used to establish  connections with application servers in the load balancing pool.

  • roundrobin (default) - Incoming requests are distributed in a round-robin fashion. (a-b-c-a-b-...)
  • leastconn - Incoming requests are sent to the server with the fewest number of active connections.
  • source - Incoming requests from the same client IP address will be sent to the same application server.
text: roundrobin



If you are not setting up SSL, leave the SSL related inputs set to 'No value/Ignore' (default).

Input Name Description Example Value
Allow Override Directive Set to All to allow the use of .htaccess files in the project web root directory. Set to None (default) to disallow the use of .htaccess files. text: None
Application Name On your application servers, the server subdirectory where your application code files are stored. This must match the Application Name input for your application servers. text:  myapp
Multi-Processing Module Set to the value matching the application servers that your load balancer will connect to: "prefork" for PHP servers, or "worker" for Rails, Apache Tomcat, and stand-alone application servers. text:  prefork
SSL Certificate Contents of the X.509/PEM-format SSL server certificate used for enabling HTTPS communications.

No value/Ignore



SSL Certificate Chain The certificate authority (CA) certificate chain associated with the server certificate used to set up HTTPS communications.

No value/Ignore



SSL Enable Set to "true" to enable SSL ('https').
Set to "false" to disable SSL. (default)

No value/Ignore


text:  false

SSL Certificate Key

The SSL server certificate's private key, in PEM format.

No value/Ignore



SSL Passphrase If required by an SSL certificate, you must provide the passphrase so Apache can start.

No value/Ignore



Launch the Servers

  1. Go to the deployment's Servers tab and launch all of the load balancer servers. When you view the input confirmation page, there should not be any required inputs with missing values.  If there are any required inputs that are missing values (highlighted in red) at the input confirmation page, cancel the launch and add values for those inputs at the deployment level before launching the server again. Refer to the instructions in Launch a Server if you are not familiar with this process.

    Note: Remember that as a best practice for building high-availability sites, you should have two load balancers that you launch in different availability zones or data centers.

Configure DNS Records

If you are using Elastic IPs or already know the public IP addresses that will be used by the load balancer servers, you might have already set up the DNS records for the load balancing tier. However, if you do not know the public IP addresses that will be assigned to the load balancer servers, you must manually set up the DNS records after the servers have been launched. Once the servers become operational (and have been assigned their respective public IP addresses), create or update the DNS records with your DNS provider. Each load balancer server should have its own DNS record with the same hostname (e.g. that points to its public IP address.

The DNS records for the HAProxy load balancing tier should direct traffic from the associated hostname (FQDN) (e.g. to the application servers in its load balancing pool.

Next Steps

Connect Application Servers

Launch new application servers that will connect to the HAProxy load balancers or connect any operational application servers using the 'lb::do_attach_all' operational script.

Check HAProxy Status

The easiest way to check the status of the HAProxy load balancing pool is to view the HAProxy Status page. By default, the Status URI input is set to /haproxy-status

If you created DNS A Records for the load balancer servers, you can visit the HAProxy Status page by entering your <FQDN>/haproxy-status in a web browser window. (e.g.  

If DNS A Records are not used, you can also use the public DNS name or IP of a load balancer server. (e.g. http://192.34.456.77/haproxy-status



Each application server that's successfully added to the load balancing pool will be highlighted in green. In the example screenshot above, two application servers are in the load balancing pool and are able to receive requests from the load balancer servers. Notice that each application server is identified by its universally unique identifier (UUID) that RightScale assigns to each instance. You can find the server's UUID in its machine tags or under its Info tab.


Application servers highlighted in red are not included in the load balancing pool and will not receive any client requests. There are several reasons why an application server may be highlighted in red.

  • The application server's firewall permissions are not allowing ingress communication from the load balancers. Check the firewall permissions of the application server (as defined by its security group, if applicable, and/or iptables rules).
  • The application server is not operational. Perhaps the application server is in the booting or decommissioning state.
  • The health check failed. 
You must to post a comment.
Last modified
15:21, 9 Dec 2013



This page has no classifications.



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