VIRTUAL_HOST syntax to support multiple destinations

[ammmze]

This request adds some additional functionality to handling the VIRTUAL_HOST environment variable. So in addition to the default functionality (ie VIRUTAL_HOST=www.example.com) you can also do something like this:

- VIRTUAL_HOST=admin.example.com=>https:8444,www.example.com=>http:8080,other.example.com
- VIRTUAL_PORT=8443
- VIRTUAL_PROTO=https

What this ultimately becomes is 3 upstream configurations (admin.example.com, www.example.com, and other.example.com).

• The admin.example.com upstream would route to https://:8444
• The www.example.com upstream would route to http://:8080
• The other.example.com upstream would route to https://:8443
  • It will default to using todays logic if the protocol and port are not specified in the VIRTUAL_HOST syntax

This is useful for scenarios where you have an application that runs multiple interfaces on different ports. (my current use case is the WSO2 API Manager product, which has an admin interface on one port and client endpoints are on a different port). While in production we would probably run a separate instance for the admin (the other part would still be running idle) and a separate instance for the api endpoints and these would be scaled depending on the load. However, in dev environments, we only want the one container and running separate instances is kind of costly given that the WSO2 products each take about 500MB ram to run idle.

[benjamin-smith]

Would be useful for me. Google AppEngine SDK dev server exposes 2 ports (8080 and 8000). Would love to be able to have 2 upstreams so they can be routed from this Nginx proxy. Right now I can only expose one or the other.

[thomasschmit]

@jwilder, what's missing to merge this pull request? It'd be very useful!

[TheBlusky]

Any update on this issue ?
Is it solved ?

[md5]

@TheBlusky No, it is not solved.

[c3s4r]

I'm also needing this feature. @jwilder what's missing for this feature to be integrated? I just took a look on the commits by @bcash-parchment and they look good. What would be the complications? How can I help?

[pascalandy]

+1

I'm looking to execute this scenario as well:

• mydomain.com (via a container using a basic nginx svr for static-file (it's the landing page))
• mydomain.com/blog (via wordpress engine)
• mydomain.com/stats/ (via a container that monitors the host/static/blog)
• ... and so one for many utilities :)

Thanks in advance!
Pascal

[ammmze]

FYI...I've rebased this on to the current master branch so it is able to merged by someone with authority ;) ... @jwilder

[xloup]

Thanks @ammmze , I found i can launch the docker with your template using the procedure of launch in separate containers described in the readme, which allows to specify a custom nginx template file

However, to avoid the need of using quotes when setting VIRTUAL_HOST env value for backward compatibility, I changed the separator to "__" from "=>" according to the allowed chars in env variable from this stackoverflow Q/R here
http://stackoverflow.com/questions/2821043/allowed-characters-in-linux-environment-variable-names

[ncadou]

You might be interested to know there's a docker image containing this PR: ncadou/nginx-proxy.

Not guaranteed to be kept up to date though.

[ashleysommer]

@xloup, It looks to me like that rule only applies to Environment Variable Names, not values.
I would say it makes sense to have the variable value wrapped in quotes anyway, so that you can put any string character in there.

[xloup]

@ashleysommer yes you're right, but for info, at least on my config it breaks backwards compatibility in the sense that if quotes were not obligatory in the past, now they will be. and if this pull request is merged, readme needs to be updated with a note that quotes are obligatory in virtualhost="domain.name" syntax

[ammmze]

The quotes should only be required if you use the advanced syntax. You can still use the old syntax without quotes

[Laykou]

Can we have this feature please? @jwilder In my case I would like to use this for gitlab-ce docker image where there is GitLab service and Registry both in one docker image but as separate services with separate internal port and externa url domain. This would really help to setup:

VIRTUAL_HOST=gitlab.domain.com=>https:80,registry.domain.com=>https:5000

Or something similiar. I've seen many approaches here. This feature is really wanted 👍

[qnorsten]

Just wanted to say thank you so much for this PR.
Was looking for this functionality and manually adding it into my custom nginx.tmpl solved the trick.
I wonder why this is not already merged (as I see nothing wrong with it)

[nathanhoel]

I forked the repo and merged this PR and changed the syntax to '__' instead of '=>' so that it was legal in all env vars.
available on docker hub here https://hub.docker.com/r/nathanhoel/nginx-proxy/
You can see my fork for the source

I was hoping someone had done this... now you don't have to go looking for it like I did!

No guarantees it will stay updated, but if anyone submits update PRs I will merge it and update docker hub!

[anthonyraymond]

👍
Any new on this @jwilder ?

@ammmze can you resolve the conflict, just in case jwilder comes by and want to merge :)

[buchdag]

Superseded by #2434