Expose same port on host for multiple containers

[irsl]

• This is a bug report
• This is a feature request
• I searched existing issues before opening this one

Description

Docker currently does not allow to execute multiple containers exposing the same port on host. Sometimes it is desirable to launch new version of an image that is to be exposed on the same port on the host. The Docker daemon could be fine tuned to allow this. Some further ideas about the behavior:

• does not allow new containers to be launched when the port is busy: original/legacy/default behaviour
• new container could be launched and packets shall be routed to the latest container (adding the DNAT rule via iptables -I...)
• new container can be launched but iptables shall route (adding DNAT rule via iptables -A ...)

Expected behavior

When starting a container with ports that are already exposed on host, it should just work:

# docker run --rm -it -p 50000:50000 debian:stretch
root@5450034a7506:/#

Actual behavior

# docker run --rm -it -p 50000:50000 debian:stretch
docker: Error response from daemon: driver failed programming external connectivity on endpoint sleepy_rosalind (3a60b9d13be971c9925ce0fc3bc14544a79c5a8cc5441f3b716815e3a803b809): Bind for 0.0.0.0:50000 failed: port is already allocated.
ERRO[0000] error waiting for container: context canceled 

Steps to reproduce the behavior

Run docker run --rm -it -p 50000:50000 debian:stretch twice.

Output of docker version:

Client:
 Version:           18.06.0-ce
 API version:       1.38
 Go version:        go1.10.3
 Git commit:        0ffa825
 Built:             Wed Jul 18 19:09:33 2018
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.0-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       0ffa825
  Built:            Wed Jul 18 19:07:38 2018
  OS/Arch:          linux/amd64
  Experimental:     false

Output of docker info:

Containers: 18
 Running: 18
 Paused: 0
 Stopped: 0
Images: 18
Server Version: 18.06.0-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: d64c661f1d51c48782c9cec8fda7604785f93587
runc version: 69663f0bd4b60df09991c08812a60108003fa340
init version: fec3683
Security Options:
 seccomp
  Profile: default
Kernel Version: 4.9.0-4-amd64
Operating System: Debian GNU/Linux 9 (stretch)
OSType: linux
Architecture: x86_64
CPUs: 1
Total Memory: 1.958GiB
Name: debian-netinst
ID: W2IJ:W3SF:DIJW:ZPWY:EKZ2:F4GC:HRTU:QVR4:Z5RF:2C6A:YKQN:W36R
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: true

Additional environment details (AWS, VirtualBox, physical, etc.)

Does not matter.

[thaJeztah]

You'd need a proxy for this, such as https://github.com/jwilder/nginx-proxy/ or https://traefik.io. Docker Enterprise also provides Layer 7 routing

This is not something that will be integrated in the core functionality of the Engine though, so for that reason, I'll close this issue, but feel free to continue the conversation

[irsl]

I know this could be done by using an additional user land application, like nginx - but the point is here that the proposed functionality would require only minor modifications in the engine itself and could be achieved at iptables level.

[thaJeztah]

let me ping @fcrisciani to have a look