WEBVTT 00:00.110 --> 00:00.560 Hey, everyone. 00:00.560 --> 00:01.460 And welcome back. 00:01.460 --> 00:07.910 Now in today's video, we will look into how we can implement our reverse proxy in Nginx using the proxy 00:07.910 --> 00:09.130 pass directive. 00:09.140 --> 00:15.710 So at a high level overview proxy pass directive forwards the request to the proxy server specified 00:15.710 --> 00:17.590 along with this specific directive. 00:17.600 --> 00:24.860 For example, under the location, you specify proxy pass followed by the IP address where the request 00:24.860 --> 00:26.000 should be transferred. 00:26.000 --> 00:33.170 So now what will happen is whenever a request is received at the Nginx level using this proxy pass directive, 00:33.200 --> 00:40.550 it will transfer it to a backend server with the IP address of 1921638 10.50 similar to what you see 00:40.550 --> 00:41.390 in the diagram. 00:41.390 --> 00:47.600 And then based on the response that the Nginx receives, it will forward the response back to the client. 00:47.630 --> 00:52.490 Now you can also have a lot of flexibility related to the proxy pass directive here. 00:52.550 --> 00:59.570 For example, for the location of slash admin, you can have a different set of servers for a location. 00:59.570 --> 01:00.450 Maybe of route. 01:00.450 --> 01:02.190 You can have a different set of servers. 01:02.190 --> 01:08.670 For example, if anyone visits the admin page in the website, he will automatically be redirected to 01:08.670 --> 01:11.430 a server with the IP of 1050, 30, 20. 01:11.460 --> 01:16.860 However, any other page other than the admin will be redirected to another server. 01:16.860 --> 01:19.170 1921681 10.50. 01:19.200 --> 01:23.310 So various kind of rules can be set up depending upon your requirements. 01:23.310 --> 01:25.890 So let's go ahead and quickly try it out. 01:25.890 --> 01:29.670 So for today's video, I have launched two additional servers. 01:29.670 --> 01:32.640 First server is where our Nginx is already running. 01:32.640 --> 01:34.860 Second server is the application server. 01:34.860 --> 01:40.680 So this is just a name that I've given and the third server is basically the authentication server. 01:40.710 --> 01:47.700 Now in all of the servers I have basically gone ahead and I have installed the Nginx we have already 01:47.700 --> 01:49.560 discussed on how we can install Nginx. 01:49.560 --> 01:54.060 So this is one of the steps that I have completed in all of the servers here. 01:54.060 --> 01:57.690 So currently I am in the CLI and I have three tabs. 01:57.690 --> 02:02.550 First tab is associated with our base Nginx installation. 02:02.550 --> 02:06.570 So this demo Nginx, we will consider it as a reverse proxy. 02:06.600 --> 02:10.860 Second is the application server, third is the authentication server. 02:10.860 --> 02:12.540 So first what we will do. 02:12.540 --> 02:19.170 Let's take a simple example of using a proxy pass directive where all the requests that Nginx receives 02:19.170 --> 02:21.480 it will forward it to a backend server. 02:21.480 --> 02:27.090 So in our case demo hyphen Nginx is basically will act as a reverse proxy here. 02:27.090 --> 02:36.240 So what I'll do from any of the servers under the e.t.c nginx conf.d directory, let's take a default 02:36.240 --> 02:37.980 dot conf data. 02:38.370 --> 02:45.150 Let's copy the base example here and let me quickly paste it within my atom editor document. 02:45.150 --> 02:47.220 So within here, let's go ahead. 02:47.220 --> 02:53.550 And one thing that we were discussing is that a proxy pass goes ahead and sits inside the location. 02:53.550 --> 02:58.820 So let's go ahead and remove the default entries here and what I'll specify. 02:58.830 --> 03:05.220 I'll specify proxy, underscore, pass, followed by the IP address of the backend server. 03:05.250 --> 03:07.950 Now I have three servers that are available. 03:07.950 --> 03:13.480 So first I'll go ahead and specify the IP address of the application server here. 03:13.560 --> 03:20.580 Now you can either specify public IP address just for ease of use, or you can also specify private 03:20.580 --> 03:21.270 IP address. 03:21.270 --> 03:27.030 Generally in the corporate environment, public IP address will not be present for any of the servers, 03:27.030 --> 03:29.670 so you'll typically be using the private IP. 03:29.790 --> 03:36.300 Now since I'm using digital ocean environment, if I'll quickly do a ifconfig, you'll see that the 03:36.300 --> 03:39.090 digital ocean droplet has two interfaces. 03:39.090 --> 03:43.380 First one is the zero, which is associated with a public interface. 03:43.380 --> 03:47.730 Second one is the one which is associated with the private IP. 03:47.760 --> 03:53.970 So now what will happen is if you want to communicate between this first server and the application 03:53.970 --> 04:00.450 server publicly, you go ahead and specify the public IP specified with the zero interface. 04:00.450 --> 04:06.990 If you want the communication to happen privately, then you will have to specify the IP address associated 04:06.990 --> 04:08.790 with the one interface. 04:08.790 --> 04:15.630 Now, again, if you're using a different cloud provider altogether, then the settings might change. 04:15.630 --> 04:19.290 But just understanding the concept is something that is important. 04:19.290 --> 04:26.760 So let's go ahead and find out the IP address associated with the application server so the Ifconfig 04:26.760 --> 04:28.020 command is not found. 04:28.050 --> 04:30.090 Let's quickly do a yum. 04:30.090 --> 04:37.530 Why install net tools so that our ifconfig package is also installed and let's also do the same in the 04:37.530 --> 04:39.000 authentication server. 04:40.260 --> 04:40.890 Great. 04:40.890 --> 04:45.660 So now I'll do a ifconfig and you will see for our application server. 04:45.690 --> 04:51.060 This is the private IP, so I'll copy this private IP and let me paste it over here. 04:51.090 --> 04:53.970 All right, so this is how the configuration looks like. 04:53.970 --> 04:57.390 We also have to add one more block here. 04:57.420 --> 04:59.760 All right, So what I'll do, I'll copy this. 05:00.200 --> 05:02.390 And in a reverse proxy server. 05:02.420 --> 05:08.960 Let's go to Etsy Nginx.conf and I'll do LS. 05:08.990 --> 05:12.620 And currently there are some conf files that are available. 05:12.650 --> 05:18.920 Let's go ahead and remove the conf extension here so that they are not really loaded by nginx. 05:22.280 --> 05:28.190 All right, so now both of them has a back extension, so none of these will be loaded and we'll create 05:28.190 --> 05:34.790 a new file, let's call it as proxy dot conf and I'll paste the contents here once. 05:34.790 --> 05:36.770 Then let's go ahead and save this. 05:36.800 --> 05:43.910 We'll quickly do a nginx hyphen t to verify and I'll do a systemctl restart nginx over here. 05:43.940 --> 05:44.600 All right. 05:44.630 --> 05:48.260 Now before we go ahead and test things out, one more important thing. 05:48.260 --> 05:51.460 Let's copy the public IP of our application server. 05:51.470 --> 05:56.180 I'll paste it in the browser and currently this has a default ingenix page. 05:56.180 --> 05:59.660 So within the application server, let's go ahead and change this. 05:59.660 --> 06:01.530 I'll say usr share nginx. 06:01.680 --> 06:06.300 HTML and what I'll do I'll quickly do an echo. 06:06.330 --> 06:10.230 This is application server backend. 06:10.770 --> 06:14.070 All right, and I'll paste it to the index.html. 06:14.160 --> 06:18.830 And if we refresh the page you should see our custom message now. 06:18.840 --> 06:23.610 So what we'll do, we'll go ahead and send the request to the Nginx reverse proxy. 06:23.610 --> 06:30.570 If our proxy pass directive is working as expected, it should go ahead and connect to the backend server 06:30.570 --> 06:33.150 and retrieve this specific message. 06:33.150 --> 06:40.320 Now from our base Nginx server, let's quickly do a curl on the localhost and currently it is showing 06:40.350 --> 06:42.510 us the 502 bad gateway. 06:42.510 --> 06:45.990 Let's also try it out from the browser. 06:46.020 --> 06:51.870 I'll paste the IP address of our reverse proxy server and it is showing us bad gateway. 06:51.870 --> 06:56.610 All right, so now let's look into why exactly this error is coming. 06:56.610 --> 07:01.470 So generally in production environment, this is one of the common errors that you will see and you 07:01.470 --> 07:04.140 will need to also troubleshoot those errors. 07:04.140 --> 07:06.900 So let's quickly look into the troubleshooting steps. 07:06.900 --> 07:13.740 So first thing that you need to do is you have to go to var log Nginx and here you should see that there 07:13.740 --> 07:14.520 are two files. 07:14.520 --> 07:16.440 These are two very important files. 07:16.440 --> 07:19.350 One is the access log and second is the error log. 07:19.350 --> 07:22.620 So let's quickly do a tale on the access log here. 07:23.580 --> 07:30.780 Now within the access log here, you can determine that a new request was sent from this specific IP 07:30.780 --> 07:31.200 address. 07:31.200 --> 07:37.410 And it is also showing you the response, which is 502, which is nothing but the 502 bad gateway. 07:37.410 --> 07:42.210 So access log is not really giving us much information related to what might happen. 07:42.210 --> 07:45.180 So now the second important file is the error log. 07:46.740 --> 07:49.050 So let's do a tail f on error log. 07:49.740 --> 07:56.250 And interesting this time you are seeing some permission denied message if you see it is critical. 07:56.250 --> 07:59.160 So generally the notice based messages you can avoid. 07:59.160 --> 08:02.550 But generally the message is related to critical or very important. 08:02.550 --> 08:04.800 That means something is not really working. 08:04.800 --> 08:07.080 So let's explore on what might happen. 08:07.080 --> 08:12.150 So here it is saying permission denied while connecting to upstream. 08:12.150 --> 08:15.900 So it is not really able to connect to the upstream server here. 08:15.930 --> 08:18.960 Now there are two important things that you will have to check. 08:18.990 --> 08:25.290 First, you'll have to also verify the access log in the back end server where the request should be 08:25.290 --> 08:25.830 received. 08:25.830 --> 08:31.440 So let's do a tail f on var log nginx access dot log. 08:31.440 --> 08:38.370 So this is our application server and let's verify if the request is actually received here or not. 08:38.670 --> 08:41.550 So let's quickly do a curl localhost here. 08:42.270 --> 08:50.160 As expected, we are seeing a bad gateway and if you see here the request is not even reaching the back 08:50.160 --> 08:50.790 end server. 08:50.790 --> 08:54.210 So something is wrong at a reverse proxy level itself. 08:54.240 --> 09:00.360 Now whenever you see a permission denied, one of the things that you will have to identify again for 09:00.360 --> 09:03.810 this, you might need a Linux skills as well. 09:03.810 --> 09:10.950 So if you do a get enforce over here, you should see that the Linux is in the enforcing mode. 09:10.950 --> 09:17.430 And if you're running Linux in the enforcing mode at one moment of time, things will get messed up. 09:17.430 --> 09:25.290 So either you know on how to write a effective Linux rule or either you go ahead and disable SELinux. 09:25.290 --> 09:28.680 So let's go ahead and temporarily disable Linux. 09:28.680 --> 09:32.940 So I'll say set enforce zero. 09:33.630 --> 09:40.530 All right, So now if you do a get enforce, you'll see it changed from enforcing to permissive. 09:40.560 --> 09:43.650 So this we are doing at a reverse proxy level. 09:43.680 --> 09:46.320 And now let's do a curl on localhost. 09:47.220 --> 09:50.610 And you see our website is working perfectly well. 09:50.610 --> 09:56.190 So if you'll have to verify from the browser, refresh the page and things are working perfectly well. 09:56.190 --> 09:59.700 So generally whenever you see error related to your. 09:59.870 --> 10:05.730 Configuration in Linux, it might not really mean that your actual configuration is wrong. 10:05.750 --> 10:09.500 It can happen due to a SELinux issue as we were discussing. 10:09.500 --> 10:11.680 It can happen due to permission issues. 10:11.690 --> 10:18.530 There can be a lot of factors that might be involved, but generally in new servers you will primarily 10:18.530 --> 10:19.880 see only two major issues. 10:19.880 --> 10:26.000 Either Linux is breaking things or either it is a permission issue for the files that are present. 10:26.030 --> 10:26.690 All right. 10:26.690 --> 10:32.240 So I hope at this stage you understood the basics of what proxy pass directive allows you to do. 10:32.240 --> 10:36.530 Now let's also go ahead and explore a few more examples here. 10:36.530 --> 10:43.940 So in this approach, you have a location of root which is going to one server and the location of admin, 10:43.940 --> 10:45.830 which is going to a specific server. 10:45.830 --> 10:52.760 So now what we'll do the location admin, we want that all the requests related to slash admin should 10:52.760 --> 10:57.830 go to authentication server only, it should not really go to application server. 10:57.830 --> 11:00.170 So let's look into how we can achieve that. 11:00.170 --> 11:06.410 So first within the authentication server, let's go to user share Nginx. 11:06.590 --> 11:10.970 HTML and within the index.html, let's change it. 11:10.970 --> 11:14.540 I'll say this is authentication server, all right? 11:14.540 --> 11:18.220 And I'll send a message to index.html. 11:18.230 --> 11:24.110 So now if I'll copy the IP address of the authentication server, let me paste it here. 11:24.290 --> 11:27.770 And as expected it is stating this is authentication server. 11:27.770 --> 11:30.980 So now let's also add one more location directive here. 11:31.790 --> 11:37.790 Let's specify admin and this time just for simplicity we'll be pasting the public IP. 11:37.790 --> 11:42.020 So let's copy the public IP and I'll add it over here. 11:42.200 --> 11:44.240 All right, so this is our location block. 11:44.270 --> 11:45.740 Things seems to be working. 11:45.740 --> 11:46.700 I'll copy this up. 11:46.700 --> 11:51.380 And within the Nginx reverse proxy, let's verify which directory we are in. 11:51.410 --> 12:01.040 All right, So let's quickly go to etcd Nginx conf.d and our proxy dot conf let's open this up and here 12:01.040 --> 12:03.740 we'll go ahead and add our own snippet. 12:03.740 --> 12:04.340 All right. 12:04.340 --> 12:05.750 Thing seems to be good. 12:05.750 --> 12:07.370 I'll go ahead and save this. 12:07.400 --> 12:11.540 Let's do a nginx hyphen t thing seems to be successful. 12:11.630 --> 12:14.630 I'll do a systemctl restart nginx. 12:14.660 --> 12:15.290 All right. 12:15.290 --> 12:21.260 And now if I do a curl on localhost slash admin immediately. 12:21.260 --> 12:24.470 Here you see it is showing 404 not found. 12:24.470 --> 12:26.960 So now let's look into the troubleshooting step. 12:26.960 --> 12:31.790 First thing specifically for the proxy pass directive related architecture. 12:31.790 --> 12:37.490 What you can do, You can first verify if the request is actually receiving at a backend server or not. 12:37.490 --> 12:39.320 So let's go ahead and verify. 12:39.320 --> 12:44.960 I'll say tail f, var log nginx access dot log. 12:45.380 --> 12:52.010 Now within here you should see that there is one specific entry and this entry has been received by 12:52.010 --> 12:55.640 a curl client and the response to it is 404. 12:55.640 --> 13:00.590 So if you want to quickly verify, let's make a request yet again. 13:00.590 --> 13:04.430 And if we look into the backend server, this request is being received. 13:04.430 --> 13:10.310 So at this stage you can determine that this is not really an issue, maybe at a reverse proxy level, 13:10.340 --> 13:16.610 but it is a issue at a backend level because the request is being received at a backend site and the 13:16.610 --> 13:23.540 backend is basically sending the 404 back to the reverse proxy server and reverse proxy server will 13:23.540 --> 13:25.970 send the same 404 back to the client. 13:25.970 --> 13:29.570 So this 404 is actually coming from the backend server. 13:29.570 --> 13:33.470 Now why is 404 coming from the backend server? 13:33.470 --> 13:34.910 Let's quickly identify. 13:34.940 --> 13:40.370 So if you see this request is going at slash admin. 13:40.370 --> 13:44.480 Now if I do a PWD, which we are in user share nginx. 13:44.630 --> 13:45.020 HTML. 13:45.020 --> 13:50.600 And if I do an ls, you only have an index dot HTML and 50X dot HTML. 13:50.630 --> 13:54.080 You do not really have anything related to admin. 13:54.080 --> 13:59.480 So what you need to do is you have to create a new directory of admin over here. 14:00.110 --> 14:04.010 All right, so this directory matches this specific Uri. 14:04.280 --> 14:09.710 And within this directory let's go ahead and create one more index HTML file. 14:09.710 --> 14:18.110 I'll say this is auth server file under admin and I'll save it to index dot HTML. 14:18.140 --> 14:19.010 All right. 14:19.160 --> 14:20.930 And now let's do one thing. 14:20.930 --> 14:29.450 Let's make a curl request on admin index dot HTML this time and you see it is stating this is auth server 14:29.450 --> 14:31.030 file under admin. 14:31.040 --> 14:31.640 Great. 14:31.640 --> 14:35.720 So I hope with this you understood the basics of proxy pass directive. 14:35.750 --> 14:38.720 We basically took two different examples. 14:38.720 --> 14:43.580 We also looked into the troubleshooting aspect so that it gives us a better clarity. 14:43.580 --> 14:46.100 So with this we'll conclude today's video.