You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is going to be an `instances` target group, and we are going to name this one `app‑servers`. Under the Protocol, let's click the drop‑down and here we've got several options, HTTP, HTTPS, TCP, TLS, UDP, and so on. We're going to work on HTTPS later. So for now, let's just go and select `HTTP`. The **port** here is going to be `8080`, which again is the port that the application servers listen on, and the `VPC` is of course going to be `webapp‑vpc`. And we are still using `HTTP1` here as well.
35
35
36
-
[Set up target group 1](./.resources/02-set-up-tg-1.png)
36
+
37
37
38
-
[Set up target group 2](./.resources/03-set-up-tg-2.png)
38
+
39
39
40
40
Now for the health check, we're going to go ahead and stick with `HTTP`, but in the path we're going to enter `/api/todos`, which is just a very simple page that displays information about the app server.
41
41
42
-
[Set up target group 3](./.resources/04-set-up-tg-3.png)
42
+
43
43
44
44
```
45
45
/api/todos
46
46
```
47
47
48
48
Now, let's expand the Advanced health check settings. Now this time we'll stick with Traffic port and set the healthy threshold to 2.
49
49
50
-
[Set up target group 4](./.resources/05-set-up-tg-4.png)
50
+
51
51
52
52
The rest of the defaults are fine, so scroll down to the bottom and click `Next`.
53
53
54
54
Now let's go ahead and select `app3`, `app2`, and `app1`, scroll down, click `Include is pending below`, scroll down a little more, make sure they're all there, app1, app2, and app3, and then click `Create target group`.
and let's name this one `app‑lb`. For the scheme it's going to be an **internal load balancer** because we don't want it to be open to the internet.
69
69
70
-
[ALB config 1](./.resources/11-alb-config-1.png)
70
+
71
71
72
72
It should receive traffic only from the web servers. For the IP address type, notice we have only one option, `IPv4`. Now for the listener, we want to stick with HTTP and we're going to use port `8080` just to keep it consistent with the destination port we configured on the target group.
73
73
74
-
[ALB config 2](./.resources/12-alb-config-2.png)
74
+
75
75
76
76
Scrolling down two Availability Zones, we're going to select the `webapp‑vpc`. For eu-west-3a we're going to select the `app‑1a` subnet, and for eu-west-3b, of course, the `app‑1b` subnet.
77
77
78
-
[ALB config 3](./.resources/13-alb-config-3.png)
78
+
79
79
80
80
Notice it tells us there's an internet gateway attached to these subnets. In our VPC, we've got an internet gateway attached to a route table which is associated with those subnets. The only reason we did this is so that we could SSH directly to each of the app server instances to set them up.
81
81
82
82
Add security group
83
83
84
-
[ALB config 4](./.resources/14-alb-config-4.png)
84
+
85
85
86
86
Let's go ahead and click `Next`. Once again we get the warning we got earlier about not using HTTPS. Let's click `Next`.
87
87
88
88
And for the security group we're going to select `app‑sg` and deselect the default security group and click `Next`. And then we'll select an Existing target group and we will choose the app‑servers target group that we just created. Scroll down, click `Next: Register Targets`, and there are our targets. Go ahead and click `Next` again, give the settings a once over.
89
89
90
90
Add load balancer tags
91
91
92
-
[ALB config 5](./.resources/15-alb-config-5.png)
92
+
93
93
94
94
Well, it looks good.
95
95
96
-
[ALB config 6](./.resources/16-alb-config-6.png)
96
+
97
97
98
98
Click `Create`, and then click Close.
99
99
100
100
Now, let's go locate the DNS name of the new load balancer and copy it to our clipboard. So click on `app‑lb`. And then here's the DNS name. Go ahead and copy that to your clipboard by clicking the little icon there.
101
101
102
-
[LB Summary](./.resources/17-lb-summary.png)
102
+
103
103
104
104
We're going to need this in just a moment. By the way, because this is an internal load balancer, this fully qualified domain name is only resolvable from within the `VPC`. There is no way to access this address from the internet.
105
105
106
106
Now let's jump over to our Target Groups, select `app‑servers`, highlight the Targets tab, and after a moment there are our three healthy targets.
107
107
108
-
[TG Summary](./.resources/18-tg-summary.png)
108
+
109
109
110
110
Now, we've got our web servers working and sitting behind an internet‑facing load balancer and we've got our application servers working and sitting behind an internal load balancer. When we configure the application target group, I directed the health check to use the path `/api/todos`.
We're going to reconfigure the web tier instances to point to the URL of the internal application load balancer, and here's how we're going to do it.
4
+
5
+
First, we're going to destroy the existing Docker containers on `web1`, `web2`, and `web3`. Once we do that, we're going to recreate the containers using a command that looks something like this.
6
+
7
+
```bash
8
+
docker run -d -p 80:3000 -e API_URL="http://<DNS API>:<PORT>" jaimesalas/todo-app-front:4
9
+
```
10
+
11
+
This is almost the same command we used when we initially deployed the web front end, but this time we're adding something new. The __‑e API_URL=__ parameter followed by the internal load balancer's URL tells the web server to send all requests for the application tier to this URL. In other words, we're just reconfiguring the web front end to treat the internal load balancer as an application server.
12
+
13
+
Notice that we're specifying a full URL here, complete with HTTP as the layer 7 protocol and 8080 as the port number. This corresponds to the internal load balancer's listener. Remember that we configured it to listen for HTTP requests on TCP port 8080.
14
+
15
+
Once we reconfigure all the web tier instances to point to the internal load balancer, any request from the web tier to the application tier will hit the listener, which again is listening on TCP port 8080. The internal load balancer will then forward these requests along to the target group containing the application server instances. Make sense? Okay, enough talking. Let's go configure this.
16
+
17
+
> Show overview diagram
18
+
19
+
Here I've browsed to the internet‑facing load balancer, which is load balancing among our three web server front ends. Just as we saw earlier, the App Server Information indicates nothing but errors because the web servers are not configured to connect to the application servers using the internal load balancer we just created. So, let's go ahead and remedy that. Let's go ahead and open up SSH sessions to `web1`, `web2` and `web3`. Let's look up the IP address of the internal load balancer.
20
+
21
+
To do that we'll do an `nslookup` and then the domain name, and as I said, an internal load balancer's fully qualified domain name is resolvable only within its `VPC`.
The load balancer, because it's using the internal scheme, does not have a publicly routable IP address, nor does it have a publicly resolvable domain name. That means the traffic between our web tier and our application tier is going to stay within the `VPC`. It is not going to ever hit the internet.
41
+
42
+
Okay, the first order of business is to destroy the web server container we created earlier. We need to destroy it so we can create a new one that's configured to point to the internal load balancer. So we're going to do a sudo docker ps and we will destroy the container by referencing a portion of its container ID, sudo docker rm and 79 and then ‑f to force deletion.
43
+
44
+
```bash
45
+
docker ps
46
+
```
47
+
48
+
```bash
49
+
docker kill<container id>
50
+
docker rm <container id>
51
+
```
52
+
53
+
Now, I'm going to paste in a much longer command. The command is the same as before except for an additional ‑e parameter. This parameter sets an environment variable containing the full URL of the internal load balancer, including the port 8080. The logic of the web front end looks at this environment variable to determine how it should connect to the application tier. So just think of this as reprogramming our web front end and telling it how to connect to the application back end. Make sense?
All right, let's go ahead and hit Enter here, and let's jump over to our SSH session with `web2`. We're going to do the same thing here, sudo docker ps, sudo docker rm, part of the Docker container ID, delete that, and I'm going to paste in another command. There we go.
63
+
64
+
```bash
65
+
docker ps
66
+
```
67
+
68
+
```bash
69
+
docker kill<container id>
70
+
docker rm <container id>
71
+
```
72
+
73
+
Notice that the host name here is web2, `‑h web2`,
Here on web3, sudo docker ps, sudo docker rm 6e, and then one last command here and hit Enter. All right. So, web1, web2, and web3 are all pointing to the internal load balancer.
102
+
103
+
Next, let's go back over to the EC2 service console and take a look at our load balancers. Go take a look at the web‑lb load balancer, grab the DNS name for that, just go ahead and copy it to your clipboard, open up a new tab, and then let's browse to it. Now, check this out. Look under the App Server Information. It shows the container host name is app3, the protocol is HTTP, and the port is 8080. Let's go ahead and hit F5 to refresh, and this time we get a different application server. So, we know internal load balancing is working. Also, notice the web server, web1. If we refresh again, we get load balanced to another web server, which is the behavior we saw earlier. So this looks great.
104
+
105
+
But we've got one more piece of the web application that we need to get working, and that's the database. Notice at the top we've got two buttons, View Data and Enter Data. Let's click on View Data. Now, clicking this button sets off a chain of events. First, the web server that we're connected to reaches out to one of the application servers. The application server then tries to open a connection to a Mongo database, pull all the records from a certain table, and then pass those records back to the web server. The web server then, in turn, should display those records. But, that doesn't happen. Instead, we get a big ugly ERROR: DATABASE SERVER UNAVAILABLE because obviously we haven't set up the database server yet, so that is exactly what we're going to do next.
0 commit comments