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

Specify predictable range of host ports used for fig scale cli #722

Closed
lwoodson opened this Issue Dec 11, 2014 · 10 comments

Comments

Projects
None yet
@lwoodson

lwoodson commented Dec 11, 2014

Discussed this with @dnephin in IRC this evening, and he said it would be worth an issue here:

  • Allow a range of host ports to use when auto-assigning port forwarding to containers. For example, "5000..5100:80" would indicate that the ports 5000 to 5100 should be chosen from when scaling containers.
  • When scaling, pick the lowest available port in the range.
  • When no more ports are available in the range, fail to spawn new containers via scale.
  • When containers are spun down via scale, reclaim their ports for future use.

Why: I would like to set up haproxy in front of X hosts that manage Y containers via fig, and be able to have a predictable range of ports on each host that will forward to containers. This way, I could use haproxy's health check configuration to determine what ports should be routed to on what hosts.

@thaJeztah

This comment has been minimized.

Member

thaJeztah commented Dec 11, 2014

Perhaps these could be of interest to you (automatic registration/discovery); https://github.com/jwilder/docker-register and https://github.com/jwilder/docker-discover (which uses haproxy)
The tool used in those links (docker-gen) listens for docker events uses the properties of the containers that triggered the event to propagate templates or run commands.

@lwoodson

This comment has been minimized.

lwoodson commented Dec 12, 2014

Thanks for the heads up, @thaJeztah. I'll look into them.

@kelonye

This comment has been minimized.

kelonye commented Dec 18, 2014

+1

@aanand

This comment has been minimized.

Contributor

aanand commented Dec 19, 2014

This is an interesting idea. Pinging the Swarm folks (@aluzzardi, @vieux), who probably have opinions on how load-balancing should work in a clustered environment.

@ddgnani

This comment has been minimized.

ddgnani commented Feb 20, 2015

+1 for the ability in fig scale to allow a range of host ports to use when auto-assigning port forwarding to containers

@rmetzler

This comment has been minimized.

rmetzler commented Aug 28, 2015

+1
Sometimes I need to set up 20 containers all the same but every container needs 2 mapped ports.
Usually I use even numbers for one port and odd numbers for the other one, but I also could use different ranges for each.

Currently I write a short shell script, but using Compose would be beneficial.

@DracoBlue

This comment has been minimized.

DracoBlue commented Aug 31, 2015

👍

@jantoniucci

This comment has been minimized.

jantoniucci commented Apr 12, 2016

You are refering to 1241 which was closed by duplicate with this issue maling a loop

@Aourin

This comment has been minimized.

Aourin commented Jul 29, 2016

@rmetzler I am doing the same thing with the script that can start and stop those containers with some other args. However, I only did it as a work around because of port randomization.

I am not sure the state of this or if anyone is making any movement on this. Seems to be something that noone is sure of how to do. To address @aanand, it would probably be cool to see how it works in swarm, but that is also a secondary part of a feature like this. For example, someone wanting to simply scale up containers across a spread of ports or provided ports, but use their own load balancer implementation, would be a candidate.

@shin-

This comment has been minimized.

Member

shin- commented Aug 4, 2017

Recent releases now support the p1-p2:p syntax (via #4649)

@shin- shin- closed this Aug 4, 2017

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