Allow VIRTUAL_PATH to run multiple upstreams and target them appropriately

[christhomas]

This modification allows you to target a VIRTUAL_HOST multiple times in various containers, with different VIRTUAL_PATH environment variables. Letting you specify multiple containers to run under the same "domain name" with different subpaths. We use this at our company and seems to be working correctly.

[christhomas]

Any interest in merging these changes? I've got a prebuilt image on https://hub.docker.com/r/christhomas/nginx-proxy that demonstrates the solution. I hope that it works for all cases. But it works for ours and doesn't have any problems so far

[m4ci3k2]

@christhomas I've tested it and works very well for me, but I also needed a small subfeature to strip the VIRTUAL_PATH from upstream urls. I've just made a pull request on your fork for that (but if there is a better workflow for such suggestions in github please do tell me).

[jeffshpe]

Our organization does not allow subdomains. We can assign multiple hostnames to the same IP, which gets around the lack of subdomains, but it requires a ticket to be created for each hostname. Having this feature where you can use part of the URL to redirect would be great for enabling quick testing for me, I'd love to see something like this merged in to the nginx-proxy image. It would be good to have the option of stripping the additional path out, such as what m4ci3k2 has added.

[christhomas]

try out my image jeff and see if that works in the way that you want, or that we need to change something, I'm happily accepting modifications if they are good

[jeffshpe]

It looks like this might need some enhancement to handle HTTPS_METHOD and redirection. Maybe it's asking too much, but I was trying to get a site which only uses HTTPS to co-exist with a site which uses HTTP with this, which didn't quite work. I also found that some of the containers I was attempting to host serve static files without relative paths, which leads to 404s when trying to retrieve the resources, so it might be more effort than it's worth.

[jplock]

@christhomas is it possible to rebase this and have @jwilder review? this would be a great additional for a use-case I just ran into today.

[christhomas]

You can try out my docker image which is already pre-built with this functionality and then at least you can try it today

[christhomas]

@buchdag I have synchronised my fork with your changes and re-applied the ability to specify the VIRTUAL_PATH on containers, which allows for a single VIRTUAL_HOST to support multiple containers mounted at various paths instead of only allowing one container per VIRTUAL_HOST.

It's a solution that I've tried to get into the repository 2 years ago and I use everyday for my company and in my personal projects. But the original maintainer was not very responsive.

Are you interested in trying this out and letting me know how this works for you and perhaps merging it? Then I don't have to support my own custom version for this feature.

We use this feature extensively at our company because we have a single virtual host api.company.com and we host multiple microservices based off of paths on that virtual host. You can imagine REST endpoints inside that api, all being separate containers.

It's a very useful modification. What are your thoughts?

[buchdag]

@christhomas your approach is interesting, unfortunately it seems to be breaking basic multiple virtual host functionality.

Failing tests are test_unknown_virtual_host_is_503, test_webA_is_forwarded and test_webB_is_forwarded from test_multiple-hosts.py.

[buchdag]

Also, we're working toward a similar feature in #1607

[christhomas]

I’ll take a look at the tests and get back to you

…

On 16. Jun 2021, 00:59 +0200, Nicolas Duchon ***@***.***>, wrote: @christhomas your approach is interesting, unfortunately it seems to be breaking basic multiple virtual host functionality. Failing tests are test_unknown_virtual_host_is_503, test_webA_is_forwarded and test_webB_is_forwarded from test_multiple-hosts.py. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[buchdag]

This features has been added to the dev branch with #1607

It's available now on the dev images nginxproxy/nginx-proxy:dev and nginxproxy/nginx-proxy:dev-alpine. Testing and feedback are welcome, the docs for the feature is here and there is another PR opened for additional improvements and comments.