Understanding Reverse Proxy ( haproxy )
On vRealize Automation Appliance we have multiple services running simultaneously.
An Open-Source application called HA Proxy is used to provide a reverse proxy on port 443 , routing traffic to each service appropriately.
Each incoming request is analyzed on where it should be routed.
Routing is determined by looking at the configuration files that contains a set of rules which live under /etc/haproxy/conf.d/
These rules outline
What url should be directed where
Any checks that needs to be done before routing traffic
What to do by default
In order to understand how reverse proxy functions in vRealize Automation , let's look at the configuration files
When haproxy starts each *cfg file is loaded in alphanumeric order. The default and recommended naming convention is to start each file with 2 digit number. These file define what to do with each requests coming in.
Let's look at /etc/haproxy/conf.d/20-vcac.cfg , we can learn how routing is determined
The snippet shown above defines requests for orchestrator and health-checks , then states what to do with these requests.
Lines 25 to 29 starting with acl says what URI to look for , for example /vco or /vcac/services/api/health
If /vco is found then it would use backend-vro ( Line#33 )
If /vcac/services/api/health is found then backend-vra-health is used ( Line#34 )
If nothing is found or none of the conditions are met , then default backend is used that's backend-vra
If we go down the configuration file , we can find the respective backend code as well.
Line#66 in the above screenshot shows us backend-vra-health , Line#80 shows us backend-vro
In the above example , if backend-vro is used then the traffic will be routed to port 8280 on the localhost
Let's now see how Reverse Proxy is used in vRealize Automation with an example
When a user navigates to https://<vra>/vcac/ a check is performed for a valid SAML token. In this case , if the user did not login into vRA for a while and does not have a valid token.Reverse Proxy , then forwards the connection to vIDM for authentication.
When authentication is complete , a valid SAML token is cached into browser. Browser sends the login request again to Reverse Proxy , now since a valid SAML token is present it forwards connection to vRA CAFE
If a valid SAML token was found in the first instance , then Reverse Proxy would have directly forwarded the connection to vRA CAFE
Some requests like vRO API calls are done through URI. If request comes in like https://<vra>/vco , then Reverse Proxy forwards it to vRO directly
Reverse Proxy Logging
By default Reverse Proxy ( haproxy ) logging is disabled. In my experience, never came across any issues with this component of vRealize Automation.
If you still want to enable logging for haproxy then we can accomplish it at /etc/haproxy/haproxy.cfg
Note: Backup /etc/haproxy/haproxy.cfg before making any configuration changes to it
To enable logging we need to add following lines to haproxy.cfg and then restart services
stats enable stats uri /stats stats realm Strictly\ Private stats auth admin:VMware123!
The first line enables stats view
Second line set's access URI to stats , that means that there is a new view set at https://<vra>/stats
Third line set's access to private
Fourth line set's the username and password ( you may set password as you want )
Post these additions to the file , you would have to restart the haproxy service
service haproxy restart
Captured these steps in screenshot for reference
To confirm if Reverse proxy is functional
We can check it's service status that's
service haproxy status
Find Listening Ports and Running Process
netstat -plnt | grep haproxy
ps -ef | grep haproxy
haproxy stats page
