Skip to content
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

Allow virtual hosts to expose multiple ports #24

Closed
timkendrick opened this issue Sep 1, 2014 · 10 comments
Closed

Allow virtual hosts to expose multiple ports #24

timkendrick opened this issue Sep 1, 2014 · 10 comments

Comments

@timkendrick
Copy link

I'm probably doing something wrong, but I can't figure out a way to proxy multiple ports from the same container. At the moment, the nginx-proxy only seems to accept connections on port 80.

Example use case: a virtual host mapped to the www subdomain needs to handle external traffic on ports 80 and 443.

Is there any way the nginx.tmpl can be modified to allow the proxy to automatically hook up all the ports exposed by the virtual host containers? Maybe by creating multiple server definitions per container, one for each port?

@jwilder
Copy link
Collaborator

jwilder commented Sep 2, 2014

Multiple ports are not currently supported in the current template but there is no reason why you could not have the template do that though. For 443, you probably need to get SSL certs setup as well. SSL support is not implemented yet.

@cosminonnet
Copy link

Hi,

Can you please explain with more detail how I could achieve this? For example, I want to use the Docker image "sameersbn/gitlab" that exposes the ports 80 and 22 and have a "jenkins" container also. So the "nginx-proxy" should be able to redirect "gitlab.myserver.com" on port 80 and 22 and "jenkins.myserver.com" on port 8080 only.

Thank in advance for your help.

@jwilder
Copy link
Collaborator

jwilder commented Oct 20, 2014

nginx-proxy won't work for proxying port 22 (ssh). For your web traffic on port 80 and 8080, you would just set an env variable VIRTUAL_HOST=gitlab.myserver.com and VIRTUAL_HOST=jenkins.myserver.com on the appropriate containers and run nginx-proxy on the same host. Provided your DNS is setup to point to those domain names to your host, nginx-proxy will route the traffice accordingly. When you start your jenkins and gitlab containers, don't bind them to the host port 80/8080, just let docker assign a host port.

@cosminonnet
Copy link

Thanks a lot for the answer, it's very clear!

So, for the SSH, I'll just let "-p 22:22", so that the gitlab container exposes the port directly. I think that should work :)

Cheers!

@jwilder
Copy link
Collaborator

jwilder commented Oct 20, 2014

That should work although you may need to change your host's SSH port to avoid a conflict.

@cosminonnet
Copy link

One last question, to make sure I fully understand (I am kind of a newbie on all this):

So, if my gitlab container exposes the port like "-p 22:22", then I won't be able to connect to my physical server (let's say "myserver.com ") on SSH port 22 anymore, because the connection will actually be redirected towards the container. The solution is, as you suggested, to have a setting like "-p 10022:22" instead of the exact port binding.

I hope I got this right. Thanks again for your help ;)

@jwilder
Copy link
Collaborator

jwilder commented Oct 20, 2014

Yes. Either the container uses port 22 on the host or the host's SSH daemon does. Only one can use it though.

@cosminonnet
Copy link

Great! I really appreciate it!

@timkendrick
Copy link
Author

@jwilder - am I right in thinking this won't solve the problem though, seeing as @cosminonnet needs to expose both ports 80 and 10022 on the same container?

Is this possible without changing the nginx configuration template?

@timkendrick
Copy link
Author

Sorry, only just realised that you were suggesting routing port 22 directly without going through nginx-proxy. Good idea!

@jwilder jwilder closed this as completed Nov 27, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants