CloudHub Dedicated Load Balancer Advanced Concepts: Internal Calls
In this final part of a three-part series that serves as a practical guide for using CloudHub DLB, learn how to use DLB's private IPs for internal calls.
Join the DZone community and get the full member experience.Join For Free
In the previous sections of this 3-part series, we explored the basic, but important principles of CloudHub DLB. In the second part, we worked to understand DLB mapping rules and looked into some practical scenarios. If you haven't read them already, please check the below posts before proceeding further on this one.
How To Use DLB's Private IPs for Internal Calls
By now we very well understand that we can map a custom domain in DNS to our DLB which will allow us to access CloudHub applications. This strategy is fine for the Experience APIs or any external-facing application hosted in our VPC. However, does it make sense to use this same approach for our Process APIs, System APIs , or applications that would only be invoked by applications in the VPC itself?
Imagine two Mule applications deployed in CloudHub where one app calls another. If the call is made to DLB's private IPs, the call stays within VPC, and so is secured by default.
The same call made on the DLB's public IP will have to go through the VPC internet gateway and would need to be made secure using HTTPS protocol.
Now that we know the benefit, let's see how to make a call to DLB's private IPs.
We have deployed two applications in CloudHub: test-rg-dlb-8091 (child app) & test-rg-dlb-8091-parent (parent app), where the latter calls the former.
Below is the HTTP requester configured in the Parent app.
The call is being made on the private IPs of the DLB by using the prefix internal- in the hostname name which represents the DLB itself.
Trying to invoke the parent application via postman results into a failure, as the internal (private) IPs of the DLB on which it is trying to invoke the child app are not accessible outside the VPC.
Now let's see the behavior of triggering the same parent application deployed in CloudHub.
The same child application now was called when the parent application called it from within CloudHub.
And now to our final topic.
DLB and HTTP(S) Traffic
You would have noticed that the request made by the parent application is an HTTPS request made on the 443 port of the DLB.
You can even make an HTTP request on port 80, provided you have enabled HTTP traffic on DLB.
If a request is made to port 80 with the above configuration, the request will timeout as seen below. The parent application has been redeployed with an HTTP requester making an HTTP request. Since HTTP requests were blocked, it couldn't call the child application.
Let's turn on HTTP mode on DLB and check the response.
In general, all the external calls coming into DLB should be HTTPS. However, internal calls to DLB can be HTTP if this configuration is enabled. Please note since such calls are directly made to the DLB, no mapping rules are executed. The DLB hostname should not be shared with external parties.
Hope you enjoyed this 3-part series on CloudHub DLB!
Opinions expressed by DZone contributors are their own.