When Docker attempts to expose a port on the host with
docker run -p <external>:<internal>
We have to decide whether to also bind the same port in the VM. In the case of addresses like 0.0.0.0:80 or 127.0.0.1:80 this can make sense, and it will allow running a Docker registry in a container and pushing directly to it, see [docker/for-mac#3611]
However it also opens us up to accidental port clashes between the user's ports and any that we have allocated internally. Recently this happened when a compose on kubernetes container was run with --net=host and bound port 8080, see [docker/compose-on-kubernetes#70].
This patch adds support for "best-effort" binding in the VM and makes this the default. This should re-enable the registry use-case while making us robust to the compose on kubernetes problem. The only downside is that if there is a port clash in the VM, the user won't be notified.
When Docker attempts to expose a port on the host with
We have to decide whether to also bind the same port in the VM. In the case of addresses like
0.0.0.0:80
or127.0.0.1:80
this can make sense, and it will allow running a Docker registry in a container and pushing directly to it, see [docker/for-mac#3611]However it also opens us up to accidental port clashes between the user's ports and any that we have allocated internally. Recently this happened when a compose on kubernetes container was run with
--net=host
and bound port 8080, see [docker/compose-on-kubernetes#70].This patch adds support for "best-effort" binding in the VM and makes this the default. This should re-enable the registry use-case while making us robust to the compose on kubernetes problem. The only downside is that if there is a port clash in the VM, the user won't be notified.
Signed-off-by: David Scott dave.scott@docker.com