How to proxy same UpstreamPathTemplate to different service based on remote IP?

[NullRefer]

Hello, I'm using Ocelot as API gateway. And I'm encountering a situation.

As for same UpstreamPathTemplate, I need to proxy it to difference backend service base on request ip address.

Given current configuration

{
    "DownstreamPathTemplate": "/api{catchall}",
    "DownstreamHostAndPorts": [
            {
                "Host": "my-order-webapi-service",
                "Port": 8080,
            }
        ],
    "UpstreamPathTemplate": "/order{catchall}",
    "UpstreamHttpMethod": [ "Get", "Post", "Put", "Delete" ]
}

If ip1, ip2 request for GET /order/1, it goes to my-order1-webapi-service;
If ip3, ip4 request for GET /order/1, it goes to my-order2-webapi-service;
And the other requests go to my-order-webapi-service.

I ask for ChatGPT, it give me an configuration of below. But ocelot starts with exception that /order{catchall} has duplicate.

How could I change my configuration to solve it?

{
    "DownstreamPathTemplate": "/api{catchall}",
    "DownstreamHostAndPorts": [
            {
                "Host": "my-order-webapi-service",
                "Port": 8080,
            }
        ],
    "UpstreamPathTemplate": "/order{catchall}",
    "UpstreamHttpMethod": [ "Get", "Post", "Put", "Delete" ]
}
{
    // for order1
    "DownstreamPathTemplate": "/api{catchall}",
    "DownstreamHostAndPorts": [
            {
                "Host": "my-order1-webapi-service",
                "Port": 8080,
            }
        ],
    "UpstreamPathTemplate": "/order{catchall}",
    "UpstreamHttpMethod": [ "Get", "Post", "Put", "Delete" ]
    "RouteClaimsRequirement": {
        "sourceIp": "ip1|ip2"
    }
},
{
    // for order2
    "DownstreamPathTemplate": "/api{catchall}",
    "DownstreamHostAndPorts": [
            {
                "Host": "my-order2-webapi-service",
                "Port": 8080,
            }
        ],
    "UpstreamPathTemplate": "/order{catchall}",
    "UpstreamHttpMethod": [ "Get", "Post", "Put", "Delete" ]
    "RouteClaimsRequirement": {
        "sourceIp": "ip3|ip4"
    }
}

Specifications

• Version: v17.0.0
• Platform: Linux
• Subsystem: .net5.0

[raman-m]

@NullRefer Paddi,
Thanks for your question!

But ocelot starts with exception that /order{catchall} has duplicate.

You have to provide full call stack of the exception from debug session. Or, at least full text of the error message!
But is it better to share call stack from Visual Studio during debugging.

[raman-m]

I ask for ChatGPT, it give me an configuration of below. But ocelot starts with exception that /order{catchall} has duplicate.

Aha-hah! LoL! Young people asks ChatGPT how to live, and how to work... That's really funny! 🤣

@ggnaegi FYI To have a fun... 😉

[raman-m]

If ip1, ip2 request for GET /order/1, it goes to my-order1-webapi-service;
If ip3, ip4 request for GET /order/1, it goes to my-order2-webapi-service;
And the other requests go to my-order-webapi-service.

@NullRefer
It is impossible to do by current Ocelot features, as far as I know... This requirements look like a Service Discovery functionality... right,
@ggnaegi ?

Based on IP address you want to route traffic to different hosts... Also some mix of Ocelot Routing feature (path template placeholders), but I believe placeholders must work with Service Discovery feature.

So, I see 2 possible solutions:

1. Find service discovery product which provides features in your requirements, I mean discovery based on client IP addresses. I have no idea if Consul, Eureka provide such functionality. If Yes just use Service Discovery Ocelot feature and write correct configurations.
2. Design, develop your own Service Discovery Custom Provider and attach to Ocelot pipeline adding to DI. You can find instructions in docs, see this link.

If you will find some interesting and popular Service Discovery product, we can integrate it to Ocelot as separate service discovery provider. So, we are open to your PRs/issues.

[raman-m]

@NullRefer

How could I change my configuration to solve it?

You cannot change it! This config being generated by ChatGPT is absolutely incorrect!
So, ChatGPT is a lier! 😠 You see?...

---

"RouteClaimsRequirement": {
  "sourceIp": "ip1|ip2"
}

The RouteClaimsRequirement property of route configuration is used for Authorization feature only!
sourceIp is a claim of auth-token, and ip1|ip2 is a value of this claim.
Do you see?

---

Finally,
I suggest you to focus on possible solutions, see above. And have some coding challenge.
Have I answered on your question, Paddi?

[ggnaegi]

@NullRefer Hello Paddi, I'm not sure I understand what you're trying to achieve. Do both services offer the same functionalities?

If so, using Load Balancing with consul is a good strategy, but you will need a consul instance and to register your services to consul.
https://github.com/ggnaegi/SwizlyPeasy.Gateway/blob/master/SwizlyPeasy.Consul/ServiceRegistration/ServiceDiscoveryHostedService.cs

        var consulClient = CreateConsulClient(serviceDiscoveryConfig);
        services.AddSingleton<IConsulClient, ConsulClient>(p => consulClient);
...
    private static ConsulClient CreateConsulClient(ServiceDiscoveryConfig serviceConfig)
    {
        return new ConsulClient(config => { config.Address = serviceConfig.ServiceDiscoveryAddress; });
    }
...
       var registrationId = $"{_config.Value.ServiceName}-{_config.Value.ServiceId}";

        var registration = new AgentServiceRegistration
        {
            ID = registrationId,
            Name = _config.Value.ServiceName,
            Address = _config.Value.ServiceAddress.Host,
            Port = _config.Value.ServiceAddress.Port,
            Check = new AgentCheckRegistration
            {
                HTTP =
                    $"{_config.Value.ServiceAddress.Scheme}://{_config.Value.ServiceAddress.Host}:{_config.Value.ServiceAddress.Port}/{_config.Value.HealthCheckPath}",
                Interval = TimeSpan.FromSeconds(10)
            }
        };

        await _client.Agent.ServiceRegister(registration, cancellationToken);

Then you need to implement your own Load Balancer using the ILoadBalancer and ILoadBalancerCreator interfaces. In your implementation, there's a method called Lease whose parameter is the HttpContext and the list of available services as a local variable. Using HttpContext.Connection.RemoteIpAddress?.ToString(), you can obtain the source IP, and then depending on the IP, return the appropriate service.

public class CustomLoadBalancer : ILoadBalancer
    {
        private readonly Func<Task<List<Service>>> _services;

        public CustomLoadBalancer(Func<Task<List<Service>>> services)
        {
            _services = services ?? throw new ArgumentNullException(nameof(services));
        }

        public async Task<Response<ServiceHostAndPort>> Lease(HttpContext httpContext)
        {
            var services = await _services();

            if (services == null || services.Count == 0)
            {
                return new ErrorResponse<ServiceHostAndPort>(new ServicesAreEmptyError("There were no services in CustomLoadBalancer"));
            }

            var service = services.First(x => x.Id == "my-order2-webapi-service");
            if (httpContext.Connection.RemoteIpAddress?.ToString() != "192.168.1.20")
            {
                return new OkResponse<ServiceHostAndPort>(service.HostAndPort);
            }

            service = services.First(x => x.Id == "my-order1-webapi-service");
            return new OkResponse<ServiceHostAndPort>(service.HostAndPort);
        }

        public void Release(ServiceHostAndPort hostAndPort)
        {
            throw new NotImplementedException();
        }
    }

As for the LoadBalancerCreator:

using Ocelot.Configuration;
using Ocelot.Responses;
using Ocelot.ServiceDiscovery.Providers;

namespace Ocelot.LoadBalancer.LoadBalancers;

public class CustomLoadBalancerCreator : ILoadBalancerCreator
{
    public string Type => nameof(CustomLoadBalancer);

    public Response<ILoadBalancer> Create(DownstreamRoute route, IServiceDiscoveryProvider serviceProvider)
    {
        return new OkResponse<ILoadBalancer>(new CustomLoadBalancer(async () => await serviceProvider.GetAsync()));
    }
}

I reckon, you could even just return two services in CustomLoadBalancerCreator instead of calling serviceProvider.GetAsync... and you could avoid using consul or another service discovery... I'm not sure though.
Don't forget to add your custom Load Balancer Creator in program.cs as a singleton.

Services.AddSingleton<ILoadBalancerCreator, CustomLoadBalancerCreator>();

If the features aren't the same, then I don't understand why you want to use the same route... 😸

[raman-m]

I'm a robo-student. 🤖 I ask ChatGPT! I believe in ChatGPT! 🤣

@ggnaegi Your solution is awesome!
It could be a very solid solution if the author would like to setup service discovery for a long term.
But if the author would like to get quick results, (s)he can just develop Custom Provider and attach it to Ocelot pipeline, and that's it! So, this is short-term solution.

[NullRefer]

Thanks for your answers. It's so good of you to provide solutions.

I'm sorry that I did not provide enough information for this question.

Actually, we are dividing(or copying) our order service into two, and the database will be divided in the future release. The client ip is the only way which distinguishes. Since we are not familiar with Ocelot, Emm, so I use ChatGPT and it tells a lie obviously...

Unfortunately, there was a Consul in our architecture but was removed in previous version. So I thought it would be great if it can be solved by just changing the configurations...

It seems that I can not achieve this by adjusting Ocelot in such situation. But we have the nginx, all the client's requests are firstly handling by nginx. So we will turn to nginx to solve this.

Thank for your replies. I'll continue learning Ocelot and won't be misled by GPT.🫡

[raman-m]

Paddi,

It seems that I can not achieve this by adjusting Ocelot in such situation. But we have the nginx, all the client's requests are firstly handling by nginx. So we will turn to nginx to solve this.

If you have not find any suitable Service Discovery product, and your team doesn't want to use Consul anymore, then I see only one possible solution with Ocelot, and it is Custom Providers, as I've already shared to you.

I'm not an expert in nginx tools, but it is pretty easy to implement what you need (client's IP-based routes) with Custom Providers, and even without nginx at all.
Don't be lazy! Write some code for your own custom provider, and embed your module to Ocelot pipeline. You can keep mappings of client's IPs and downstream service names just in simple text file with parsing to memory during Ocelot startup, and you'll get dynamic routing based on client's IPs.

Also, Custom Load Balancer solution by @ggnaegi is ready solution. You need just remove IP hardcoding by moving mappings to a file. And seems some decoupling from Consul is required.

Finally, I would say that custom providers idea and your user case can be converted to a real useful feature of custom service discovery provider.

P.S. Please mark a message in the thread as answer, if you've got final answer.