QuarkusIntegrationTest: docker option --net=host not supported for windows

[bdevreugd-vialis]

In Quarkus 2.1.0 the docker run command has changed to bind to the host network instead. This property, however, is invalid on windows (and mac?). Nor does this work properly if the container is started from another container (for example on our gitlab runner).

quarkus/test-framework/common/src/main/java/io/quarkus/test/common/DefaultDockerContainerLauncher.java

Line 81 in d0555c7

args.add("--net=host");

Obviously the old behavior had major issues as well, so I thought of a solution that will work in all cases:

Why not run the docker image (containing the application) using testcontainers as well?

• All the test containers should be started on the same network (withNetwork(Network.SHARED), see the Kafka dev service)
• The dev services set a Network Alias (withNetworkAliases("name-" + Base58.randomString(5)))
• The DevServicesNativeConfigResultBuildItem should contain both 'regular' as 'container-network' values, for example:
  • kafka.bootstrap.servers has PLAINTEXT://localhost:49215 and PLAINTEXT://kafka-x42bz:9092,
  • quarkus.mongodb.connection-string has mongodb://localhost:49213/test and mongodb://mongo-8ux2l:27017/test

When running the testcontainer containing the application, we would provide the second set of values while all others receive the first set.

[quarkus-bot]

/cc @geoand

[geoand]

The suggestion is interesting, but I don't see how setting both hosts would solve the problem.

We could use test containers to launch the container, but I would really like to avoid that...

[bdevreugd-vialis]

The main issue right now is that it is rather hard to write a solution that fits all (windows / mac / linux / from within another container). So I though, why not use a solution that already supports all those (edge) cases.

Reason I added both connection strings was that an connection inside the testcontainer network is different then a connection from the host to a testcontainer.

Anyway, any other solution that would work on all those cases would be great as well.

[geoand]

Right, I understand the rationale and definitely appreciate the input!

I have another idea that would be simpler to implement and hopefully would cover all cases.
I'll work on it today and see how it goes

[geoand]

I used some of your ideas to open #18933.

Thanks for the input