[Proposal] Run app and sidecar separately without requiring hardcoded ports

[artursouza]

Today, when debugging locally, users run the sidecar separately with hardcoded ports and then run the app from the IDE using env variables with the same ports as the sidecar.

Could there be a solution where the app can connect to the right sidecar without requiring the dapr ports environment variables?

One option would be to offer a feature in the SDKs where the SDK can discover which sidecar to connect to based on the app id. How to discover the dapr ports based on the app id still not clear at this point. Dapr CLI does that by inspecting the cmd arguments of the processes but that does not seem to be a good solution for an SDK.

/cc @rynowak @yaron2

[withinboredom]

What about just a simple yaml/json file in dapr-cli's folder? I don't think it has to be anything fancy and dapr-cli knows which apps/ports things are running on.

[artursouza]

@withinboredom We had that file before and we had all kind of issues keeping that in sync to what was actually running. The file would not be updated on some situations and users saw "zombie" dapr instances. We fixed that with a major refactoring, so we use the system information + metadata API to build the dapr list output.

[withinboredom]

Ah, good to know

[rynowak]

One option would be to offer a feature in the SDKs where the SDK can discover which sidecar to connect to based on the app id. How to discover the dapr ports based on the app id still not clear at this point. Dapr CLI does that by inspecting the cmd arguments of the processes but that does not seem to be a good solution for an SDK.

If this is for local dev only, it could be based on mDNS - however, I'm not sure how widespread the availability of mDNS libraries are for different languages.

Another option would be a domain socket (named pipe on windows). This is how tools like dotnet counters work. Every .NET Core process creates a domain socket in a well-known location with the PID as part of the name (we could do the same with the app-id). https://lowleveldesign.org/2021/01/20/snooping-on-net-eventpipes/ I'm not sure how widespread the ability is to use this domain socket for outbound HTTP traffic to the app. If we investigated this it might be better to just use it to discovery the set of ports. You could really do the same with a well-known file as well.

[artursouza]

@rynowak I think UDS is the way to go here. The thing is that it works well for gRPC but not so sure about HTTP. I did a quick search and it might be possible to get it to work in HTTP too.

So, instead of daprd listening to two ports, it will listen on two UDS sockets.

[ionut-balazs-lateral]

@artursouza
Does this mean that dapr run could support a new --app-protocol which will result in inter-process communication between sidecar and application (UDS or names pipes)?

[artursouza]

@ionut-balazs-lateral This is not for --app-protocol (initially, at least) but for the daprd endpoint.

So, in standalone mode: dapr run --app-id myapp --dapr-grpc-socket -- python3 app.py would cause daprd to listen on grpc in $HOME/.daprd/sockets/myapp.sock

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[dapr-bot]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as pinned, good first issue, help wanted or triaged/resolved. Thank you for your contributions.

[daixiang0]

As #3502, potential solution is Unix domain socket.

[daixiang0]

/assign

[yaron2]

/assign

Please make sure to put the design here

[daixiang0]

POC design(only consider standalone mode):

For daprd:
Add --enable-grpc-socket option, create socket file named as appid-http.socket and appid-grpc.socket and delete them when exit.

For dapr cli:
Call this option and use this option to connect.

[artursouza]

Reopening until the solution is working end to end.

[artursouza]

@daixiang0 Can we also add support for Windows?

[daixiang0]

Need to dig into it due to little Win development experience first, if someone is interested in it, feel free to assign to him.

[daixiang0]

After a quick google, socket support for Window is very young, I do not consider add support for Windows for now.

[daixiang0]

@artursouza please review dapr/cli#788, after it merged, we can announce this feature.

[wmeints]

It would be really nice to have this on Windows too. It makes the experience for devs a lot better. You mention this feature is pretty new on Windows. Does this mean it's too unstable to be used there?

[artursouza]

Support for this feature on Windows will be tracked in #4128

[artursouza]

Retroactive creating issue to track when feature was added for Linux only: #4129

[artursouza]

This issue is now marked as an Epic, which means it is not fixed to a single milestone.