Devservices and host exposed ports

[scrocquesel]

I've seen some use cases where test containers need to connect back to the host application:

• Allow to preconfigure dev services container for Kubernetes #38138
• LocalStack Dev Services container cannot connect to host network quarkiverse/quarkus-amazon-services#1161

Typically, the approach involves configuring test containers to allow access to the host and then let the user manually add host ports with Testcontainers.exposeHostPorts. However, this method has its drawbacks:

• Most often, users need to expose the Quarkus server HTTP port, requiring them to search for and write boilerplate code to get the quarkus.http.port value and find the right way to call the method at the right moment.
• Calling Testcontainers.exposeHostPorts leaks implementation details of DevServices.

Would it be possible to have a better and seamless integration of this use case in Dev Services ?

[maxandersen]

Good question - I can see the need and I agree it would be nice to have an API for this or at least a decent convention.

Just have to be careful we don't end up accidentally expose too much local access (i.e. for remote hosts) and I'm curious if this just works in windows/mac where there is an extra level of indirection of the network (at least when using podman)

[geoand]

#39156 is probably also related

[cescoffier]

Do you mean that the container must connect to the host?

This is a bit tricky. There is a special dns name in docker desktop, but I don't think it's portable.

Also, finding the application port may not be possible. Dev services are started before the application. The application may use a random port, which won't be known before runtime. This scenario often happens on tests (rarely in dev as you not know where to connect).

We could think about a port discovery mechanism. There are a few concerns (like what if you have multiple apps running), how could the container retrieve it (After they have been started).

[scrocquesel]

For network issues, dev services uses TestContainer and they should already handle all this. Edges cases should be fix with test container environment variables.
This sould be true when the application runs locally. But I guess, some integration tests can actually run the produced image in a docker container. Obviously, the container port should be accessible and I don't know if the ports are exposed.
If yes, it means we already have part of the problem solved because this generally is those port the user will want to be able to connect to from the dev services test container.

If we cannot discover the port, how is the user supposed to do it by itself in its test code.

Also, it seems that when quarkus.http.port is not set, the app listen on the loopback address only. This can also make things more tricky.

[alesj]

I remember this hack I once had to do to make some things work in Strimzi testing:

• https://gist.github.com/alesj/56e7eb89d5004f83edb109a02e596783
  ... unfortunately my memory sucks on why exactly I had to do this ...

[geoand]

But I guess, some integration tests can actually run the produced image in a docker container

That's what @QuarkusIntegrationTest does when the produced artifact is a container.
You can look at the launch command to see what we set in order to make this work.