[Proposal] Provide alternative service resolution mechanism besides mdns #3256
Comments
wcs1only
changed the title
|
We can point users to use Consul in self hosted mode. Alternatively, if we find another cross machine self discovery mechanism that doesnt involve an external agent (as this is already provided with Consul) we can consider that. |
I'm hoping for a solution a little more out of the box than "point users to this." This seems to be tripping up users on the quickstart hello-world path, and the last thing I'd want to do is introduce another thing to install/understand before getting started. |
wcs1only
changed the title
|
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 (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions. |
|
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. |
|
It would be really nice for there to be a simple alternative for self-hosted systems where this is an issue. There is something with our corporate network that is blocking service to service invocation. Every time I think I've worked out how to work around it, it comes back. I can imagine this could be a very frustrating issue for people trying out Dapr for the first time. |
|
@mukundansundar Any idea on this? |
|
Here are a few thoughts from an offline conversation: Yes, Consul would absolutely work, but is another container that the CLI would have to install. An alternative is to add "Consul lite" functionality to the placement service. This could range anywhere from a "local only mode" which holds a simple in-memory lookup table to a fully distributed/replicated lookup table via Raft. The placement service already handles replicating the actors placement table. In theory, adding general service addresses could make use of existing infra/replication code. One could ask "are you just recreating Consul"? Yeah sort of. That aside, assuming the goals are 1) lightweight/no additional installation footprint, 2) satisfies Dapr service invocation without the pitfalls of mDNS and potentially 3) operate in a distributed setup, then this approach could make sense. /cc @artursouza |
|
Could we have a local resolver component that is just a flat file in ~/.dapr/ ? |
|
Alternatively, we could do whatever |
|
|
|
I don't support expanding the placement service to provide service discovery, although I am guilty of suggesting the same in the past. Assigning extra responsibilities for a component that is targeted at placing actors just because it's the nearest neighbor isn't something I can advocate for. I do support creating a local name resolution component that's explicitly clear about providing dev/single-box discovery. Using it would be as simple as configuring the following: apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: appconfig
spec:
nameResolution:
component: "local"The CLI could be configured to register the |
|
For the local component, we could replicate similar logic to Consul but have it in a datastore for example Redis. Since we are already using Redis as a state store an an actor store we can use it for service resolution also I think. This way a service can self register on Init and perform GET requests on ResolveID calls. The potential issue in this is in the slim mode the fallback will still be mDNS or Redis needs to be stood up separately and used for service discovery. One more concern is deregistration of the service once it is shutdown . Currently we do not have a onShutdown handle regarding name resolution for deregistration ... One option is extend the name resolution interface to handle onShutdown ... This will help with the current Consul component also. |
|
@mukundansundar @yaron2 any concerns with using the |
|
I do not support using Redis or any state store for service discovery purposes as that would create a tight coupling between a state store and a name resolution component. @pkedy I'm fine with a file based approach or whatever |
|
@wcs1only would using Gossip directly be a viable alternative to mDNS? I think based on this article even Consul uses Gossip under the hood for membership and there's other projects in this space such as https://github.com/newrelic/sidecar. |
|
This may already be covered by another issue, but a work around for me works as follows:
This is pretty painful in development as I do restart the apps often as I make changes. If my application didn't have to access the corporate network, that wouldn't be a big deal though. I'm going to work on running dapr on WSL/ubuntu since I could at least script the startup/shutdown of the apps and vpn. |
|
I have confirmed that if I use openconnect in WSL and run my apps in WSL, I can run everything without issue. That does prevent me from using VPN on the host, or at least requires me to start/stop vpn, but I can work around that at least. |
|
Configuring the name resolver to resolve only dapr sidecars on local computer would be much needed feature for us. We have quite opposite issues with dapr in development but this should fix them too. When developing in office environment where mDNS is allowed, Dapr resolves to services on other developers' computers. This is because mDNS packets are thrown to the same network which other computers can see. We have tried blocking inbound mDNS packets on Windows Firewall but somehow they don't get blocked at all. If blocking outbound mDNS, the name resolution stops working completely. Do you have some estimate when this will be implemented? Currently this pretty much blocks us from using dapr in local development. |
|
We found a solution for our issues which is to use Consul. However, the guide on Dapr docs doesn't give simple and complete example how to use Consul as name resolver in local environment. Thankfully I found this great article that contains simple enough instructions for that. You could include such an example on the Dapr Docs Consul page. |
Thank you. It's been two years since this issue was raised, but Dapr has not yet provided an official solution. |
|
Let's get this done for 1.13, for local development scenarios using SQLite. |
|
Adding that on CLI 1.11.0/Runtime 11.1.4 this is still an issue (Windows 10). |
|
New name resolver (backed by SQLite) is implemented in #7038 Whether that becomes the new default for the local DX is an issue that should be discussed with the runtime and CLI maintainers. |
|
@ItalyPaleAle Is this "Whether that becomes the new default for the local DX is an issue that should be discussed with the runtime and CLI maintainers." tracked as an issue? |
and others
In what area(s)?
/area runtime
Describe the feature
We commonly get reports that service invocation does not work with dapr standalone mode:
#2665
dapr/quickstarts#361
dapr/quickstarts#388
dapr/quickstarts#399 (May also be a general failure to start daprd?)
dapr/python-sdk#146
... and a bunch more across various SDKs/docs repos
We've root caused most of these to security/VPN configurations blocking mdns requests. The fix varies heavily based on which OS/security software the user is using. It would be lovely to have a generic solution to this, either by falling back to another service discovery mechanism if mdns doesn't work, or replacing mdns outright with something else.
Release Note
RELEASE NOTE:
The text was updated successfully, but these errors were encountered: