It will just look so much nicer in my test than
genericContainer.getContainerInfo().getNetworkSettings().getPorts().getBindings().get(new ExposedPort(originalPort, protocol))[0].getHostPortSpec()
I think it has something to do with the law of demeter.
But in all fairness root cause is https://github.com/moby/moby/issues/4635
Wow, yes, that is quite a lot of code for something that ought to be nice and simple.
I think our withExposedPorts method ultimately _only_ sets up TCP port mappings. Are you looking, then, for:
withExposedPorts(Integer originalPort, InternetProtocol protocol) method (and a corresponding add... method)getMappedPort(Integer originalPort, InternetProtocol protocol) methodIs this what you mean?
This seems like an straightforward and worthwhile thing to add - thanks.
Both would be nice.
When I created the issue, the port was exposed in the dockerfile and default behavior is to Map all port so it was only retrieving that caused a fuzz.
I have now also added an unexposed udp port thru the createCommand hook.
So having both methods, would make usage easier and the test code much nicer.
@rnorth do you need help here? I can take care of this issue
@agafox PR would be greatly appreciated 馃檪
Late to this conversation. Is there a way to map UDP ports with randomly assigned port numbers as with ".withExposedPorts()" ?
I need to implement the equivalent of docker-compose
ports:
- 6831:6831/udp
- 6832:6832/udp
I also need to have TestContainers map the udp ports like it does for TCP.
I tried to use Testcontainers in a black box test use case where I wanted to ran a test against several network flow services provided on UDP port 50000-50003 in our application. I use the DockerComposeContainer which builds and runs a stack of the required services and publishes services on 50000-50003/udp and one for a REST API endpoint on 8980/tcp. I was able to use the withExposedService() method for the REST API port. The test sends some network flow packets into our application and we check with some REST API calls if the packets are processed and stored correctly.
During the test I've noticed the withExposedService() method only allows to create TCP mappings which are required to use the getServiceHost() and getServicePort() methods from DockerComposeContainer to resolve the dynamically assigned host and ports.
I was able to workaround this issue by publishing a static port 50000-50003/udp in my docker-compose.yml file. Each port represents a different network flow protocol implementation:
ports:
- '50000:50000/udp'
- '50001:50001/udp'
- '50002:50002/udp'
- '50003:50003/udp'
So I can form a InetSocketAddress against the local machine and bypass the Testcontainer framework. That way I'll loose the ability to use dynamically mapped ports and have to ensure this test runs only once on the host system.
The code for the test can be found here and the Docker Compose file is here
This is a pretty serious issue, I can see a lot of people are trying to test jaeger based on the UDP port there, including me.
For anyone else coming from Google with this issue, simply use:
addFixedExposedPort(5775, 5775, InternetProtocol.UDP);
addFixedExposedPort(6831, 6831, InternetProtocol.UDP);
addFixedExposedPort(6832, 6832, InternetProtocol.UDP);
in your custom jaegertracing/all-in-one GenericContainer's constructor
Anyone working on this? Was it resolved?
@sHiniz0r
There is currently no implementation for a dynamically mapped port for UDP. Are you interested in contributing this?
@kiview yes, I would like to try to contribute it.
Great, feel free to ping me in Slack if you want discuss details or have questions.
I'd think implementation should be relatively straight forward, unless I overlooked something.
Most helpful comment
Late to this conversation. Is there a way to map UDP ports with randomly assigned port numbers as with ".withExposedPorts()" ?
I need to implement the equivalent of docker-compose
I also need to have TestContainers map the udp ports like it does for TCP.