New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support multiple VIRTUAL_PORT alongside VIRTUAL_HOST #59

Open
byrnedo opened this Issue Dec 3, 2014 · 77 comments

Comments

Projects
None yet
@byrnedo

byrnedo commented Dec 3, 2014

Maybe this is being addressed in some of the other open issues or perhaps I missed something when trying this but would be great if a virtual host was mapped to the corresponding port in a list of virtual ports.

I.e.
-e VIRTUAL_HOST=one.dev,two.dev -e VIRTUAL_PORT=80,81

would get the proxy to send traffic for one.dev to port 80, two.dev to port 81.

Maybe better if I just hack on the template?

@jwilder

This comment has been minimized.

Owner

jwilder commented Dec 3, 2014

I think using a custom template would be better for that case TBH.

@byrnedo

This comment has been minimized.

byrnedo commented Dec 3, 2014

Well I got it to work after some fiddling. Custom template will do fine for me. If you feel like using the change I made a pull request. #60 : removed VIRTUAL_PORT, now specify port via -e VIRTUAL_HOST=foo.bar:80
Keeps old behavior if no colon.

@marmotz

This comment has been minimized.

marmotz commented Apr 5, 2015

+1

@gabeos

This comment has been minimized.

gabeos commented Apr 16, 2015

Would actually be nice to have a feature in the template for allowing the use of $server_port in the upstream configuration.

Something like VIRTUAL_PORT="all"
or in this model, VIRTUAL_HOST=foo.bar:*

Would be super useful for webapps (like seafile, or others that offer WebDAV), and in general anything that is required to expose multiple ports on the same hostname, e.g. Drupal+Etherpad-lite, etc.

@jmls

This comment has been minimized.

jmls commented May 8, 2015

how far did you get with this ? We need to expose 2 ports on the container, and have two different virtual hosts. For example a.foo.bar.com->80:80 and b.foo.bar.com->80:9090

@byrnedo

This comment has been minimized.

byrnedo commented May 8, 2015

@jmls I didn't have much in the line of go skills at the time. I could probably revisit it to finish this if I get time.

As an alternative (though it was a breaking change so wouldn't be merged ) I catered for -e VIRTUAL_HOST=foo.bar.com:8080 ...
Here's the fork https://github.com/byrnedo/nginx-proxy
Check the readme there.

Works fine for us for exposing nonstandard ports via the proxy.

As far as I rember ( been a while since I played with this ), your case would be

-e VIRTUAL_HOST=a.foo.bar.com:80,b.foo.bar.com:9090 
@jmls

This comment has been minimized.

jmls commented May 8, 2015

thanks for the link - I see that there are several (!) commits from the origin that haven't been merged in - is there a reason for this ?

@byrnedo

This comment has been minimized.

byrnedo commented May 8, 2015

Yeah, I just haven't updated it. Do you need this asap?

On 2015-05-08 13:07, jmls wrote:

thanks for the link - I see that there are several (!) commits from
the origin that haven't been merged in - is there a reason for this ?


Reply to this email directly or view it on GitHub
#59 (comment).

@jmls

This comment has been minimized.

jmls commented May 8, 2015

I do .. thanks !

@byrnedo

This comment has been minimized.

byrnedo commented May 8, 2015

I'll have a look, might be that too much has changed but we'll see, I'll
have a go at rebasing.

On 2015-05-08 13:13, jmls wrote:

I do .. thanks !


Reply to this email directly or view it on GitHub
#59 (comment).

@jmls

This comment has been minimized.

jmls commented May 8, 2015

thanks so much. really appreciate it.

@byrnedo

This comment has been minimized.

byrnedo commented May 8, 2015

Check it out now, should work. And no problem, actively using it here so I needed this too!

@jmls

This comment has been minimized.

jmls commented May 8, 2015

awesome! thanks!

@asthomasdk

This comment has been minimized.

asthomasdk commented May 8, 2015

I did a test build of this in a docker container - and tried it out. Something is wrong though, as the proxying is not working at all now.

I have tried starting a docker container using something like this:
-e VIRTUAL_HOST=dev.foor.bar
-e VIRTUAL_PORT=8181

and
-e VIRTUAL_HOST=dev.foor.bar:8181

and also
-e VIRTUAL_HOST=dev.foor.bar:8181,preview-dev.foo.bar:3000

None of these work. All I get is the nginx welcome page.

The ports mentioned above are the ports the services inside the container are running. The container is being started with :
-p 8181 -p 3000

@byrnedo

This comment has been minimized.

byrnedo commented May 8, 2015

I'll take a look

@asthomasdk

This comment has been minimized.

asthomasdk commented May 8, 2015

Thanks!

@byrnedo

This comment has been minimized.

byrnedo commented May 8, 2015

whats your full 'run' command?

@byrnedo

This comment has been minimized.

byrnedo commented May 8, 2015

This seems to be working for me:

docker build -t byrnedos_nginx_proxy_fork .

docker run --rm -it -p 80:80 -v /var/run/docker.sock:/tmp/docker.sock byrnedos_nginx_proxy_fork

docker run --rm -it -p "8080:8080" -p "9090:9090" -e VIRTUAL_HOST="test.local:8080,test2.local:8090" <some web app which runs on 8080 and 8090>

@byrnedo

This comment has been minimized.

byrnedo commented May 8, 2015

can you check the output in the nginx_proxy log ( docker logs -f <container_id/name> ) when you make a request to the virtual host?

@asthomasdk

This comment has been minimized.

asthomasdk commented May 8, 2015

I'll check.

I can see you have things in quotes in your last run statement :
docker run --rm -it -p "8080:8080" -p "9090:9090" -e VIRTUAL_HOST="test.local:8080,test2.local:8090"

Is that a requirement? Usually isn't.

@byrnedo

This comment has been minimized.

byrnedo commented May 8, 2015

no, shouldn't be, copy-pasta just. Is the web service in the docker
container binding to 0.0.0.0 and not just 127.0.0.1?

On 2015-05-08 21:16, Thomas Hansen wrote:

I'll check.

I can see you have things in quotes in your last run statement :
docker run --rm -it -p "8080:8080" -p "9090:9090" -e
VIRTUAL_HOST="test.local:8080,test2.local:8090"

Is that a requirement? Usually isn't.


Reply to this email directly or view it on GitHub
#59 (comment).

@asthomasdk

This comment has been minimized.

asthomasdk commented May 8, 2015

it is binding to 0.0.0.0

@byrnedo

This comment has been minimized.

byrnedo commented May 8, 2015

Also try, with the virtual host containers running:

docker exec -it <proxy container id/name> cat /etc/nginx/conf.d/default.conf

That will show the generated template that the proxy is using.

@md5

This comment has been minimized.

Contributor

md5 commented May 8, 2015

@byrnedo Any chance you'd want to rework that branch to be backwards compatible and still support VIRTUAL_PORT in addition to the colon syntax?

I can't speak for @jwilder and I don't want to endorse running multiple HTTP services in a single container, but it's clearly something that people are doing that can't be supported by jwilder/nginx-proxy as it now stands.

@byrnedo

This comment has been minimized.

byrnedo commented May 8, 2015

I can give it a go yeah, I have a bit more of a clue about go now so maybe it'd be quick..

@md5

This comment has been minimized.

Contributor

md5 commented May 8, 2015

👍

Also, it looks like if you want to make #60 mergeable, you're going to want to rebase out the merge commits at some point. Perhaps wait for some positive encouragement from @jwilder before doing that, though.

@byrnedo

This comment has been minimized.

byrnedo commented May 8, 2015

A bad habit I picked up.

On 2015-05-08 22:00, Mike Dillon wrote:

👍

Also, it looks like if you want to make #60
#60 mergeable, you're
going to want to rebase out the merge commits at some point. Perhaps
wait for some positive encouragement from @jwilder
https://github.com/jwilder before doing that, though.


Reply to this email directly or view it on GitHub
#59 (comment).

@md5

This comment has been minimized.

Contributor

md5 commented May 8, 2015

No worries. If you end up needing any enhancements to docker-gen or need to ask any questions, I'm happy to help.

@byrnedo

This comment has been minimized.

byrnedo commented May 8, 2015

Thanks, will let you know.

On 2015-05-08 22:04, Mike Dillon wrote:

No worries. If you end up needing any enhancement to |docker-gen| or
need to ask any question, I'm happy to help.


Reply to this email directly or view it on GitHub
#59 (comment).

@asthomasdk

This comment has been minimized.

asthomasdk commented May 8, 2015

Here's a snippet of the output from default.conf:

...
upstream dev.foobar.com {
# dev.foobar.com
server 172.17.0.89:8181;
}
server {
server_name dev.foobar.com;
location / {
proxy_pass http://dev.foobar.com;
}
}
...

Looks fine as far as I can tell.

@mikesir87

This comment has been minimized.

mikesir87 commented Jul 27, 2016

I have the same use case, but with Gitlab. A single container is exposing one port for the Git web interface and another port for the container registry.

I'm more than happy to help contribute code, but seeing the discussions, it's a little unclear what direction should be used. Any input @jwilder ?

@s17t

This comment has been minimized.

s17t commented Jul 27, 2016

We started to use docker-gen and custom template script loosy inspired by nginx-proxy. Probably the user cases are just too much for a once-fit-all solution.

@jgangemi

This comment has been minimized.

jgangemi commented Jul 28, 2016

@s17t would you mind sharing your template and the steps used to achieve this? i'd be ok w/ using that approach, i'm just not entirely sure on how to get started.

@jgangemi

This comment has been minimized.

jgangemi commented Aug 18, 2016

is there any movement on this? the issue seems to be languishing and i can't proxy the docker functionality of sonatype's nexus 3 w/o this.

@wader

This comment has been minimized.

wader commented Aug 18, 2016

@jgangemi don't think anyone is actively working on it. If you really eager i guess you could try to get the changes in #254 onto master and try

@jgangemi

This comment has been minimized.

jgangemi commented Aug 18, 2016

i'm not sure #254 will solve my problem as i want to point two different hostnames (nexus.example.com and registry.example.com) to a single docker container and have them be handled by different ports (8081 and 5000).

what about the template solution? could someone explain how that works or point to a solid example? i'd be ok w/ that as a solution.

@wader

This comment has been minimized.

wader commented Aug 18, 2016

@jgangemi ah sorry, i assumed this issue was about paths :)

@jgangemi

This comment has been minimized.

jgangemi commented Aug 31, 2016

bueller?

is there any movement on this issue?

@TheBlusky

This comment has been minimized.

TheBlusky commented Aug 31, 2016

It does not seem that this issue is important for maintainers ...

However, there is clearly many use cases for it (nexus with repository / registry, seafile with frontend / backend, gitlab with frontend / regsitry, ...)

@jgangemi

This comment has been minimized.

jgangemi commented Aug 31, 2016

yeah - that's very, very unfortunate.

paging @s17t again in the hope he might respond with some information about his custom template.

@s17t

This comment has been minimized.

s17t commented Sep 1, 2016

Hi guys,
the point is to bypass nginx-proxy and learn to use docker-gen and Go template. You can start from here [0]. We have something like this as template:

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" "," }}
{{/*
Original docker-gen nginx template [0] has the upstream section generation. In this
project is worthless as it would end to have one upstream entry per host/proxypass
combination.

Must be handled if one or more proxypass has to be balanced.

[0] https://raw.githubusercontent.com/jwilder/docker-gen/master/templates/nginx.tmpl
*/}}

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 $s, $p := where $containers "Env.VIRTUAL_HOST" $host}}
                location /{{ $p.Env.VIRTUAL_HOST_PATH }} {

                {{ $addrLen := len $p.Addresses }}
                {{ $network := index $p.Networks 0 }}

                {{/* If only 1 port exposed, use that */}}
                {{ if eq $addrLen 1 }}
                        {{ with $address := index $p.Addresses 0 }}
                                proxy_pass http://{{ trim $address.IP }}:{{ $address.Port }}/{{ $p.Env.VIRTUAL_HOST_PATH }};
                        {{ end }}

                {{/* If more than one port exposed, use the one matching VIRTUAL_PORT env var */}}
                {{ else if $p.Env.VIRTUAL_PORT }}
                        {{ range $i, $address := $p.Addresses }}
                                {{ if eq $address.Port $p.Env.VIRTUAL_PORT }}
                                        proxy_pass http://{{ trim $address.IP  }}:{{ $address.Port }}/{{ $p.Env.VIRTUAL_HOST_PATH }};
                                {{ end }}
                        {{ end }}

                {{/* Else default to standard web port 80 */}}
                {{ else }}
                        {{ range $i, $address := $p.Addresses }}
                                {{ if eq $address.Port "80" }}
                                        proxy_pass http://{{ trim $address.IP }}:{{ $address.Port }}/{{ $p.Env.VIRTUAL_HOST_PATH }};
                                {{ end }}
                        {{ end }}
                {{ end }}

                        proxy_set_header Host $http_host;
                        proxy_set_header X-Real-IP $remote_addr;
                        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                        proxy_set_header X-Forwarded-Proto $scheme;

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

Then you will run docker-gen and a dockerized nginx:

$ docker run -d  --name nginx-gen --volumes-from nginx -v /var/run/docker.sock:/tmp/docker.sock:ro     -v /home/ibex/tmp/docker-gen/templates:/etc/docker-gen/templates -v /home/ibex/tmp/nginx:/etc/nginx/conf.d -t jwilder/docker-gen -notify-sighup nginx -watch /etc/docker-gen/templates/nginx.tmpl /etc/nginx/conf.d/default.conf

$ docker run -d -p 80:80 --name nginx -v /home/ibex/tmp/nginx:/etc/nginx/conf.d -t nginx

From now on each time you will run a container with VIRTUAL_HOST, VIRTUAL_PORT and VIRTUAL_HOST_PATH environment variables docker-gen will generate new vhost and reload nginx:

$ docker run --env VIRTUAL_HOST=app.com --env VIRTUAL_PORT=9292 --env VIRTUAL_HOST_PATH=/

$ docker run --env VIRTUAL_HOST=app.com --env VIRTUAL_PORT=8080 --env VIRTUAL_HOST_PATH=/

[0] https://github.com/jwilder/docker-gen/blob/master/templates/nginx.tmpl

@dbendelman

This comment has been minimized.

dbendelman commented Jan 11, 2017

B"H

I ran into this issue and tried the byrnedo fork, but found that it no longer builds and is quite behind this upstream atm. Seeing as @byrnedo said he no longer uses this himself, I forked byrnedo/nginx-proxy, merged in upstream and fixed the conflicts. We use this as a hub for serving per-branch staging sites, and so far it's been working perfectly for a few days under heavy use.

For anyone coming to this issue now and wants a quick solution, feel free to use this and let me know if you find issues.

@ronaldtse

This comment has been minimized.

ronaldtse commented Jan 13, 2017

+1 Is it possible to get this merged? It would save many people hours of labor :-) Thanks!

julianxhokaxhiu added a commit to julianxhokaxhiu/vps-powered-by-docker that referenced this issue Feb 14, 2017

Support multiple VIRTUAL_PORT alongside VIRTUAL_HOST
See jwilder/nginx-proxy#59

Final solution: VIRTUAL_HOST="example.com:8080,example.org:8081"

julianxhokaxhiu added a commit to julianxhokaxhiu/rpi-powered-by-docker that referenced this issue Feb 14, 2017

Support multiple VIRTUAL_PORT alongside VIRTUAL_HOST
See jwilder/nginx-proxy#59

Final solution: VIRTUAL_HOST="example.com:8080,example.org:8081"
@Laykou

This comment has been minimized.

Laykou commented Aug 1, 2017

👍 Please get this merged.

@ebuildy

This comment has been minimized.

ebuildy commented Feb 6, 2018

Hello guys, if you really want multiple backend with a single container, what about using socat (as a simple proxy)?

I have post this solution: https://gist.github.com/ebuildy/c20fd9124730b535dddffa7b9e6946ca

@luisnabais

This comment has been minimized.

luisnabais commented Feb 28, 2018

I would really like this feature. I'm searching for alternatives at the moment... Thanks

EDIT: Can this be done, in the meanwhile, manually, using the vhost configuration?

Alexander-Krause pushed a commit to Alexander-Krause/rpi-docker-nginx-proxy that referenced this issue Mar 30, 2018

Merge pull request jwilder#59 from MrsKensington/patch-1
break in location in case the upstream is protected
@nodriza-io

This comment has been minimized.

nodriza-io commented May 4, 2018

Hello guys, can someone tell me if the @dbendelman solution works?
https://hub.docker.com/r/dbendelman/nginx-proxy/

I'm trying to make the multi port per container working by adding this:
-e VIRTUAL_HOST=foo.myapp.io:80,foo.nodriza.io:443,foo.myapp.io:3000

But is not working, what can be wrong?

@dbendelman

This comment has been minimized.

dbendelman commented May 6, 2018

@nodriza-io check that your container is actually exposing those ports and that they can be reached with curl from inside the nginx-proxy container. If that works fine, inspect the nginx.conf that was generated inside the nginx-proxy container for any issues.

@kevrat

This comment has been minimized.

kevrat commented Jun 26, 2018

+1

@frederikbosch

This comment has been minimized.

frederikbosch commented Jul 30, 2018

See PR #1157. Hopefully we can convince @jwilder To merge this in, cq. help to merge it in.

@lost-carrier

This comment has been minimized.

lost-carrier commented Aug 9, 2018

+1

1 similar comment
@codemaker219

This comment has been minimized.

codemaker219 commented Aug 13, 2018

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment