By Muaaz Sarfaraz, Alibaba Cloud Community Blog author.
In this blog article, we talk about why you should use a reverse proxy, how is a reverse proxy different to a load balancer. We also look into how reverse proxies can be used on Alibaba Cloud. The NGINX tool would be used as a reverse proxy for this article as it is the most common open source tool used worldwide as web-service.
A reverse proxy is an added layer—more appropriately an intermediate node/proxy server—that acts as a messenger between the external requests and the source system/application system. There could be additional layers (this is often the case for firewalls) in an enterprise setting between the external user and the application server.
In other words, within a network of workstations, a reverse proxy requests information from the application server on the request of a client, and takes the request to the relevant application server based on the client request (in case there are more than one application servers), for client this would be seamless. The client would get the required response as expected.
For enterprises, it's a common standard and practice to use zoning as an added security layer, and in fact this is also a recommended practice for enterprises. By doing this, enterprise servers are not exposed to the outside world, but rather the users from the Internet that access these serves through a reverse proxy, and as such in a simple scenario only the proxy server's IP is known to the users—nothing else. That is to say, no information is known about the application server—keeping the enterprise's information safe. This thus also avoiding certain direct attacks to the application node.
Actually, this topic has already been covered here. I recommend that you look through this article it to get better familiar with a load balancer. In Alibaba Cloud, load balancer is usually referred to as Server load balancer (SLB).
Now a natural question to ask would is "what's the difference between a reverse proxy and load balancer". Both seem quite similar, because SLB can also relay the request of the client to the server and is the one exposed on public IP. However, one difference, of course, is that there are the application servers are behind it.
The main purpose of a load balancer is to provide high availability, better horizontal scaling, and as the name implies, load distribution. On the other hand, reverse proxy can be used in the same way as a load balancer, however, its main function is to retrieve the information from a server behind a fire-wall (or a secured zone, where internet is disabled) for an internet user. The information or resources returned to the internet user or the client seems as if it originated from the reverse proxy. A picture below would also illustrate this difference for the readers.
A reverse proxy's main function is to act as an additional line of defense for the back-end servers, while load balancer's main function is to offer high availability and load balancing. There are some tasks that both can perform but are not specialized for and there are some tasks that one can perform and the other cannot. For example, a reverse proxy caches request, while SLB does not, this means reverse proxy can return a response to the client from its cache. Moreover, reverse proxies can proxy to any back-end this back-end could be any website, an ECS instance, container, OSS, while in case of an SLB you are limited to an ECS instance, container or limited cloud products. But with SLB scaling is inherently easy as it's built specifically for that purpose, while with a reverse proxy this is challenging.
1. You would need a node/workstation/server/ VM that would act as a reverse proxy. For this tutorial we would follow the instruction for a Linux-based reverse proxy, as Linux is the most popular OS for reverse proxies.
Firstly, we need to install NGINX. The rpm file for CentOS NGINX can be downloaded from here.
Command for downloading the rpm binary package for NGINX is as follows:
wget http://nginx.org/packages/centos/7/x86_64/RPMS/nginx-1.14.2-1.el7_4.ngx.x86_64.rpm
This would download the file in the directory this command was called from. In case you have other Linux distribution look for the relevant packages under the required Linux distribution at http://nginx.org/packages/
2. Install NGINX by running the command below:
rpm -ivh nginx-1.14.2-1.el7_4.ngx.x86_64.rpm
3. Once NGINX is installed, you can test it by the nginx –v
command, which prints the nginx version.
For example, a clients HTTP request has to be served by a backend server with the IP 10.1.244.35, in order to establish the setup shown below.
Once made sure that the relevant ports are open for communication between the relevant nodes, edit the configuration file present in the directory at /etc/nginx/nginx.conf
.
Keep the default file as is and create a new file in the nginx.conf directory with a relevant name 'application.conf'
.
Write the following in the configuration file
---------------------------------------------------------
#Configuration file
#Disable all logs
#Load balancing with sticky session enabled minimum one session
Upstream anynameofyourchoice {
#ip_hash;
keepalive 100;
server 10.1.244.35;
}
server {
listen 80;
listen [::]:80
server_name yourpublicwebsite.com
location /
{
proxy_pass http://anynameofyourchoice;
proxy_send_timeout 60m;
send_timeout 15m;
proxy_read_timeout 60m;
proxy_connect_timeout 60m;
client_max_body_size 0;
#enable websocket
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
}
In case your configuration is simple you can also try the basic setting wit this configuration file shown below (Only use one of the two configuration files provided here, not both).
Configuration File 2 (For simpler cases)
---------------------------------------------------------------
server {
listen 80;
listen [::]:80
server_name yourpublicwebsite.com
location /
{
proxy_pass http://10.1.244.35;
}
}
Note: In both the configuration files replace the relevant text with your own public domain and backend server IP.
<yourpublicwebsite.com>
with your own public domain<10.1.244.35>
with your own backend server IPThe upstream saves the backend server IP where traffic has to be routed and an alias(anynameofyourchoice)
is given to it to make it easy to refer in the 'server'
section. The port at which the server would receive the connection form public domain usually its an http traffic (it could be https as well) hence 80 is mentioned. Later you would have to mention your public domain name. The other settings ensure that the timeout limit is enough for the page to respond and in certain cases you would need websocket to be enabled.
4. You can use any one of the following commands to activate the nginx now:
It would read and initiate as per the configuration file.
At this stage the nginx should be up and running, and if the configuration file is right, it would start acting as reverse proxy.
To edit and re-start the service you would have to follow these steps:
A. Stop the nginx service (cmd: sudo kill nginx)
B. Edit the configuration file
C. Restart the services (cmd: sudo nginx)
In this section, we would go through a real-world implementation of a NGINX reverse proxy scenario.
A dashboard is built on a QlikSense application, which is in the non-exposed zone, as it is connected to the database which cannot be in the exposed zone. This Qliksense dashboard is accessed via a website interface. A user visits a website subscribes to relevant dashboard and then access relevant QlikSense dashboard. The dashboard and the web application have to be accessible on the public domain without exposing the backend servers.
The purpose of the setup is to get the public website visitor access the static web pages through our reverse proxy, and once subscribed to the dashboard, access the dashboard which can be filtered by nginx based on permalink /global or /form or /hub etc.
The steps shown above would stay the same apart from the configuration file. Below we would be sharing the configuration file for achieving this use case.
#Configuration file
#Disable all logs
#Load balancing with sticky session enabled minimum one session
Upstream qlikwebsocket {
#ip_hash;
keepalive 100;
server 10.14.14.24;
}
server {
listen 80;
listen [::]:80
server_name dashboard.com
location /global/
{
proxy_pass http://qlikwebsocket;
proxy_send_timeout 60m;
send_timeout 15m;
proxy_read_timeout 60m;
proxy_connect_timeout 60m;
client_max_body_size 0;
#enable websocket
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
location /form/
{
proxy_set_header Host $http_host;
proxy_pass http:// 10.14.14.24:4244;
proxy_read_timeout 60m;
#enable websocket
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
location /{
proxy_pass http:/ 10.13.13.23/;
}
}
The above configuration file would set the nginx as a reverse proxy enabling the website visitors enjoy our backend application without realizing that they have been served by a reverse proxy, while on the enterprise end we would stay secure by not exposing our backend server IPs.
Please note, for this configuration to work the network shown in the diagram above should be whitelisted so the ECS instance at Alibaba cloud being used as reverse proxy should be accessible by both the backend servers. This can be achieved if they are all in the same security group with the relevant port and IP allowed. Also, you would have to ensure that the websocket protocol is allowed in case of Qlik dashboard access otherwise dashboard would not load.
2,599 posts | 762 followers
FollowAlibaba Clouder - March 26, 2020
Alibaba Clouder - December 19, 2019
Alibaba Container Service - July 28, 2021
kehuai - May 15, 2020
Xi Ning Wang - March 1, 2019
Alibaba Cloud Community - November 4, 2024
2,599 posts | 762 followers
FollowElastic and secure virtual cloud servers to cater all your cloud hosting needs.
Learn MoreLearn More
Learn More
More Posts by Alibaba Clouder