Question about LB with a Request Path

First of all, I found out about Rancher only yesterday and since then I played with it non-stop, went through most of the blog articles and I keep discovering awesome features. Thank you so much for such a great app!

Second, I apologize in advance for what is probably a stupid question due to my lack of completely understanding networking.

So, I created a service with a simple test container, that I named topicservice. Then I added a load balancer for this service with simple settings: it listens to port 4040 and it calls my container on its internal port. I call it with <host IP>:4040 and everything works great!

Then I tried to add a request path to it, so it will only answer to <host IP>:4041/topic. I created a new LB same as the original one, with Source Port = 4041. In the Advanced routing options I left the Request host empty, same with Source Port (thinking it will use the Source Port from the main definition), added /topic in the Request Path, selected the target service to be my topic service and its internal port in the Target Port. Saved, started it and tried the same <host IP>:4041/topic and I get 404. If I try <host IP>:4041 with no path I get no service is available (which is what I expected).

My main goal is to have several services on the same LB (same as Alena showed in a blog post I’ve read - thanks for all your posts, Alena, they are great!) and make them answer to different paths. But I am not able to do so even with one service. Alena’s post showed how to do this but using 2 different public URLs, chat.example.com and web.example.com but all I really want is to be able to call my services internally based on the path, not exposed as separate websites.

Can you please help me understand what I’m doing wrong and how to achieve what I want?

Thanks a lot for all you do and for any help I can get!

The HTTP request is not modified by the routing, so a request to http://<host IP>:4041/topic becomes a request to http://<container 10.42.x.y>:<target port>/topic. Your service/container probably doesn’t have a /topic, so it responds 404.

There are options that can make haproxy rewrite the request path to not include the matched prefix that you could set once #1871 is implemented. Rewriting is not enabled by default because it will not work for many applications… anything that responds with root-relative (<img src="/images/blah.jpg"/>) or absolute URLs (<a href="http://<host header>/things/stuff) will not include the prefix and will therefore be broken. These are both pretty common, but may not occur in your specific application. Some applications have config options to tell it what root path it should be served under that you could set to /topic.

But basically this is why people often use subdomains instead of path routing :slight_smile: .

This makes a lot of sense, I will change my service code and try again.

Thanks for the fast reply!

I’m having a similar issue. Can this be resolved by customizing the haproxy config? If so, can someone give me an example of what to add to the configs?

To be clear, I have path based routing for individual microservices and my services are returning 404 since the path is not included in the microservice path. I would like to do the following at the proxy layer.
/dfs/ -> /
/vms/ -> /

I found articles for how to structure the “reqrep” method of haproxy…
reqrep ^([^\ :])\ /dfs/(.) \1\ /\2
reqrep ^([^\ :])\ /vms/(.) \1\ /\2

But when I add this to the configs, the service fails to initialize.

I’m I missing something?

reqrep can only go in frontend, listen, and backend, you are putting them in defaults or global so they are invalid.

Customizing those will be possible in 1.2 #2179.