Another template for VIRTUAL_PATHs instead of VIRTUAL_HOSTs about nginx-proxy HOT 15 CLOSED

@andrefernandes could you re-format your example, because it's quite hard to read right now. You can either indent the whole block with 4 spaces or put three back-ticks before and after the example.

from nginx-proxy.

Sorry for that, it was like 2 AM... Fixed.

from nginx-proxy.

Can you elaborate on why just VIRTUAL_HOSTs does not work? Each container can have multiple virtual hosts defined as well.

from nginx-proxy.

Not much of a big deal.

The DNS guys around here cannot create new DNS entries on an acceptable timeframe, while paths are under my control.

Actually I prefer VIRTUAL_HOSTs too.

De: Jason Wilder [mailto:[email protected]]
Enviada em: sexta-feira, 19 de setembro de 2014 14:04
Para: jwilder/nginx-proxy
Cc: Andre de Oliveira Fernandes
Assunto: Re: [nginx-proxy] Another template for VIRTUAL_PATHs instead of VIRTUAL_HOSTs (#33)

Can you elaborate on why just VIRTUAL_HOSTs does not work? Each container can have multiple virtual hosts defined as well.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/33#issuecomment-56205256.

from nginx-proxy.

+1 for this kind of functionality.

BTW @andrefernandes, in current state of the nginx.tmpl template, not providing a VIRTUAL_PATH would result in the following line

location /<no value>

while (I think) it should be

location /

An even more user-friendly template could allow something like

docker run -e VIRTUAL_URL=www.example.com/path ...

and automatically derive VIRTUAL_HOST and VIRTUAL_PATH from this VIRTUAL_URL variable.
If that is of interest, I am willing to help though I am not sure I understand how the whole thing works.

from nginx-proxy.

For anyone running this in front of a docker registry container...

Now that the docker registry v2.0 is out, and they've pretty much done away with /v1/ API backwards compatibility, this feature / use case is definitely needed ;-)

They're currently recommending to run a v1 and v2 registry in parallel with an nginx proxy in front. Their nginx config just passes the requests for /v1/ and /v2/ to the different backend containers.

from nginx-proxy.

Getting this working for the /v1 v. /v2 case is pretty easy and already works in [https://github.com/jwilder/nginx-proxy/compare/master...appropriate:multiple-paths](my multiple-paths branch). Getting it working in such a way that it's mergeable in the general case is quite a bit harder. The underlying docker-gen utility would have to include a sort* command that could do a reverse sort by longest path segments. There would also have to be a provision for providing a sane (and secure) response for / if no backing container provided a VIRTUAL_PATH=/.

from nginx-proxy.

Because of reasons, github points md5's link above to incorrect address. The actual link is: master...appropriate:multiple-paths

from nginx-proxy.

I just took a look at the Nginx docs and found that location matches don't actually happen in the order they're defined. Nginx already does a "longest prefix" algorithm:

To find location matching a given request, nginx first checks locations defined using the prefix strings (prefix locations). Among them, the location with the longest matching prefix is selected and remembered. Then regular expressions are checked, in the order of their appearance in the configuration file. The search of regular expressions terminates on the first match, and the corresponding configuration is used. If no match with a regular expression is found then the configuration of the prefix location remembered earlier is used.

So I think the only thing that actually needs to be fixed to make my multiple-paths branch usable is to make sure that a 503 error is returned for / when no location matches it.

from nginx-proxy.

I Would love this feature.

from nginx-proxy.

I just took a look at getting my master...appropriate:multiple-paths branch back in shape and it's turning out to be quite painful...

There have been quite a few changes in nginx.tmpl since I last updated the branch and the logic in the template is getting more and more complicated. It will only get more complicated if I add this or if some of the open feature requests get implemented (e.g. making the HTTP to HTTPS redirect conditional).

Trying to do a direct rebase seems to be more trouble than it's worth. I think the only viable approach is to reproduce the VIRTUAL_PATH changes from scratch.

from nginx-proxy.

I guess I spoke too soon. I managed to get the branch closer to a mergeable state, though it still doesn't handle the 503 issue I mentioned in my comment from July: #33 (comment)

Before doing any more work on that branch, I'd like to see #244 merged. I think it still needs to have the additional lines fixed that are mentioned in this comment: #244 (comment)

I'd also like to see the whitespace in the file made consistent again, but that's not a huge deal.

from nginx-proxy.

I finally opened what I think is a mergeable PR for this feature over at #254

Please discuss the patch I've offered at that PR if you're interested in this feature.

from nginx-proxy.

Sure!

De: Mike Dillon [mailto:[email protected]]
Enviada em: sexta-feira, 9 de outubro de 2015 00:50
Para: jwilder/nginx-proxy [email protected]
Cc: Andre de Oliveira Fernandes [email protected]
Assunto: Re: [nginx-proxy] Another template for VIRTUAL_PATHs instead of VIRTUAL_HOSTs (#33)

I finally opened what I think is a mergeable PR for this feature over at #254#254

Please discuss the patch I've offered at that PR if you're interested in this feature.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/33#issuecomment-146748495.

from nginx-proxy.

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.

from nginx-proxy.