testcontainers / testcontainers/testcontainers-java
[Bug]: Containers created with DockerCompose can't resolve host.testcontainers.internal
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 8.7k
- Forks
- 1.9k
- Avg merge
- 2d 17h
- Merged PRs (30d)
- 9
Description
Module
Core
Testcontainers version
1.17.2
Using the latest Testcontainers version?
No
Host OS
MacOS
Host Arch
x86
Docker version
Client:
Cloud integration: v1.0.31
Version: 20.10.24
API version: 1.41
Go version: go1.19.7
Git commit: 297e128
Built: Tue Apr 4 18:21:21 2023
OS/Arch: darwin/amd64
Context: default
Experimental: true
Server: Docker Desktop 4.18.0 (104112)
Engine:
Version: 20.10.24
API version: 1.41 (minimum version 1.12)
Go version: go1.19.7
Git commit: 5d6db84
Built: Tue Apr 4 18:18:42 2023
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.18
GitCommit: 2456e983eb9e37e47538f59ea18f2043c9a73640
runc:
Version: 1.1.4
GitCommit: v1.1.4-0-g5fd4c4d
docker-init:
Version: 0.19.0
GitCommit: de40ad0
What happened?
If started an HttpServer, then exposed its port using
Testcontainers.exposeHostPorts(webHookPort);
Then I start my service using DockerComposeContainer
My service then can't resolve hostname "host.testcontainers.internal"
This is because all the magic to resolve this is done in GenericContainer
here to attach to network https://github.com/testcontainers/testcontainers-java/blob/b448c9a25763da3d99e6f15aeba4941b85cc0215/core/src/main/java/org/testcontainers/containers/GenericContainer.java#L435
here to add the hostname resolution
I was able to workaround it :
Add this to docker compose on service where you need the host to be resovled
extra_hosts:
- "host.testcontainers.internal:${HOST_TESTCONTAINERS_INTERNAL_IP}"
Then before starting the docker compose get an instance of the sshd container and its network
var dockerCLient = DockerClientFactory.lazyClient();
final Container sshdContainer = dockerCLient.listContainersCmd()
.exec()
.stream()
.filter(c -> c.getImage().contains("sshd"))
.findFirst()
.orElseThrow(() -> new Exception("PortForwardingContainer not found"));
final ContainerNetwork sshContainerNetwork = sshdContainer.getNetworkSettings()
.getNetworks()
.values()
.stream()
.findFirst()
.orElseThrow(() -> new Exception("PortForwardingContainer network not found"));
Then you can push the IP to the DockerCompose env
.withEnv("HOST_TESTCONTAINERS_INTERNAL_IP", sshContainerNetwork.getIpAddress())
Then join your containers to the network with command
final ContainerState mycontainer = dockerCompose.getContainerByServiceName("service_1")
.orElseThrow();
mycontainer.getDockerClient().connectToNetworkCmd()
.withContainerId(mycontainer.getContainerId())
.withNetworkId(sshContainerNetwork.getNetworkID())
.exec();
Relevant log output
No response
Additional Information
No response
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing exposeHostPorts in core/src/main/java/org/testcontainers/containers/GenericContainer.java at the referenced attachment and hostname-resolution code, then compare that behavior with DockerComposeContainer startup. Reproduce the MacOS Docker Compose case described in the issue and verify that a Compose service can resolve host.testcontainers.internal and reach the exposed host port without the workaround.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, docker-compose, java
- Domain
- networking, testing-qa
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100