When an application is deployed in CloudHub, under the hood, a new Mule runtime worker is created. At the same time, a default load balancer is created to route the API requests to the Mule worker(s). The public URL will be for example http(s)://space-station.cloudhub.io/, where space-station is the deployment name. The API will be publicly available and is load balanced when it is set to multiple workers. Note that the URL is tied to MuleSoft's “cloudhub” domain.
So, what if I want to have my own domain? What if I want to control the APIs as per my organisation’s policies. That is when a Dedicated Load Balancer (DLB) or a Proxy Server would be useful. Consider these use cases:
- A software load balancer to distribute load to workers
- Use a custom/vanity domain and hide “cloudhub” domain to my API consumers. Consumers don’t need to know where my APIs are running
- Define custom SSL certificates based on my company policy
- Setup 2-Way or 1-Way SSL
- Define proxy rules and route requests to the appropriate REST resource
With a DLB in place, it would be possible to add more flexibility and control to the APIs. I can now expose a custom domain name called peoplefly.com, which is registered on a DNS server.
Step 1 – Dedicated Load Balancer creation
A DLB is not part of the standard subscription and hence should be procured separately from MuleSoft per Virtual Private Cloud (VPC). I would need at least two – one for Non-Prod and one for Prod. When a DLB is provisioned (this can be done by my CloudHub Admin) with the name “fly-prod”, the domain fly-prod.lb.anypointdns.net is created with two workers. The DNS A records for “fly-prod” are associated to each worker:
fly-prod.lb.anypointdns.net → 45.100.10.245
fly-prod.lb.anypointdns.net → 122.44.100.22
Step 2 – Domain Mapping
As discussed earlier, I want to use peoplefly.com and map to the DLB URL. This is done by CNAME Map on the DNS server:
peoplefly.com → fly-prod.lb.anypointdns.net
This way, any request initiated with base URL peoplefly.com, will be mapped to the DLB URL fly-prod.lb.anypointdns.net.
Step 3 - SSL Endpoint Configuration
The SSL Endpoint is setup on the DLB to serve client requests in MuleSoft CloudHub over SSL. Note that an SSL Endpoint should be associated with a Certificate which has the matching Common Name (CN) entry in the Certificate Key; in this case, peoplefly.com. As per my company policy, I setup a 2-way SSL against peoplefly.com
Step 4 – Proxy Rules
The DLB listens on ports 80 and 443 from the external clients and always uses ports 8091 and 8092 – internal worker URL to call Mule APIs inside VPC. Hence, the URL map is created from client calls. For example, to map the API call GET: /routes that the company operates:
API exposed → https://peoplefly.com/routes
Internal Worker URL → https://mule-worker-internal-station-routes.cloudhub.io/routes
In the above, the internal worker is configured with HTTPS port 8092. However, as the DLB is part of the same VPC, it is safe to use HTTP port 8091.
Reference
To find out more about MuleSoft's DLB architecture: https://docs.mulesoft.com/runtime-manager/lb-architecture
If you would like to find out more about MuleSoft CloudHub and how API-led connectivity can help you create a fully integrated environment, do give us a call at +44 (0)203 475 7980 or email us at Salesforce@coforge.com
Other useful links:
Distributed cache on CloudHub using Mule 4.x Object Store V2