Allow for port bindings to be setup between container and host

[flipmokid]

Some applications such as Couchbase have reserved ports which must be exposed with the same port number on the host. As such, the current mapped port settings will not help us create these containers and be sure that the same reserved ports are exposed.

If the testcontainers library could add a method such as withPortBinding(exposedPort, hostPort) that allowed the setup of these port bindings then I think it would fix this issue.

Thanks

[rnorth]

Hi
Yes, thank you for the suggestion. It seems like a good idea in principle.

My only slight worry is what happens if the requested host port is not available. Part of the rationale for the current design is to make this kind of failure unlikely - from painful experience of port contention making int test suites unreliable.

As such, I think I'd probably want to only expose this method on a suitably-named subclass of GenericContainer. This way everyday users wouldn't accidentally open their tests up to this risk, but people who are willing to accept the risk can.

What do you think? Would this work for you?

Thanks again

Richard

On 10 Feb 2016, at 19:09, flipmokid notifications@github.com wrote:

Some applications such as Couchbase have reserved ports which must be exposed with the same port number on the host. As such, the current mapped port settings will not help us create these containers and be sure that the same reserved ports are exposed.

If the testcontainers library could add a method such as withPortBinding(exposedPort, hostPort) that allowed the setup of these port bindings then I think it would fix this issue.

Thanks

―
Reply to this email directly or view it on GitHub.

[flipmokid]

Hi Richard,

You're right, we should aim to highlight to the user that there is inherent risk involved in trying to start a container whose application expects ports to be a fixed number. I'm more than happy for the functionality proposed to be included in a subclass that highlights this warning.

Thanks

Manpreet

[rnorth]

I've just released v1.0.1 with this change in - I hope this works for your use case now!
Thanks
Richard

[flipmokid]

Great stuff! I'll give it a go on Monday!

Thanks again