Contact Free trial Login

Dedicated Load Balancer Mapping Rules

The load balancer configuration is defined by a list of mapping rules that describe how an input URL should be translated into calls to different CloudHub apps. Mapping rules are attributes of the load balancer’s SSL endpoint. When you create a mapping rule, you need to specify a certificate CN. Omitting the [certificateName] parameter adds the mappings to the default endpoint.

When you create a simple matching rule, one input address is 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, such as input text to an endpoint.

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

Using Patterns in Mapping Rules

Patterns in the application URI are not currently supported.

A pattern is a string that defines a template for matching an input text. Whatever value is placed within curly brackets ({ }) is treated as a variable. Variable names can contain only lowercase letters (a-z) and no other characters. Variable values can contain the characters a-z0-1.&?-_, but can’t contain slashes.

Suppose you set up a DNS CNAME record from example.com to lb-name.lb.anypointdns.net. You can then map app.example.com to a different deployed CloudHub Mule application name.

For example, you can bind two hostnames for redirect:

‘app.example.com’ ->  application: `app` URI: `/example’

In this case, external requests to https://app.example.com are directed to http://app.cloudhub.io/example.

Or you can define a pattern to hold the input value:

‘example.com/{mypattern}’ -> application: `app-{mypattern}` URI: /data

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

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

Creating Mapping Rules

A mapping rule is a set of fields that define an input URL, and a set of fields that describe the output URL.

The input URL is described using a URI parameter that can be specified by the user. The URI is a string or pattern that describes the input URI.

The input URL follows the main load balancer’s domain and should remain constant for the same load balancer.

The output URL is specified by two fields:

  • appName

    Outputs the application name where the request is forwarded.

  • appURI

    Specifies the URI string that is passed to the resolved application.

You can define both input and output URLs using patterns or literal strings.

Mapping rules are attributes of the load balancer’s SSL endpoint, which is identified by the certificate name. When you create a mapping rule, you must specify a certificate CN. Omitting the [certificateName] parameter adds the mappings to the default endpoint.

If your SSL endpoint sets a wildcard certificate, and you want to use the subdomain portion in a mapping rule, you can use the pre-defined {subdomain} variable.

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 using the mappings add, mappings describe and mappings remove commands respectively.

Mapping Rule Examples

The external load balancer domain name depends on the unique name you assign to it. In the following mapping rule examples, the load balancer is lb-demo.

By default, your load balancer listens to external requests on HTTPS and communicates internally with your worker over HTTP. If you configured your Mule application within the VPC to listen on HTTPS, make sure you set upstreamProtocol to HTTPS when creating the mapping list using the load-balancer mappings add command.

URL Mapping

You can pass the app name as an input URI and map it directly to the app name in CloudHub:

Rule # Input URL Output URL

URI

appName

appURI

0

/{app}/

{app}

/

This rule maps lb-demo.lb.anypointdns.net/{app} to {app}.cloudhub.io. {app} is a pattern for any application name you pass in the inbound request.

Host Mapping

If you have a wildcard certificate (such as *.example.com), you can use the subdomain variable to map any subdomain:

Rule # Input URL Output URL

URI

appName

appURI

0

/

{subdomain}

/

This rule automatically maps any request passed to a subdomain of example.com to the corresponding appName. For example:

  • Passing api.example.com would redirect to api.cloudhub.io

  • Passing application.example.com is mapped to application.cloudhub.io.

The same applies to the Subject Alternative Names (SANs) of your SSL endpoints.

Instead of using a wildcard certificate, which permits any subdomain application name to be passed through the dedicated load balancer, you can restrict the allowed subdomain names. To do this, you must have different SANs configured for a certificate’s common name. You can use the subdomain variable to map the subdomain portion of your domain name to your application.

In this example:

  • Two deployed applications:

    • dev-app

    • qa-app

  • An SSL endpoint with the SANs:

    • dev.example.com

    • qa.example.com

  • Mapping rule:

    Rule # Input URL Output URL

    URI

    appName

    appURI

    0

    /

    {subdomain}-app

    /

This rule maps the subdomain part of your domain name to the application name:

  • dev.example.com redirects to dev-app.cloudhub.io.

  • qa.example.com redirects to qa-app.cloudhub.io.

1:1 Mapping

If you have only one application, you can map the literal app name.

Rule # Input URL Output URL

URI

appName

appURI

0

/

myApp

/

This maps your default load balancer lb-demo.lb.anypointdns.net directly to your app in CloudHub myApp.cloudhub.io.

Indexing the Priority of Rules

When creating a mapping rule, assign an index to it to define the rule’s priority order.

A rule defined first, at index 0 has higher priority against other rules defined after it. The higher the index assigned, the less priority the mapping rule has.

Every rule must have a priority defined. When creating rules, pay attention to the order for each rule to avoid having multiple rules override each other.

Ordering and Prioritizing Rules

You can set the order of your mapping rules when creating them using the cloudhub load-balancer mappings add command in the Anypoint Platform CLI and specifying an index value.

When using the API to create a rule, you cannot specify a priority order, but you can send a PATCH request later to the load balancer endpoint anypoint.mulesoft.com/cloudhub/api/organizations/{orgid}/loadbalancers/{loadbalancerId} and update your rules expressions with an order index, to match your needs based on the order logic explained above.

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

We use cookies to make interactions with our websites and services easy and meaningful, to better understand how they are used and to tailor advertising. You can read more and make your cookie choices here. By continuing to use this site you are giving us your consent to do this.