testcontainers-java

testcontainers-java copied to clipboard

Module

Core

Problem

cannot make a container inside the docker compose network to communicate with the docker host machine via a specific port.

Solution

use the same port forwarding mechanism that GenericContainer has in order to expose a host port to the docker compose network.

Benefit

containers inside docker compose to communicate back with a test that verifies some e2e scenario.

Alternatives

create some container inside the compose and communicate with it.

Would you like to help contributing this feature?

No

Hey @adilev26, you are right that this does not work. Since in the case of DockerComposeContainer, parts of the functionality that is normally executed by Testcontainers gets delegated to Docker Compose, integrating this feature might be a bit more complicated.

In general, I'd suggest using a pure Testcontainers-based approach for this use case instead.

hi @kiview, I agree about the complexity, if the compose environment is quite simple then it would be a good idea to use Testcontainers-based approach but when we have more complex ones such as redis/pulsar clusters with mapped ports it's less feasible. I wonder if this could be done as a post compose execution to link the SSHD container to the compose network rather how it is done with GenericContainer.

but when we have more complex ones such as redis/pulsar clusters with mapped ports it's less feasible.

I would like to see a setup, where this is not possible or hard 🙂 TBH, I think Testcontainers provides a very powerful and flexible way to define everything you can define with Docker Compose, and instead of using YAML, you can use a statically typed Java-based DSL, that has full debugging and IDE auto-completion capabilities. In addition, Testcontainers allows to model real startup dependencies between containers, a feature that works in a very limited fashion in Docker Compose.

Because we as Testcontainers maintainers fundamentally believe in this philosophy, we are generally hesitant to invest larger amounts of work to create feature parity for DockerComposeContainer.

But yes, there will be for sure technical mechanisms by which this feature could be made to work with DockerComposeContainer as well, and exploring this and providing a PR would be appreciated. Please note that DockerComposeContainer works for containerized Docker Compose as well as with the local binary and the upcoming work for Compose V2 support creates even higher friction around this module.