for-aws
for-aws copied to clipboard
docker-archive
Add Support for the Application Load Balancer (ELB v2)
The current cloud formation template creates a Classic load balancer (ELB v1). The newer Application Load Balancer (ELB v2) has the ability to route HTTP requests. I'd like to be able to do the following:
https://example.com --> Application Load Balancer (ELB v2) --> http://my-docker-service:5000
What is the current recommended approach to do the above? I can think of a few options:
- What happens if I delete or turn off the Classic Load Balancer and create an Application Load Balancer in it's place. I'm assuming this would be bad and an upgrade of the cloud formation template would undo my change.
- Use an nginx container.
- Create an Application Load Balancer and point it at the Classic Load Balancer. This is not ideal from a cost and complexity perspective.
@RehanSaeed thanks for the request, it is on our list. In the meantime we recommend your second option, using nginx or haproxy in a container to handle this host based routing.
Traffic -> ELB -> Nginx/HaProxy container -> Services
@RehanSaeed something along the same lines as haproxy you might want to consider that I've had good experience with is docker-flow-proxy which has a wrapper around haproxy to allow you to use swarm labels to configure host and route based reverse proxies including SSL certificate and https redirect support.
Check out the documentation here: http://proxy.dockerflow.com/swarm-mode-auto/
Without this feature you can't really easily build internet facing apps without some extra leg work, so it'd be pretty high up on my wish list. Do you have a rough idea about when this feature would make it live, no pressure, just need to make plans?
I just wanted to throw something up quickly, so I tried throwing up an Application Load Balancer (ALB). I had a container running on port 8080 so I:
- Created an ALB using the same VPC as my docker stack and waited until it's status changed to active.
- Created a CNAME entry in Route 53 to point mycontainer.example.com to my ALB DNS name.
- Created ALB Listeners on port 80 and 443.
- Created an ALB rule to point mycontainer.example.com to a custom target group.
- Created said target group listening on port 8080 over HTTP and targetting my docker EC2 instances, also on port 8080.
Unfortunately, navigating to mycontainer.example.com over HTTP or HTTPS does not resolve to anything. Did I do something wrong? Is there something in the Docker stack stopping this from working?
Check security group association. Make sure your your ALB is a member of you ELB security group. Otherwise it seems right.
I'd like to give my +1 to this, for a different use case: websockets. Classic LB's don't support web sockets, while ALB's do. I'm working on a tweak to the CF template to make this happen, but it's not been straightforward so far.
any news on this issue? I also need it for websockets.
@tomlancaster did you find any way around this?
Really appreciate all the work that has gone into the project. Another reason is http/2 support. But I understand that ALB is not available in all regions.
So I modified the stable template and replaced the ELB with an ALB. Seems to work. Please feel free to incorporate and let me know if there is anything wrong with it.
@pieter-vandenburg, assuming you've been using your patch over the past month or so, what's been your experience thus far?
@tomalok It worked for the week or so I played with it. In the end I just went with native ECS Container Services.
FWIW, I gave it a try, and although the ALB was created, no further configuration was done to it when I exposed ports from containers and/or services...
Sorry to waste your time. 🙁
On Jan 8, 2018 1:35 AM, "tomalok" [email protected] wrote:
FWIW, I gave it a try, and although the ALB was created, no further configuration was done to it when I exposed ports from containers and/or services...
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/docker/for-aws/issues/83#issuecomment-355892171, or mute the thread https://github.com/notifications/unsubscribe-auth/AfaMKwEgPo09zntJ3mvZOMXRqxP2XOmsks5tIbcugaJpZM4Omwy4 .
@seriousben (and others) - hopefully my question is relevant enough to post here, please advise otherwise:
Currently I am using websockets with normal ELB/TCP:
Traffic -> ELB -> Nginx -> NodeJS service (using 'ws' npm pkg)
Quite often I see in the server logs
error WebSocket is not open: readyState 3 (CLOSED)
and the client not knowing that the connection is in fact closed. Am still in the process of properly debugging this, but I have heard advice that ALB (instead of Classic ELB) will make this problem go away with the way it persists connections, but wouldn't adding the ping from the server also make the connection a bit more stable (or better chance of staying persistent) whilst still using Classic ELB?
Sidenote: the typical usage of this websocket connection is from a mobile client primarily being used when not on WIFI.
From experience the best way to detect connection drops is to both send pings from the servers and to even implement ping/pong at the application level.
Slack's websocket API is a good example of this.
On Sun, Apr 8, 2018, 06:46 0v3rst33r [email protected] wrote:
@seriousben https://github.com/seriousben (and others) - hopefully my question is relevant enough to post here, please advise otherwise:
Currently I am using websockets with normal ELB/TCP:
Traffic -> ELB -> Nginx -> NodeJS service (using 'ws' npm pkg)
Quite often I see in the server logs
error WebSocket is not open: readyState 3 (CLOSED)
and the client not knowing that the connection is in fact closed. Am still in the process of properly debugging this, but I have heard advice that ALB (instead of Classic ELB) will make this problem go away with the way it persists connections, but wouldn't adding the ping from the server also make the connection a bit more stable (or better chance of staying persistent) whilst still using Classic ELB?
Sidenote: the typical usage of this websocket connection is from a mobile client primarily being used when not on WIFI.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/docker/for-aws/issues/83#issuecomment-379540386, or mute the thread https://github.com/notifications/unsubscribe-auth/AF3FjoMAicyPBwuDnYptkenBxsy6fIrlks5tmeqbgaJpZM4Omwy4 .
@seriousben when you say at the application level I assume you mean on the client side application?
@rafagsiqueira Could you please share how you've setup the redirect using Traefik? I haven't been able to do this. I use the aws elb with traefik as well -> but http to https redirect is something I've not been able to achieve...
@Narrator I meant I have been using traefik and ELB v1. I also want ELB v2 to be able to do https using amazon certificates. I believe we are on the same boat. Sorry for the delayed answer.