Compose: Specify predictable range of host ports used for fig scale cli

[lwoodson]

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]

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]

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

[kelonye]

+1

[aanand]

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]

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

[rmetzler]

+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]

:+1:

[jantoniucci]

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

[TheBubbleDuck]

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

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

[maxt]

Hi! It looks like when you have this range p1-p2:p and use docker-compose up & docker-compose down the first time initial port will be p1, and when you use docker-compose up next time, you get initial p1+1 port. I tried both --force-recreate and --no-recreate options for docker-compose up command but it makes no difference. Version is 1.23.2. Can I somehow specify that each time it must use the first port from the range?
I also noticed that if you do the following sequence:
docker-compose up -> docker-compose down -> docker service restart -> docker-compose up
everything looks good and the initial port is p1 again.

[NonaryR]

@maxt hello! did you find a way to resolve this? Stack with the same problem, address already in use, only restart helps, or great random -)

[maxt]

@NonaryR Hello! Unfortunately, I didn't find a way to fix this behaviour.

[juliofalbo]

Any news around this bug? @shin-