Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create an example tutorial for how to use ALB/NLB with App Mesh #119

Closed
bcelenza opened this issue Apr 4, 2019 · 7 comments
Closed

Create an example tutorial for how to use ALB/NLB with App Mesh #119

bcelenza opened this issue Apr 4, 2019 · 7 comments

Comments

@bcelenza
Copy link
Contributor

bcelenza commented Apr 4, 2019

Create a new example tutorial that focuses just on when and where to use ALB/NLB with AWS App Mesh.

@subfuzion subfuzion self-assigned this Apr 17, 2019
@rverma-nikiai
Copy link

We are also interested in this. We are using aws-alb-ingress-controller with the target as IP.
The first roadblock is the target group health check starts failing as soon as we add the proxy. It happens transitively with the liveliness also( #137), even if we disable the liveliness the ALB can't sense the app-mesh virtual node health check. I think its time for a new target type for ALB which is VirtualNode. It enhances the experience of ALB with respect to App mesh across services EC2, ECS, EKS, etc.

Probably it also allows SSL termination at the virtual node.

@tomaszdudek7
Copy link

Indeed, I struggle to find any information how would one connect ALB to a Virtual Router. Is it even doable? My use case is pretty simple - I would like to do canary deployment on both publicly and privately accessible services and thought about utilising App Mesh to do it.

Example scenario:

  • there is an ALB pointing to Virtual Router which leads to Virtual Node vn_app:1.0.0(which points to ECS Service app:1.0.0)
  • I create ECS Service app:2.0.0 and add new Virtual Node (vn_app:2.0.0) pointing to it
  • I add vn_app:2.0.0 to Virtual Router
  • I smoothly transition from 100% traffic vn_app:1.0.0 + 0% traffic on vn_app:2.0.0 to 0% traffic vn_app:1.0.0 + 100% traffic on vn_app:2.0.0
  • I remove vn_app:1.0.0 from the router
  • I destroy vn_app:1.0.0 and ECS Service app:1.0.0.
  • Canary Deployment has been done and ALB did not even know about it (that means both internal communication from other services to app AND external traffic from the internet to app experienced no downtime and smoothly transitioned from 1.0.0 to 2.0.0 at the same time)

Is it already possible? If not, wouldn't it be a proper usecase?

Also, FAQ says that you should use ALB for external traffic and App Mesh for internal, which I fully agree and understand. However, with App Mesh I can fluently switch the traffic between old and new services in internal communication inside AWS. How can I do it both internally and externally(with ALB involved)? If my scenario is not possible then I can't see how is no-downtime deployment possible .

@karanvasnani
Copy link
Contributor

@spaszek So, your use case of connecting an ALB to a Virtual Router isn't doable currently. To achieve the scenario described you'll have to connect the ALB to a Virtual Node first which can then point to the Virtual Router.

A Virtual Router isn't an actual router and is just an abstraction. A Virtual Router needs a source and target Virtual Node to route traffic. In App Mesh, the actual routing of traffic within the mesh is performed by the Envoy proxies that are associated with your source and target Virtual Nodes. Right now, we do not support ALBs as source Virtual Nodes.

Our ColorApp example covers a similar scenario where the ALB connects to the ColorGateway VirtualNode first which then connects to a ColorTeller Virtual Router and route to different versions of ColorTeller Virtual Nodes by updating the Routes.

@tomaszdudek7
Copy link

tomaszdudek7 commented Aug 15, 2019

@karanvasnani

Thanks for clearing it up. Do you mind if we continue? I might be not the only person excited AND having doubts about App Mesh.

Lets say I have Virtual Service A and B with multiple Virtual Nodes running and Virtual Router(VR_A, VR_B) for each of services, load balancing the traffic.

To add an ALB into the mix I have to add a gateway service as Virtual Node whose only job is passing the traffic further, to the "gateway" Virtual Router(VR_gateway) which would then decide (by path) what kind of service should serve the request. If it is A then the request is routed to VR_A, if it is B then to VR_B.

Can you connect Virtual Router to another Virtual Router? If not, my VR_gateway would have to have information about ALL routes in my Mesh, merging VR_A and VR_B responsibilities into VR_gateway. That could work but I might end up having gigantic path routing logic inside only one Virtual Router.

Am I getting this right?

Also, is there any high performant and HA service I'd run on the edge Virtual Node that could just pass the traffic further? Is nginx enough for this? Utilities like zuul seem to be way too complicated for such task, they also have capabilities of Virtual Router which may leave me with unclear responsibilities(should zuul route the trafic or Virtual Router? or maybe both). On the other hand, your ColorApp gateway looks kinda like self-made edge service. Implementing that on my own would require even more manpower, as I would have to create and maintain another microservice in the stack. I am also worried that running such edge service might overlap with ELB (my application is one region only), unnecessarily increasing the cost of the project.

Or maybe I am fighting with a "framework" (well, with AWS) and my use case (canary deployments for internal and external traffic at the same time) is just wrong and can't be done properly yet?

@karanvasnani
Copy link
Contributor

@spaszek
Right now a Virtual Router cannot be connected to another Virtual Router. A Route can only have Virtual Nodes as the weighted targets. So, the VR_gateway in your terminology would not be able to route traffic between VR_A and VR_B.

What you require is having a VN_gateway that has VS_A and VS_B as backends it can talk to. App Mesh currently doesn't support ingress routing so you will have to use an edge service at VN_gateway similar to our ColorApp gateway for this purpose. This proxy should be able to rewrite external request to internal based on the rules you would like your Virtual Services to be routed on. So, on the edge the envoy would redirect traffic to your edge service which will rewrite the external request according to your internal rules and send it back to envoy and now once the traffic is in the mesh it can very well be configured by App Mesh.

You can use any proxy like Nginx, Apache or HAproxy at the edge for this purpose. Also, you should track this open issue #37 on our roadmap to enable ingress routing in App Mesh.

@tomaszdudek7
Copy link

Great, thank you very much for your detailed answers!

@bigdefect
Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants