Another template for VIRTUAL_PATHs instead of VIRTUAL_HOSTs

[andrefernandes]

What about offering other templates for different needs?

I am using the template below to generate several "location" entries for each server. This results on a single domain with a context root for each container (more like port redirection). Serves me well for my single-server Digital Ocean droplet.

You can have several templates available in this project, it is just a matter of mounting the chosen template into "/app/nginx.tmpl" when running the proxy.

---

server {
    listen 80 default_server;
    server_name _; # This is just an invalid value which will never trigger on a real hostname.
    error_log /proc/self/fd/2;
    access_log /proc/self/fd/1;
    return 503;
}

{{ range $host, $containers := groupByMulti $ "Env.VIRTUAL_HOST" "," }}

server {
    gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

    server_name {{ $host }};
    proxy_buffering off;
    error_log /proc/self/fd/2;
    access_log /proc/self/fd/1;

{{ range $index, $value := $containers }}
{{ $location := $value.Env.VIRTUAL_PATH }}
{{ $address := index $value.Addresses 0 }}
# {{$location}}

    location /{{$location}} {
            proxy_pass http://{{ $address.IP }}:{{ $address.Port }};
            include /etc/nginx/proxy_params;

            # HTTP 1.1 support
            proxy_http_version 1.1;
            proxy_set_header Connection "";
    }
{{ end }}

}

{{ end }}

[thaJeztah]

@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.

[andrefernandes]

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

[jwilder]

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

[andrefernandes]

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:notifications@github.com]
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.

[hbredin]

+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.

[trinitronx]

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.

[md5]

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=/.

[PavelVanecek]

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

[md5]

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.

[lonix]

I Would love this feature.

[md5]

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.

[md5]

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.

[md5]

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.

[andrefernandes]

Sure!

De: Mike Dillon [mailto:notifications@github.com]
Enviada em: sexta-feira, 9 de outubro de 2015 00:50
Para: jwilder/nginx-proxy nginx-proxy@noreply.github.com
Cc: Andre de Oliveira Fernandes andre.oliveira@bcb.gov.br
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.

[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.