It looks like there are a few conflicts between this and #12622, I think the better solution would be some combination of both PRs (see: #10052 (comment)) - I just never got around to implementing this format.

A couple of questions for you:

• What does the hostConfig look like on a container that is started with this feature?
• What happens on restart of the container started this way? (try to keep the same allocated port, or always re-allocate from the range?)

I love what you've done with the port range keys in the global map. I started out doing something similar, but with multiple port maps so I came across an issue where you can have potentially overlapping maps that will conflict with each other. This is a much more elegant approach.

@bru7us

Here is an example session:

$ docker run -d -p 8000-9000:80 --name porttest nginx
$ docker port porttest
80/tcp -> 0.0.0.0:8003
$ docker inspect porttest
[{
  ...
    "HostConfig": {
  ...
        "PortBindings": {
            "80/tcp": [
                {
                    "HostIp": "",
                    "HostPort": "8000-9000"
                }
            ]
        },
  ...
    },
  ...
    "NetworkSettings": {
  ...
        "Ports": {
            "443/tcp": null,
            "80/tcp": [
                {
                    "HostIp": "0.0.0.0",
                    "HostPort": "8003"
                }
            ]
        }
  ...
    },
  ...
}
]
$ docker restart porttest
$ docker port porttest
80/tcp -> 0.0.0.0:8004

The restart does not attempt to keep the same port, but it does re-allocate from within the same requested port range.

Thanks for the follow up - I'm struggling to understand the benefit of using this instead of just any ephemeral port (outside of the scope of the other PRs). If every restart auto-allocates a port - why not just use the ephemeral range?

I think my latest comment (#12622 (comment)) sums up the ultimate solution (a combination of your work, mine and that in #10052), do you have any feedback on that?

My use-case is that I'm attempting to use AWS Security Groups to differentiate between 'public' vs 'private' port ranges to allow external traffic. I need to be able to assign container ports in a more controlled manner than just using ephemeral ports.

I'll take a look at #12622 and provide some feedback

@docker/core-maintainers for design review. I think it is smaller and less-breaking than #12622

I think it is smaller and less-breaking than #12622

It's definitely smaller, but it's also different than #12622 as it doesn't provide persistence for dynamic allocations (which is the primary goal of that PR - I just absorbed the changes from this one into it for better use case coverage).

Rebased off master. Updated vendor/src/github.com/docker/libnetwork to match moby/libnetwork#285

@mavenugo @mrjana @aboch Thoughts?

@mavenugo @mrjana @aboch @icecrime Any word on this?

Group review session

Design LGTM assuming that the container doesn't persist the elected port (which was the reason that the alternative implementation got previously closed).

Ping @mrjana @mavenugo @aboch: please review!

@mrjana @mavenugo @aboch @icecrime : Rebased off master

@dkjer have a comment / question for your PR in libnetwork moby/libnetwork#285. Can you please address that so that we can get this PR moving ?

@mavenugo Sure, apologies for the delay

@dkjer latest libnetwork with your patch is in docker master now. Can you please rebase to the latest and update this PR ?

@mavenugo Rebased

@mavenugo, did you see moby/libnetwork#453 yet? If we can catch it before this PR gets merged we can easily maintain full backward compatibility in libnetwork with a minor update to this PR to include separate start port and specified port.

If this gets merged first, there will be a dependency on docker and libnetwork to be updated together to get persistence policies in.

@mavenugo Error string updated / commit squashed

@dkjer Could you please cover this in current integration cli test for port specs: docker_cli_port_test.go
You can just integrate the existing test functions with few more cases where the host port range is specified (correctly and incorrectly) and verify it.

@mavenugo @aboch Addressed code review comments and added integration test. Squashed commit

LGTM

@bru7us sorry not yet. we have start with design review of moby/libnetwork#453 and make sure the features align with all the upcoming features. We have to also look @ all the design review comments of #12622. I think it is okay to keep 2 separate.

Ok, thanks for the response.

@dkjer Thanks for addressing the comments.
The implementation LGTM and is inline with the use-case that was discussed in this PR during the design review.

But, I think we need some inputs from the docs team especially because the -p host-port-range:container-port-range behaves a bit different from the newly introduced -p host-port-range:container-port and also the persistence expectations are a bit different.

ping @moxiegirl @thaJeztah

@mavenugo I'll LGTM and carry the change after the merge if you are cool with it.

sgtm, agreed to update after merging so LGTM

@moxiegirl I'll merge this one, then I'll rebase #15675 when I'm home, does that work for you?

@moxiegirl Thanks for carrying the doc changes!

Thank you @dkjer for contributing, and being so patient!