Built-In Service Discovery / Ingress

[Danielku15]

Hi everyone.

It would be great if yarp would provide some built-in Service Discovery mechanisms without the need of relying on K8S, Consul, Eureka etc.

Maybe Service Discovery is not really the right term. What I'm rather thinking is a simplified version of the Tunneling feature discussed here. The usecase is like:

I am providing my applications a configuration containing:

• Where to find YARP
• How to authenticate against YARP
• To which service type + cluster (composite cluster id) they belong.

Whenever an application is started in a dynamic scaling environment (no matter whether K8S, custom orchestration like manual installation, Ansible, Azure App Services) it will connect to YARP and register itself in the cluster and perform a regular health-check & keep-alive.

At this point everything is as usual: YARP will look in the list of destinations which were dynamically registered through the process above.

Has this been discussed within the YARP community already? I was thinking that with a custom API (or maybe websocket channel) I guess I could handle this also as a custom YARP extension but something more common/standardized/built-in is always preferrable 😁

[Tratcher]

Self-registering destinations hasn't come up. This could be done as an implementation of IProxyConfigProvider that was updated from a listening endpoint. The protocol doesn't matter (HTTP/REST, WS, etc.). You're right to call out that this endpoint would have to be secured.

The biggest downside is that it also requires a client on each node being proxied to, written in the language of that client (Java, node, .Net, etc). For that reason you'd want to keep the interaction as simple as possible, likely some REST HTTP calls. That's one reason it's generally preferable to rely on an orchestrator for the discovery. Another is that you'd need a garbage collection mechanic for destinations that go offline for too long and can't self-unregister.

[Danielku15]

Thanks for the input. A few hours later I have an operational and running version of my concept now. Roughly 150 Lines of Code for the client part, Roughtly 600 Lines of Code for the server part. It is at this point not super resilient but the mechanism of maintaining the available destinations of a cluster through WebSocket channels works fine.

The only pain point was that many things of the built-in configuration loading are internal. I still want to load the main part of my route and cluster configs from the IConfiguration but cannot utilize the built-in ConfigurationConfigProvider for that. Maybe I file an Issue to make this provider part of the public API so others can inherit, extend, and use it for their purposes.

[Tratcher]

Awesome. Can you show how you did it, perhaps as a github repo?

[Danielku15]

Yes, still need to find some time to extract the relevant parts into a standalone repository. I made the extensions directly as part of a product we're developing. 😉

[eyalg-msft]

Hi @Danielku15,
We also use YARP and we need a dynamic update (periodic) of our destination list.

This is what we did:

1.Added a BackgroundService which I called "ConfigurationUpdaterBackgroundService" that runs every 3 minutes.

2.On the ConfigureServices when creating our new BackgroundService we use the service provider to get the IProxyConfigProvider and pass it to the background service constructor.

services.AddHostedService<ConfigurationUpdaterBackgroundService>(serviceProvider => new ConfigurationUpdaterBackgroundService(proxyBuilder, ServiceInstanceFinder, Configuration, serviceProvider.GetRequiredService<IProxyConfigProvider>()));

3.The BackgroundService will now periodically check for updates in the list (we have another service to get it), and if needed it wil call the Update function of YARP:

this.reverseProxyInMemoryConfigProvider.Update(routes, clusters);

I would be happy to hear your thoughts of this solution. Is this the right way to do it? do you have a recommendation to do it diffrently?

[Danielku15]

I quickly put a standalone project together with our PoC. As announced: not super sophisticated at this point but it does its job 😁 It also shows a bit the pain point of not being able to use the default config classes and loaders.

https://github.com/Danielku15/yarp-service-discovery