Closed robinvanderstraeten-klarrio closed 1 month ago
Hey @robinvanderstraeten-klarrio thanks for opening this issue, yeah, I see it clear with your report where the bug is. I think your fix will work, so feel free to elaborate a PR when you have the time.
Thanks for your contribution!
I have one related question: why do you need a fixed port? Testcontainers will provide APIs to discover the random port for the service, gcs in this case. I'd like to understand more on your use case.
@mdelapenya it's because we require the public port inside of the container for public-api address which is returned by the program to client so that the client can reach the container back. In this particular case, it is the fake gcs container: https://github.com/fsouza/fake-gcs-server. There's a public host setting https://github.com/fsouza/fake-gcs-server/blob/main/internal/config/config.go#L74, this address is returned to the client who wants to read a file, and that address becomes a full signed URL like http://localhost:port/storage/v1/b/... The port needs to be a port reachable from the host where the client runs.
You'd normally see this behavior in other places, the most notorious would be Apache Kafka that also requires you to advertise a public hostname and an internal hostname (https://docs.confluent.io/platform/current/installation/configuration/broker-configs.html#advertised-listeners). Sometimes you simply need to know the public port before the container is started.
Normally, when this happens, an approach similar to this is preffered: https://github.com/radekg/app-kit-orytest/blob/master/common/common.go#L42-L108.
Wdyt about contributing a module for the fake-gcs-server? Then we can do this magic inside the module, hiding the implementation details to the users. Thoughts?
I have one related question: why do you need a fixed port?
@mdelapenya In our test cases we simulate how our app handles 3rdparty service outage - so we doing stop-start for containers. without explicitly mapped port after restart port changes.
In our test cases we simulate how our app handles 3rdparty service outage - so we doing stop-start for containers. without explicitly mapped port after restart port changes.
@absorbb have you tried toxyproxy for that? We have an example here https://golang.testcontainers.org/examples/toxiproxy/ Probably worth it to convert it into a real Go module 🤔
In our test cases we simulate how our app handles 3rdparty service outage - so we doing stop-start for containers. without explicitly mapped port after restart port changes.
@absorbb have you tried toxyproxy for that? We have an example here https://golang.testcontainers.org/examples/toxiproxy/ Probably worth it to convert it into a real Go module 🤔
Hi @mdelapenya.
I'm experiencing same issue using RabbitMQ testcontainer. We need a fixed port mapping too, because in our tests we create bindings and queues for the exchanges, and with the restart we test that bindings are still persists within the RabbitMQ. So, the toxiproxy is not an option for our library, because with those tests we can be ensured that our queues created by it are durable.
Hope that you manage to use the fork proposed by @robinvanderstraeten-klarrio
chipping in, as I have the same problem but a slightly different cause.
We're having exposed ports defined as 0.0.0.0::9000/tcp
, which for the same reasons now also doesn't work.
The reason we have this, is to explicitly only bind to IPv4. Otherwise, at least on certain Linux systems, it will bind to both IPv4 and IPv6. And initially the port numbers might be the same, but over time there might be a discrepancy where the mapped port for IPv4 is different to the IPv6 port, causing different kinds of issues. (this is due to Docker, a long open issue which I expect won't be resolved, see https://github.com/testcontainers/testcontainers-go/issues/551)
I'm not sure if the provided PR already covers for this. @robinvanderstraeten-klarrio could you add a test case to make sure?
@mdonkers It's already covered, I've added a testcase here: https://github.com/testcontainers/testcontainers-go/pull/2658/commits/352e5ac49e9907a3ed43f34be916778d0ebea68c
Thanks to all of you folks that were involved in the resolution of this bug 🙇
Hey @mdelapenya, is there a chance there will be a patch version released with this fix?
Hi @czeslavo yes, we are planning cutting a release soon. There is a bugbash PR with many small but important refinements that I'd like to get in into the release: https://github.com/testcontainers/testcontainers-go/issues/2685
Testcontainers version
0.32.0
Using the latest Testcontainers version?
Yes
Host OS
Linux (WSL)
Host arch
x86_64
Go version
1.22.3
Docker version
Docker info
What happened?
Since version 0.32.0 of testcontainers, creating a container with an explicit port mapping in
ExposedPorts
(for instance"4443:4443/tcp"
) no longer works. The container starts correctly, but a newly introduced readiness check fails. It incorrectly parses the input given inExposedPorts
and concludes that the container did not start correctly. For context, I'm talking about the logic here. I'm aware that testcontainers creates a port mapping for you, but sometimes you need to know the port before the container starts. Here's an example snippet:Relevant log output
Additional information
I have made a fork with a suggestion for a fix. https://github.com/robinvanderstraeten-klarrio/testcontainers-go/commit/193ab0683acd1372a0d9e071c847b21c3b4ce299
If this is the right approach I'll submit a PR.