Contact Free trial Login

CloudHub Load Balancer

logo cloud active logo hybrid disabled logo server disabled logo pcf disabled

Overview

CloudHub features a backend load-balancing service designed to automate the provisioning of infrastructure components.

By using this service to proxy your CloudHub-deployed apps, you can:

  • Enforce two way SSL authentication

  • Enforce SSL authentication with custom certificates

  • Easily configure proxy rules that map your applications to custom domains, enabling you to for example host everything under a single vanity domain

  • Handle Load balancing amongst the different CloudHub workers that run your application

Load balancers are an optional addition to your cloud infrastructure that is not included by default in all CloudHub plans. To enable it, you must first own an Anypoint Virtual Private Cloud (Anypoint VPC) offering. This service is designed to have one load balancer per Anypoint VPC and although each Anypoint VPC supports only one domain, you can have multiple environments in the same network, meaning that you can use the same load balancer for your different environments.

Using the Load Balancer

This feature is currently available only as a service that you can use with the Anypoint Command Line Interface, or by using the Cloudhub API through the endpoints anypoint.mulesoft.com/cloudhub/api/organizations/{orgid}/vpcs/{vpcId}/loadbalancers and anypoint.mulesoft.com/cloudhub/api/organizations/{orgid}/vpcs.

For a full list of Anypoint Platform CLI commands and their respective usage, check our reference page.
A full description of loadbalancers and vpcs endpoints is available accessing your API Portal.

In the API Portal, search among other Mule APIs for the CloudHub API and enter its latest version.

Mapping

The load balancer configuration is defined by a list of [mapping rules] which describe how input URL should be translated into calls to different CloudHub apps. When creating a simple matching rule, one input address is literally matched to the defined output: the endpoint of one of your applications. Instead of using literal matchings you can also use a pattern to match a variable-like input text to an endpoint. See the [Pattern matching] section.

By using proxy rules, you can map a domain or subdomain to one of your Mule applications that run in CloudHub.

Pattern Matching

A pattern is a string that defines a template for matching an input text. Whatever is placed into curly brackets ({ }) is treated as a variable. These variables can contain only letters (a-z) and cannot contain any other characters, such as digits, slashes, etc. The variable values can contain the following characters a-z0-1.&-? but no slashes.

Examples

Defining a Simple Rule
‘app.example.com’ -> ‘app/example’

The example above literally binds these two addresses for redirect.

Defining a Rule that Includes a Pattern
‘{mypattern}.example.com’ -> `app/{mypattern}`

The example above causes that both bookings.example.com and sales.example.com match to app/bookings and app/sales respectively, as the variable mypattern holds this value. For input=”bookings.example.com”, the pattern can be resolved by assigning mypattern=”bookings” and for input=`sales.example.com`, the pattern is resolved asignining mypattern=”sales”

Depending on your design, you can choose to leverage your internal redirects to your endpoints using patterns or simply literal mappings.

Mapping Rules

A mapping rule is a set of fields (described below) which defines an [input URL] pattern and a set of fields which describes the [output URL] in terms of patterns described above.

The rule which is defined first has high priority against other ones defined after it. This means that the first matched rule will be applied. You can create, view and delete existing rules.

Rule Examples

The table below contains some rule examples:

Rule # Input URL Output URL

Subdomain

Domain

URI

appName

appURI

1

qaparm

services.com

{appname}/{region}/

{appname}

{region}

2

api

mcd.com

internal-router-proxy

3

{app}.api

mcd.com

`{app}-mcd `

4

api.cce

mule.com

/{group}/{version}/

{group}

/{version}/

5

example.com ,,

/{app}/

{app}

/

6

default

example.com

nn

default-app

Input URL

The input URL is composed of the following parameters, which can be specified by the user:

  1. Subdomain - a string or pattern which defines a subdomain value of the load balancer domain.

  2. Domain - The load balancer’s domain This value should remain constant for the same load balancer.

  3. URI - a string or pattern that describes the Input URI.

subdomain={app}
domain=example.com
URI=/v1/

The input echo.example.com/v1/api matches with the fields above, in which case the variable app=echo. The input echo.example.com/v2/api cannot be matched with the pattern above, as v2 is not in the pattern.

Output URL

The output URL is composed of the following fields. The user can use variable patterns from the input URL.

  1. appName - Output application name where the request will be forwarded to.

  2. appURI - the URI string that is passed to the resolved application.

appName={app}
URI=/hello

Redirect URL

Sets the URI text portion that should be added in the Location and Refresh header fields of a proxied server response. Suppose a proxied server of your application returned the header field Location: http://example.com/two/some/uri/. The directive redirectURI=”/hello” changes the location header to: Location: https://example.com/hello/two/some/uri/.

Rule Order

Rules are grouped into groups by same subdomain name. Groups with longer subdomain names are checked first. So rules with short subdomain names (numbers or symbols) have lower priority. The group with empty subdomain name is checked last.

Within a group (rules with same subdomain) the rules with longer inputURI expressions are checked first, and if they don’t match, the rules with shorter input URI expressions are checked.

Rule order is essential. Pay attention to the rules’ order when creating them as it’s not possible to edit them.

Setting a Rule Priority Order

You can set an order when creating the rule using the cloudhub-add-lb-rule command in the Anypoint Platform CLI by specifying an index value.

When using the API, you can’t specify a priority order, but you can send a PUT request to the endpoint anypoint.mulesoft.com/cloudhub/api/organizations/{orgid}/vpcs/{vpcId}/loadbalancers/{loadbalancerId} and update your rules expressions to match your needs based on the order logic explained above. Longer URIs within the same subdomain are checked first.

The load balancer ID is provided to you when you create it. You can also perform a GET request to your endpoint /organizations/{orgid}}/vpcs/{vpcId}/loadbalancers to get the ID.

Managing Certificates

Certificate Validation

The Cloudhub Load Balancer provides a 2-way SSL client authentication. It allows you to provide a .pem file certificate to your load balancer to validate client requests.

The load balancer passes the certificate data to the API using the http headers below:

X-SSL-Client-Verify

This header returns either SUCCESS, FAILED, or NONE Only after SUCCESS, the client is verified.
It returns NONE when the certificate is not present and FAILED when other validation problems occur.

X-SSL-Client-DN

Contains the full Distinguished Name of the client certificate.

X-SSL-Issuer

Contains the full Distinguished Name of the issuing certificate.

X-SSL-Client-Serial

Contains the serial number used by the CA to identify the client.

Adding Revocation Lists

If you manage your revocation list using OCSP, your revocation are defined in the certificate that you upload, so you don’t need to take any extra steps.

If you manage your revocations using CRL, you can add a crlCert field under the certificates field in your JSON when creating the load balancer and specify your revocations there.