In this lesson,
we'll look at how to configure reverse proxies and load balancers for web servers.
Whenever we access websites like code cloud.com or youtube.com,
the content that's displayed in our browsers comes from a web server.
The most simplistic scenario looks something like this.
The user requests, the web page,
the browser sends that request to the web
server and the web server returns some content.
But nowadays the websites that see heavy traffic are not accessed this way,
not directly.
A lot of infrastructure sits in the middle between the user and the web server.
Let's see what changes when a reverse proxy is added into the mix.
If we add a reverse proxy in front of the web server, things now look like this.
The user request now goes to the reverse proxy first,
then the proxy sends it to the web server.
Next,
the web server returns the page to the reverse proxy and
finally the reverse proxy hands it out to the user.
So why would we need to add this reverse proxy in the middle?
Well, it brings a couple of advantages.
Here's just one example, let's say we build a new and improved web server,
more ram more CPU power and it's just working faster.
And as soon as we finish building it,
we can tell the reverse proxy to switch some traffic to it.
We basically flip a switch
and traffic stops going to the old web server and goes to the new one instead.
And this transition happens instantly.
But if our set up would be the old model we
looked at with user requests going directly to the web server,
then the transition wouldn't be instant.
We'd have to update our code cloud.com domain name to point
to the different IP address of the new web server.
And until all users get redirected to this new IP address,
it can take minutes or hours.
This is called DNS propagation.
DNS is short for domain name system.
A reverse proxy can bring many other advantages such as filtering web traffic,
caching pages to return results faster to users and so on.
But it's actually the way that it can instantly redirect traffic to
a different web server that created another interesting use case load balancing.
We'd have to update our code cloud.com domain name to point
to the different IP address of the new web server.
And until all users get redirected to this new IP address,
it can take minutes or hours even days.
And this is called DNS propagation.
DNS is short for domain name system.
A reverse proxy can bring many other advantages such as filtering web traffic
caching pages to return results faster to users and so on.
But it's actually the way it can instantly redirect traffic to a
different web server that created another interesting use case load balancing.
A load balancer is in a way similar to a reverse proxy.
But the difference is that it redirects traffic to multiple web servers,
not just one.
And it can dynamically pick which server is the best one to use.
For example, it can redirect a request to the server that's the least busy
this way, no server is overloaded and they're all used evenly.
This is the core idea of load balancing to balance the load that is to split
up the work that needs to be done so that each server gets a fair share.
This is the core idea of load balancing to balance
the load that is to split up the work that
needs to be done so that each server gets a
fair share that it can more easily deal with.
Now think about sites like youtube.com,
there's no way a single web server can respond to
the requests of millions of users at the same time.
But load balancing, distributes requests to thousands and thousands of servers.
And this makes it possible to serve all
of those users without overusing any one server.
And now that we know how reverse proxies and load balancers work,
let's see how to create them.
An application often used to create reverse proxies is Engen
X. Although alternative solutions exist such as H A proxy, Apache, et cetera,
you might already be familiar with Engen
X since it's one of the most used web servers in the world.
But even though it's a web server at heart,
it can be configured to work as a reverse proxy as well.
And also as a load balancer. As we'll see later on
the steps to go through to create a reverse proxy are quite simple.
First, we install engine X
then in the Etsy engine X sites available directory,
we'll create a configuration file called proxy con.
We can pick any name we want for it. It's not mandatory to use this exact name
as far as engine X is concerned.
These are simply settings for a website that it will host.
Since technically, it still functions as a web server at its core.
When users connect to it,
they can get to website content.
But the difference is when a user requests
a webpage instead of generating it internally,
we tell engine X to fetch the content from an external web server,
which is what makes it a reverse proxy.
Now, as far as engine X is concerned,
these are simply settings for a website that it will host.
Since technically, it still functions as a web server at its core.
When users connect to the engine
X reverse proxy,
they can get website content.
But the difference is is that when a user
requests a web page instead of generating it internally.
We tell ingen
X to fetch the content from another web server,
which is what makes it a reverse proxy.
We'll add the following content in our configuration file in the server block.
We tell engine
X to listen for incoming connections on port 80.
This line might be a bit harder to understand,
but in essence, it tells engine
X to apply the proxy pass directive below
only for requests that match this location description.
For example, let's look at these URL S. What do they have in common?
Well, after the name of our domain, example.com,
all of the URL S continue with a forward slash
since there's no URL that doesn't add a slash.
After example.com domain name,
it means that this location directive will match all requests for
any web address that the user might want to visit.
But in some cases, we might want to proxy requests only for a portion of our website.
So we could change our location directive to location slash images.
Now, only URL S like this under the slash images will be proxied
but URL S like example.com and example.com/admin won't be.
So you can look at this location directive as a filter we tell engine X to
proxy requests only if the web address visited
contains this part specified under location directly.
After our example.com domain name.
Finally this line, this is almost self explanatory
the request matched in the location directive will
be proxied to the web server specified here,
we can use an IP address but also a hostname or domain name if we want to.
So a line like this
with web server, one.example.com is also valid.
If the web server that we are proxying requests to does not
listen on port 80 we'll have to specify the port ourselves.
For example,
if the server listens for incoming connections on port
8081 we can modify our line this way.
Now think of the web server from its point of view,
it looks like the website visitor is our proxy.
Since it's the proxy that connects to it
depending on our setup, we might want to avoid this illusion.
For example,
imagine we want to collect statistics and see what users visit our website.
So how do we tell our server that we're
actually making this request on behalf of a user?
And this user has a certain IP address that should be logged.
Well, we can add this line include proxy underscore params.
This simply includes instructions specified in
another file called proxy underscore Params.
And we can find this file at Etsy engine X proxy underscore params.
And if we use the cat command, we would see this content,
we can see that all this does is set some headers
for the requests that will be redirected to the web server.
This way, the server gets some additional data and the requests it receives
data like the real IP address of the user that requested the page,
what protocol they used
and so on.
After we save our file, we need to tell engine
X to use settings for this website as we defined
or more accurately, the website definition will tell it to work as a reverse proxy.
Remember we added this config file to the Etsy engine
X sites available directory.
But as the name suggests,
this just lists what website configurations are available.
Gen
X has an additional directory called sites dash enabled
and it only applies definitions for files it can find in that directory.
Now, the standard practice is to simply softlink files.
When we want to enable a website config from the sites available directory,
we soft link it to the sites enabled directory.
In our case, we would use this command
also,
we should disable the default website configuration that's currently active
to disable it. We simply remove the file from the directory
and the file is actually called default.
Now this file is also a soft link so we
won't lose any content since a real file can be found
in the Etsy engine X sites available directory.
And at this point, it's a good idea to check our config files for errors with
pseudo
engine XT
dash T is a parameter that tells engine X to test configuration files
and we should see this output
otherwise errors will inform us about the lines that we have to correct.
Even though this mentions Etsy
Engine
xex.com,
this configuration file will load other files
including the proxy.com file we created.
So that will be tested as well. Even if it doesn't show up in this output
and to apply our new settings, we simply reload engine X
and that's it.
Engine X now works as a reverse proxy,
redirecting all requests to the web server at 1.1 0.1 0.1.
Now let's see how to reconfigure this as a load balancer.
First, we should remove the link to our old configuration.
Next, a new configuration file should be created in the Etsy engine X sites
available directory.
Then the content we add could look something like this to understand it.
Let's analyze from the last lines upward
because we're already familiar with how this block at the bottom works.
It's almost the same as what we saw in our reverse proxy section of this lesson.
The only difference is that we tell engine X to proxy request to
myweb servers instead of the IP address or hostname of a web server.
Basically my web servers is something that doesn't
exist out there in the real world.
But we defined what it means internally in the first block above.
Now the text at the top makes sense
with the upstream directive. We defined a collection of servers
and we called this collection my web servers,
but we can choose any name we want here.
Then we simply listed the IP addresses of various web servers
with the current contents in this file.
The load balancing method would be what's called round robin.
This means that any time a user requests something from our load balancer,
this request would be redirected to a random server.
Sometimes it would be 1234 or other times 5678.
This could work fine for a website that's not seeing very heavy traffic
but with heavy traffic, the random redirection might not be ideal.
It could happen that the server at 1234 gets more than 50% of
the request and it might get overloaded with more than it can handle
to make engine X distribute requests to the least busy server. We can add this line,
the least underscore con keyword makes it pick the
server with the least active connections from this list.
Pretty neat. Right.
Another scenario we can encounter is that we might
have web servers that are more powerful than others.
So they could process more requests than our weaker servers.
In this case, we can assign what are called weights.
If we add this keyword here,
engine X will send many more requests to the server with the IP address 1234.
And even if we don't specify it,
the default weight is equal to one. So
server 5678 has a default weight of one assigned to it
with these settings every four requests.
Roughly three will be sent to 1234 and one will be sent to 5678.
If we need to do some maintenance work on a server,
we can mark it as being unavailable by adding the down keyword
note how we can add multiple settings to a single server specified here,
we assigned it a weight equal to three but also marked it as down
now engine X will not redirect requests to the server anymore
and we can do maintenance work,
restart it and finally remove that keyword when
the server is ready to accept requests.
Again,
here's a different scenario we can encounter
maybe two servers are enough to handle web traffic.
But if one server breaks, things will be slow with just one server left around.
So we want to prevent this. We can add the following line
here. We're adding 1020 3040 as a backup.
What this does is adds 10.20 0.30 0.40 to our collection of web servers,
but it marks it as a backup, which means traffic will not be load balanced to it yet.
Instead if 1234 or 5678 breaks down,
then 10.20 0.30 0.40 becomes active and traffic
begins to be redirected to it as well.
So it sits on the sidelines and it's only used if necessary.
It's also worth mentioning that if these web
servers are not listening for incoming connections.
On the standard port 80
we can specify a custom port like this.
In this case,
we specified that server 1234 is listening for incoming connections on port 8081.
After a config file for the load balancer has been created.
The rest of the steps are identical to what we did for the reverse proxy.
Meaning first we should link this file to the sites enabled directory.
Then the configuration should be tested.
And finally, engine X settings should be reloaded with this command.
And that's all for this lesson. See you in the next one.