Skip to content
This repository has been archived by the owner on Sep 2, 2021. It is now read-only.

Possibility to use multiple port rules #31

Open
Munsio opened this issue May 29, 2017 · 4 comments
Open

Possibility to use multiple port rules #31

Munsio opened this issue May 29, 2017 · 4 comments

Comments

@Munsio
Copy link
Member

Munsio commented May 29, 2017

Sometimes you have an application with multiple ports running and want an subdomain for each - something like:

frontend: 80
admin: 8081
monitoring: 7117

We need an draft to made this possible - so in all we need an label or something else which supports domain+port matching.

@emcniece
Copy link
Member

emcniece commented Sep 8, 2017

Looks like I have an opportunity to put some time in on this. Let's brainstorm.

Possible scenarios:

  1. Single port, single container
  2. Single port, multiple containers
  3. Multiple ports, single container
  4. Multiple ports, multiple containers

The first two cases are straightforward, and we already handle scenarios where upstream blocks have multiple containers. These cases rely on a single port being opened: 80, rgon.port, or whatever is exposed.

Case 3 could mean several things: a single container could have multiple ports open that all accept traffic from a single port (ie. 80 external upstreams to 10.0.0.0:81, :82, and :83) OR it could be that traffic from multiple externals forwards to multiple internals (ie. :81 external -> :81 internal, :82 external -> :82 internal). This requires an upstream block and a location + proxy_pass block for each port pair.

Case 4 is the most complex as it combines all possibilities up to this point.

I think we could implement something that is familiar to Docker users - let each container specify its external and internal ports, like -p 8080:80. We can do some clever grouping by IP and port matching in the template to create a combination of single and multiple ports/upstreams.

Daydream:

version: '2'
services:
  stack1:
    image: whatever
    labels:
      rgon.port: 8000:80, 9000:9000

  stack2:
    image: whatever
    labels:
      io.rancher.scheduler.global: 'true'
      rgon.port: 8000:80, 8001:80

... might produce this: (pseudo-config)

upstream stack1-8000 {
  server 10.0.0.1:80
}

upstream stack1-9000 {
  server 10.0.0.1:9000
}

server stack1-80 {
  listen 80;
  server_name stack1.com
  location / {
    proxy_pass http://stack1-8000
  }
}

server stack1-9000 {
  listen 9000;
  server_name stack1.com
  location / {
    proxy_pass http://stack1-9000
  }
}

upstream stack 2-80 {
  server 10.0.0.2:80
  server 10.0.0.3:80
  server 10.0.0.4:80
}


server stack2-8000-8001 {
  listen 8000;
  listen 8001;
  server_name stack2.com
  location / {
    proxy_pass http://stack2-80
  }
}

@Munsio
Copy link
Member Author

Munsio commented Sep 8, 2017

Okay but you forgot one use-case:

version: '2'
services:
  stack1:
    image: whatever
    labels:
      rgon.domain: example.com:80, api.example.com:8080, admin.example.com:1771

Outbound-inbound port matching is okay but the real thing is that i want to map subdomains to specific ports cause, as in my company, sometimes not widely used ports are blocked, in the case above it would be 1771

@emcniece
Copy link
Member

emcniece commented Sep 8, 2017

@Munsio do we also want to support custom locations?

For example:

example.com/web:80
example.com/api:8080
example.com/db:3306

@Munsio
Copy link
Member Author

Munsio commented Sep 10, 2017

That what you like to achieve is already possible with the vhosts location files cause the URL specification says it that port have to be after TLD so if you catch the route /web in your vhost file it is already possible to create an proxy_redirect rule in there directing to port 3306 etc. etc.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants