[Enhancement]: Improve port mapping consistency for IPv4 and IPv6 when using getMappedPort() method

[timlukas]

Module

Core

Proposal

Hi.
We just ran into an issue similar to those described in testcontainers-node and testcontainers-dotnet and wanted to raise the java equivalent issue.

Testcontainers version: 1.20.2

Description

container.getMappedPort() returns inconsistent port mappings when using Docker containers with both IPv4 and IPv6.

Problem

We have a test case to verify, that our application can establish a connection to a docker container via IPv6.
To tell our app where to reach the container, we used

container.getMappedPort(9093)

Turns out that this results in a flaky test, because sometimes Docker assigns different random host ports to the IPv4 and IPv6 bindings.

Typical scenario:
0.0.0.0:55555->9093/tcp, :::55555->9093

Problematic scenario (notice the different host ports):
0.0.0.0:55555->9093/tcp, :::55556->9093

getMappedPort() always returns the first mapped port in the bindings list (return Integer.valueOf(binding[0].getHostPortSpec());).

Workaround

To achieve consistent results, we currently use the following workaround:

Retrieve the bindings via:
containerInfo.getNetworkSettings().getPorts().getBindings().get(new ExposedPort(targetPort))

Filter the result by hostIP:

• 0.0.0.0 for IPv4
• :: for IPv6

Proposed Solution

How about adding dedicated methods to retrieve the ports for IPv4 and IPv6, such as:

container.getMappedIpv4Port()
container.getMappedIpv6Port()

[kiview]

Thanks for opening the issue @timlukas, you are right about this inconsistency and thanks for sharing the workaround.

Given that Docker/moby did fix this upstream in moby/moby#47871 (which is part of of Docker Engine 27 and hence Docker Desktop 4.34.0), I am inclined to have this fixed in the upstream only, instead of handling it across all libraries downstream (that was also our decision for tc-go).

Are you able to upgrade Docker accordingly in your environments and see if that fixes the issue?

[timlukas]

Many thanks for the quick reply and pointing me in the right direction!

That actually looks like it should solve our problem. Until we can update Docker, I can totally live with our workaround.