Reputation: 567
Recently started using Network Load Balancer which listens on port 80 and forwards traffic to my target group. My autoscaling group is configured to add any new targets to this target group.
However, my application on the target EC2 instances runs on port 8001, not 80. So my targets should register under port 8001 in the target group. The auto-scaling configuration doesn't seem to support that. All new instances created by auto scaling are added as targets with port 80 and there is no way to auto specify which port that should be used instead (8001 for me).
Any ideas how to implement this?
Upvotes: 3
Views: 3314
Reputation: 30135
I was crying over this for hours and the answers here gave me a clue and finally, I found out what the heck is going on!
The story of ports can get complicated, but let's clarify them.
It's crucial to know that you are dealing with 4 ports here! So let's name them one by one.
(I am using ECS, but the same applies to anything else that manages your code to ELB.)
The port where the Load Balancer receives traffic. Usually 80 or 443.
The port where the Target Group is set to work on. It's baked into the Target Group at the time of creation of TG (as jpact mentioned) and shows in the description. You cannot change it later.
You, however, can set the health-check of the Target Group on a different port, but it doesn't help you have a working set-up.
This is the port that the container is giving out and expects to receive traffic.
This is the port your code (say a Node.js app) is actually listening to.
The thing is P2 (TG's) and P3 (container's) can differ. In fact, you will not even face a challenge if they are set to arbitrarily different numbers, initially.
When you register a Service's container to a TG, no one asks about ports and it can work well. You just say attach this container to that TG and it automatically pick's the "container's" port (P3) here.
And then if you go to your TG's page you will see it is on the container's port (P3) which is a different port that the TG's (P2), but it works well and who cares!
The headache begins when you add Auto Scaling with healthcheck!
ASG knows it should create instances on TG. However, it needs to assign a port between EC2 instance and TG. And clearly, ASG doesn't know what container (P3) is going to be in it, so by default it picks TG's port (P2). And this is where the craziness happens!
Set TG's port == Container's port. They can be anything you want, but make them match.
Below the container and to to your app (P4) you can have a mapping. Above TG (on LB) you have another port mapping (P1). But these P2 and P3 MUST match!
Go ahead, create new TG's with the container's port (P3), wire them to above (ELB) and below (Services) and hopefully it will work well!
PS. Apparently, you cannot change a Service's TG! So new Service as well... :)
Upvotes: 1
Reputation: 1072
What kind of application are you using (web server, application server, ...)? Maybe ALB would be more suitable for you as it works on layer 7 of OSI model, therefore it is able to proccess HTTP headers, for example.
Back to your question; To be able to forward traffic to your EC2 instances, that runs application on port 8001, you have to set port on your target group to 8001. Auto-scaling group knows nothing about what application is running on EC2 it provisions, nor about ports that are used by that application.
So the final flow is like:
LB listens on port 80 and forwards traffic to target group on port 8001. This target group then sends traffic to its targets (your EC2 instances) on port 8001.
Upvotes: 2
Reputation: 34754
The port definition in the target group is the port definition you're looking for. The port in the target group is the port on which the targets receive traffic. The port on the listener is the port on which the load balancer listens for requests.
So you should set port 80 on the listener and port 8001 on the target group.
Upvotes: 3