Closed hffmnn closed 4 years ago
@hffmnn One of the current limitations of Virtual Services is that their names must resolve via DNS to an IP address from the perspective of the application, otherwise it will fail to make a request. However, for the case of HTTP traffic, that IP address can be almost anything, as once the request is intercepted by the Envoy, the HTTP authority (host) header is inspected and the actual destination determined and routed to.
So for the color app example, we set the white virtual node's host name to the same as the virtual service just so there would be a DNS A record for colorteller.${ServicesDomain}
. You could in theory set any of the virtual nodes to that hostname, so long as all the virtual nodes behind the color teller virtual service have unique discovery names. Or you could add an arbitrary A record for colorteller.${ServicesDomain}
in your DNS registry to achieve the same effect.
See https://github.com/aws/aws-app-mesh-roadmap/issues/65 for a little more information on this current limitation. We're hoping to resolve this issue by having Envoy respond to the DNS queries made by the application behind it.
Thanks @bcelenza for this great explanation. 🙇
Describe the bug Trying to understand the mesh setup in the ECS walkthrough, I stumbled upon this line of code: https://github.com/aws/aws-app-mesh-examples/blob/master/examples/apps/colorapp/servicemesh/appmesh-colorapp.yaml#L99
The
DNS:Hostname configuration
of theColorTellerWhiteVirtualNode
is the same as the name of the virtual service (colorteller.${ServicesDomain}
). Looking at the other color nodes, the all have their color in the DNS name, e.g.colorteller-red.${ServicesDomain}
.Also the mesh overview image shows the name of the virtual node as
colorteller-white
.Platform ECS
To Reproduce Steps to reproduce the behavior: See the linked code above.
Expected behavior I expected the mesh setup not to work and wonder why it works at all? Shouldn't the DNS entry be unique? Note: Looks like the setup still works.