nginx-proxy icon indicating copy to clipboard operation
nginx-proxy copied to clipboard

VIRTUAL_HOST syntax to support multiple destinations

Open ammmze opened this issue 10 years ago • 16 comments

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.

ammmze avatar Oct 12 '15 21:10 ammmze

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.

benjamin-smith avatar Nov 02 '15 14:11 benjamin-smith

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

thomasschmit avatar Nov 30 '15 15:11 thomasschmit

Any update on this issue ? Is it solved ?

TheBlusky avatar Jan 18 '16 13:01 TheBlusky

@TheBlusky No, it is not solved.

md5 avatar Jan 18 '16 15:01 md5

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?

c3s4r avatar Mar 10 '16 15:03 c3s4r

+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

pascalandy avatar Apr 14 '16 02:04 pascalandy

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

ammmze avatar Jun 01 '16 18:06 ammmze

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

xloup avatar Jun 23 '16 21:06 xloup

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.

ncadou avatar Jun 30 '16 04:06 ncadou

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

ashleysommer avatar Sep 29 '16 00:09 ashleysommer

@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

xloup avatar Oct 14 '16 18:10 xloup

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

ammmze avatar Oct 15 '16 01:10 ammmze

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 👍

Laykou avatar Aug 01 '17 18:08 Laykou

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)

qnorsten avatar Apr 17 '18 18:04 qnorsten

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!

nathanhoel avatar Apr 30 '18 22:04 nathanhoel

👍 Any new on this @jwilder ?

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

anthonyraymond avatar May 30 '18 23:05 anthonyraymond

Superseded by #2434

buchdag avatar May 09 '24 10:05 buchdag