AWS ECS name resolution component

[yaron2]

It'd be great to add support for service invocation in AWS ECS so that Dapr sidecars can communicate between them securely.

Name resolution components sit here: https://github.com/dapr/components-contrib/tree/master/nameresolution.

Info on AWS ECS dns: https://aws.amazon.com/blogs/compute/service-discovery-for-amazon-ecs-using-dns/.

For anyone who wants to pick this up, please respond /assign in this issue.

[daixiang0]

I do not know the details of that, my concern is that each CSP has its own DNS service, is it better to add interfaces to call extern DNS rather than add?

[fbridger]

@yaron2 I believe @daixiang0 is correct. Currently, we were able to enable ECS Service Discovery and assign each ECS Task it's own DNS Name.

For example: We currently have 3 ECS Tasks running using the same namespace ecssd.com:

• Placement Service:
  • DNS = place.ecssd.com
• CustomerA
  • DNS = customera.ecssd.com
  • SideCar using ./daprd -app-id customera.ecssd.com -placement-host-address place.ecssd.com:50005
• CustomerB
  • DNS = customerb.ecssd.com
  • SideCar using ./daprd -app-id customerb.ecssd.com -placement-host-address place.ecssd.com:50005

CustomerA and CustomerB can communicate without any problem to Placement. CustomerA App and CustomerB can communicate directly without problems between each other

However, Dapr Sidecars Service to Service communication fails with the following error: fail to invoke, id: customera.ecssd.com, err: invalid app id customera.ecssd.com

Also, it evens fails when CustomerA Sidecar tries to communicate with it's own "CustomerA" app.

How hard would it be to implement what @daixiang0 is suggesting? I can volunteer to do this if it is in my reach.

[fbridger]

@daixiang0 I've noticed an unmentioned dns nameresolution component

Might this solved our problem and be used for ECS Service Discovery?

[fbridger]

@yaron2 @abogdanov37 Could the dns resolution included in PR https://github.com/dapr/dapr/pull/2903 might help us here?

[abogdanov37]

@yaron2 @abogdanov37 Could the dns resolution included in PR dapr/dapr#2903 might help us here?

Hi @fbridger! I think yes. It can resolve to use any DNS services. Maybe it needs some fixes. If that I will help with pleasure.

[fbridger]

Thanks for your reply @abogdanov37!

@yaron2 @daixiang0 or @artursouza could any of you confirm this and suggest next steps to get the DNS resolution component merged and available to everyone?

[yaron2]

@fbridger @abogdanov37 @daixiang0 a general purpose DNS component can certainly do the trick here, but I want to get in the weeds about how this is going to work.

for example, one implementation can be that the ID of the target app IS actually the target DNS address. Or, we can configure the base DNS address in a component, like:

apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
  name: appconfig
spec:
  nameResolution:
    component: "dns"
    configuration:
      baseAddress: ecssd.com

And then the app-id is customera and customerb. Thoughts?

[fbridger]

@yaron2: Having to configure the namespace or domain would definitely work in our implementation.

However, there may be scenarios where you may want to use different namespaces or domains for DNS entries like customera.ecssd.com and customerb.otherecssd.com.

So I would try to keep things as simple as possible (minimum yaml configuration) and allow AppIds to fully contain the entire DNS entry. If this is the case, would additional code changes be needed in Dapr Sidecars to support full DNS names in AppIds?

[abogdanov37]

@fbridger @abogdanov37 @daixiang0 a general purpose DNS component can certainly do the trick here, but I want to get in the weeds about how this is going to work.

for example, one implementation can be that the ID of the target app IS actually the target DNS address. Or, we can configure the base DNS address in a component, like:

apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
  name: appconfig
spec:
  nameResolution:
    component: "dns"
    configuration:
      baseAddress: ecssd.com

And then the app-id is customera and customerb. Thoughts?

Hi everyone! In current dns implementation I based on NAMESPACE. In my opinion, it is enough. If you have any cases in with it is not work please share it.

[fbridger]

@abogdanov37 Do you mean the namespace that is configured in the config.yaml

Example:

apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
  name: config
  namespace: default # THIS NAMESPACE?

If this is the case, doing a Service Invocation from customerA to customerB like http://localhost:3500/v1.0/invoke/customerB/method/ping would result in a HTTP request to customerB.default ([AppId].[namespace]) ?

[yaron2]

Actually, thinking about this more, for simple "bring your own DNS" use cases (which I come to realize are important) we should decouple the name resolution component from the "discovery" aspect of it.

I propose the following:

An app can specify the address of the service it's calling via an HTTP header for HTTP requests and a new proto field on the Invoke method for gRPC calls.

Example

This example shows an app calling a different app, named serviceB over a well known DNS address:

curl http://localhost:3500/v1.0/invoke/cart/method/add -X POST  -H 'dapr-app-address: serviceb-prod.mydomain.com:8080'

This effectively tells Dapr "for this call, override the name resolution lookup".

@artursouza @beiwei30 what do you think?

[abogdanov37]

@abogdanov37 Do you mean the namespace that is configured in the config.yaml

Example:

apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
  name: config
  namespace: default # THIS NAMESPACE?

If this is the case, doing a Service Invocation from customerA to customerB like http://localhost:3500/v1.0/invoke/customerB/method/ping would result in a HTTP request to customerB.default ([AppId].[namespace]) ?

Yes!

[abogdanov37]

Actually, thinking about this more, for simple "bring your own DNS" use cases (which I come to realize are important) we should decouple the name resolution component from the "discovery" aspect of it.

I propose the following:

An app can specify the address of the service it's calling via an HTTP header for HTTP requests and a new proto field on the Invoke method for gRPC calls.

Example

This example shows an app calling a different app, named serviceB over a well known DNS address:

curl http://localhost:3500/v1.0/invoke/cart/method/add -X POST  -H 'dapr-app-address: serviceb-prod.mydomain.com:8080'

This effectively tells Dapr "for this call, override the name resolution lookup".

@artursouza @beiwei30 what do you think?

IMHO. In this case, we move the discovery function to client. And we will have problems with deployment in different environments. For example, deploy on test and on prod. We should change addresses in all calls. In another case, if we want to divide discovery ability from name resolution we should exclude consul name resolution.

[fbridger]

@yaron2 @artursouza Any thoughts about this PR (https://github.com/dapr/dapr/pull/2903) on how we could allow the "bring your own DNS" feature so Dapr can work in environments like AWS ECS?

[jigargandhi]

/assign

[jigargandhi]

I can take up the work forward We can implement cloud specific DNS resolution based on the same DNS component in components contrib. Of course this will need to provide configuration for authentication in the component yaml.

@fbridger for your suggestion regarding full DNS entries, what would be the use cases for that, do you think that services may also be called externally, can we use CNAME for that redirection

[fbridger]

AWS ECS has integrated Service Discovery. We would like to simply be able to simply use the DNS name provided by this feature. I think this also applies to many other DNS components.

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html

https://aws.amazon.com/es/blogs/aws/amazon-ecs-service-discovery/

[Jan-Jasek]

Any update on this?

[itsoli91]

Any update on this ?

[dkuida]

Actually, thinking about this more, for simple "bring your own DNS" use cases (which I come to realize are important) we should decouple the name resolution component from the "discovery" aspect of it.

I propose the following:

An app can specify the address of the service it's calling via an HTTP header for HTTP requests and a new proto field on the Invoke method for gRPC calls.

Example

This example shows an app calling a different app, named serviceB over a well known DNS address:

curl http://localhost:3500/v1.0/invoke/cart/method/add -X POST  -H 'dapr-app-address: serviceb-prod.mydomain.com:8080'

This effectively tells Dapr "for this call, override the name resolution lookup".

@artursouza @beiwei30 what do you think?

I wonder - what are the options currently to invoke a remote gRPC service.