-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatic route creation based on microservices registered to Consul, Eureka #340
Comments
@OrionDevelopment thanks for your interest in the project! I think that this could be done! Ocelot could definitely be configured to use first segment of request path as a key when looking up the service to call. The only annoying thing would be changing the validation and ReRoute creation code to not need pre configured ReRoutes but this might be easier than I imagine! I'll take a look when I get some free time 😄 |
@TomPallister If you need help, point me in the right direction. Would be amazing if this can be controlled via DI as well. |
@OrionDevelopment I think that the main thing is the DownstreamRouteFinderMiddleware + deps, this will not find a ReRoute and then return a 404. It needs to be changed to handle requests that dont have a ReRoute. Then LoadBalancingMiddleware.cs + deps would need to be changed to use the first path segment as a key and that is pretty much all you have to change (I think!). |
@TomPallister Are you guys using the normal DI injection from .Net Core (so IServiceCollection/IServiceProvider), if so we might be able to do this nicely with a decorator pattern? |
@OrionDevelopment sorry I missed this, so many issues!! I just started a new job so I don't have much time at the moment either :( Yes we use normal DI but I would not do this using decorator pattern as we havent used it anywhere else in Ocelot now and I'm not sure I would want to introduce a way of solving problems that isn't consistent. The way this would normally be done in the Ocelot code base is with factory returns different implementation of some interface based on some values. In this case I would look at the condig decide that we were not using typical routing and do whatever needs to be done. It might even be easier than this! I dont have the whole code base in my head I'm afraid :( |
Ah Okey. Good to know. Will take a look. |
* #340 started looking at supporting automatic routing when using service discovery * #340 getting old routing tests to pass * #340 renamed stuff to provider rather than finder, as its not longer finding anything * #340 working towards supporting dynamic routing * #340 loads of refactoring to make configuration work with dynamic routing * #340 refactor consul config code so the registry class owns it * #340 default to consul to maintain backwards compat * #340 added docs, finished this branches todos
@OrionDevelopment Ive just pushed version 7.0.1 and this has the changes for dynamic routing with service discovery. Check out the docs here. Let me know if this works for you or if you think we could make it better. |
To clearify. |
@OrionDevelopment yes it does, consul is just used as an example. I will make that clearer. |
Okey. Cool. |
Well done! But I have another plan, and it works pretty well. I store the configuration files to consul, and then write a common API server boot container, read the configuration from consul when the service starts, and update it dynamically! Example:
|
how to deal with the api start with “api” |
As far as I know that is not possible at the moment. |
Hi! As i understand, this feature work only with Consul / Eureka? If i don't use Consul / Eureka, this setting in GlobalConfigurations don't work and then application start i get next error: "Exception: Unable to start Ocelot, errors are: When not using service discovery DownstreamHostAndPorts must be set and not empty or Ocelot cannot find your service!" Configuration example: {
} |
can I get conventional routing i.e it automatically maps all the routes in the ocelot.json |
Expected Behavior / New Feature
It would be amazing if Ocelot could create and remove routes depending on the services registered in Eureka and/or Consul. We are currently looking to move most of our Microservices to .Net Core and we are currently looking for a replacement for the Zuul-Eureka-Combo that automatically routes all request for a given service to it:
Example:
https://system.com:80/auth/<request_for_auth_service>
--> Here the /auth/ is the service name registered in Consul and/or Eureka
http://auth:5000/<request_for_auth_service>
--> Here the root address: http://auth:5000/ gets pulled from consul and/or eureka.
Actual Behavior / Motivation for New Feautre
As of now we could not find a away to do this without additional software which called the administration API and updated the routes on its own.
Specifications
Docs
The text was updated successfully, but these errors were encountered: