A load balancer or reverse proxy is required to map external traffic with ports and URLs that WSO2 API Manager (WSO2 API-M) uses internally. Follow the instructions below to configure load balancing together with reverse proxying.
Step 1 - Create a SSL certificate for the load balancer
This step is only applicable for a High Availablity (HA) setup where multiple nodes are fronted by a load balancer.
Create a SSL certificate for the load balancer using the following instructions.
Create the Server Key.
sudo openssl genrsa -des3 -out <key_name>.key 1024
Submit the certificate signing request (CSR).
sudo openssl req -new -key <key_name>.key -out server.csr
Remove the password.
sudo cp <key_name>.key <key_name>.key.org sudo openssl rsa -in <key_name>.key.org -out <key_name>.key
Sign your SSL Certificate.
sudo openssl x509 -req -days 365 -in server.csr -signkey <key_name>.key -out <certificate_name>.crt
Copy the key and certificate files that you generated in the above step to the
/etc/nginx/ssl/
location.
Step 2 - Configure the load balancer/reverse proxy server
In the following instructions, you are instructed to use NGINX to handle the load balancing requirements.
Although the following section instructs you to use NGINX as the Load Balancer, you can use any load balancer in your deployment based on your preference.
Carry out the following steps to configure the load balancer to front multiple nodes.
Install NGINX in a server configured in your cluster.
The NGINX version that you need to install varies based on the WSO2 API-M components that the load balancer is fronting.
Deployment API-M Nodes LB Reason Single all-in-one deployment N/A NGINX Community Does not need Sticky Sessions. Active-active deployment using single all-in-one nodes N/A NGINX Plus Requires Sticky Sessions, but NGINX Community version does not support it. Can use ip_hash
as the sticky algorithm.Distributed deployment Gateway NGINX Community version Does not need Sticky Sessions. Store, Publisher, and Key Manager NGINX Plus Requires Sticky Sessions, but NGINX Community version does not support it. Can use ip_hash
as the sticky algorithm.For more information on installing NGINX, see NGINX community version and NGINX Plus.
Configure NGINX to direct the HTTP and HTTPs requests based on your deployment.
Run the following command to identify the exact location of the
<NGINX_HOME>
directory. Inspect the output and identify the--prefix
tag as it provides the location of the<NGINX_HOME>
directory.nginx -V
Update the
ngnix.conf
file with the required NGINX configuration given below. If not, you can create a file with the.conf
suffix and copy it to the<NGINX_HOME>/conf.d
directory.
- All ports are default ports assuming no port offsets are used.
- The key and the certificate for SSL is assumed to be at the
<NGINX_HOME>/ssl/
location. The placeholders{cert_name}
and{key_name}
are the name of the certificate and key generated. - The directories used for acess logs and error logs should be created if they do not exist.
The ports and URLs that are used internally by API Manager are given below:
Usage | URL | Port |
---|---|---|
HTTPS Servlet (UI Consoles) | localhost | 9443 |
NIO transport (HTTP API Traffic) | localhost | 8280 |
NIO transport (HTTPS API Traffic) | localhost | 8243 |
Restart the NGINX server:
sudo service nginx restart
You do not need to restart the server if you are simply making a modification to the VHost file. The following command is sufficient in such cases.
sudo service nginx reload
Step 3 - Configure the reverse proxy settings in the product
- This step is only relevant to the Store and Publisher nodes when fronting multiple nodes with a load balancer.
- These configurations need to be added in all the Publisher and Store nodes.
When using a load balancer, you need to configure Reverse Proxy for the API Store URL, API Publisher URL, Admin Portal URL, and whatever other URLs that you are working with for the portals to be able to work with the Proxy Server configuration.
Update the API Store node.
Update the following configuration in the<API-M_HOME>\repository\deployment\server\jaggeryapps\store\site\conf\site.json
file as shown below, to configure reverse proxying for the API Store."reverseProxy" : { "enabled" : true, // values true , false , "auto" - will look for X-Forwarded-* headers "host" : "<hostname>", // If reverse proxy do not have a domain name use IP "context":"/store", //"regContext":"" // Use only if different path is used for registry }
Update the API Publisher node.
Configure reverse proxying for the API Publisher.
Update the following configuration in the<API-M_HOME>\repository\deployment\server\jaggeryapps\publisher\site\conf\site.json
file as shown below:"reverseProxy" : { "enabled" : true, // values true , false , "auto" - will look for X-Forwarded-* headers "host" : "<hostname>", // If reverse proxy do not have a domain name use IP "context":"/publisher", //"regContext":"" // Use only if different path is used for registry }
Configure reverse proxying for the Admin Portal.
Update the following configuration in the<API-M_HOME>\repository\deployment\server\jaggeryapps\admin\site\conf\site.json
file as shown below."reverseProxy" : { "enabled" : true, // values true , false , "auto" - will look for X-Forwarded-* headers "host" : "<hostname>", // If reverse proxy do not have a domain name use IP "context":"/admin", //"regContext":"" // Use only if different path is used for registry },