Support path based routing between services about apicast HOT 11 CLOSED

You can set the server_name in the admin interface. Then just expose it via a router and it will be accessible through that route.

from apicast.

But the server_name always remain the same since they have only one domain i.e api.company.com.This is the domain where the request is sent and then depending on the URL path it is routed to correct backend.

As the domain is always same, how does correct location block and service_id is triggered?

We mainly do this by identifying the URL path by location eg: location /v1/test {} and then route it correct upstream by manually editing the nginx conf file

from apicast.

The server name should be unique. If they have more than server block with the same server_name the path based routing won't work. It will route to just one of them. If they have one domain, have just one service & one gateway. We just support domain routing. This is not a problem of this Docker Gateway.

/cc @vramosp

from apicast.

That is the point. The server_name is always same since it's one domain. The customer blindly followed our tutorial https://support.3scale.net/guides/infrastructure/docker-openshift and expects that when he routes using URL, correct backend should be invoked.

Let me explain with example:

There are 3 endpoints on 3 different backends. My wish is to access the docker gateway api.mystation.com and access all three backend endpoints.

On 3scale UI, I configure api.mystation.com as public facing URL and this is the server_name which always remain the same.

/movies --> movies.api.com
/music --> music.api.com
/location  --> location.api.com

On 3scale side we configure using 3 separate services, thus creating 3 server blocks

For above three services, 3scale generates below service_ids

movies.api.com --> 2555555
music.api.com --> 244444
location.api.com --> 233333

Whey I run the docker image and scripts, the gateway downloads the file per the format on #22 (comment)
This is wrong and it doesn't understand where to route the calls

whereas the correct format would be only one server block and depending on the URL path route the call to correct service id

http {

  upstream backend_abc {
  server movies.api.com:443 fail_timeout=30;
}

upstream backend_def {
  server music.api.com:443 fail_timeout=30;
}

upstream backend_xyz {
  server location.api.com:443 fail_timeout=30;
}

  server {
    server_name api.mystation.com;

    location /movies {
    set $service_id 2555555;
    proxy_pass https://backend_abc;
    ...
    }

    location /music {
    set $service_id 2444444;
    proxy_pass https://backend_def;
    ...
    }

    location /location {
    set $service_id 2333333;
    proxy_pass https://backend_xyz;
    ...
    }
  }
}

@vramosp I would be available to go over the scenario again. Let me know.

from apicast.

@VinayBhalerao the gateway never supported that. It always supported only host based routing (without customizations).

What we could do, is leverage the redirect_uri parameter of the mapping rule and have one meta meta service as router.

That would mean creating:

• service api.mystation.com
• service movies.api.com
• service music.api.com
• ...

And the meta service api.mystation.com would have those path mappings & redirect_url set to route to the different service.

That way the routed would still have a server block for ever service, but each would have unique server name.

We probably should show some warning, when your services don't have unique server name, because that just won't work.

from apicast.

#62 shows how to add new server with custom configuration. Feel free to contribute more complete example with routing.

from apicast.

Also there is feature to use both host and mapping rules to determine a service. #71

That would solve your issues. I can help you to test this.

from apicast.

I guess this is solved by #71?
We need to add some documentation though.

from apicast.

I'd say it is solved by #71. Someone just has to try it. I'll add a flag to the openshift template to enable that feature in #114.

from apicast.

@mikz I tried it and it worked for me. Will see if I can add a description of how it works somewhere.

from apicast.

@mikz @andrewdavidmackenzie Tested and seems to be working fine. Thank you for your help @mayorova !

from apicast.