You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
getTestHostIpAddress is not possible under Docker for Mac beta #166
Current Docker for Mac beta does not provide an easy mechanism for establishing the host machine's IP address. This means that getTestHostIpAddress cannot function.
Users can use a simple workaround, but I'd like to find a better solution to this.
This post, among others, describes the issue and some proposed workarounds.
Reacted by dbalakirev, Rob Winch, Andrea Arcuri, Dennis Neufeld, Maksim Kostromin and Oliver
@Override
public String getTestHostIpAddress() {
if (DockerMachineClient.instance().isInstalled()) {
This is from the GenericContainer so I am not sure why this is mac specific?
How do you really run Selenium tests against services (webserver for example) on the host machine?
The reason I'd be interested in this is to retrofit testcontainers to existing java webapps without changing the apps themselves. Meaning I'd like to use testcontainers-selenium so I don't need to install various browsers etc. And developers would be able to conveniently test their local apps.
We should act on this, as it's clear that it's not going to be 'fixed' in Docker for Mac.
@dbalakirev's use case (local apps) was the first use case that I created Testcontainers' selenium support for (way back), so I do really see a need to restore it, and it pains me that DfM doesn't support it.
In the short term docker machine works; I think it's incumbent on us now to try and find a way to make this possible with the 'native' implementations.
I'm also interested in support for connecting to a web application running on the host, but for a Linux based host. Do I need a separate issue or will this issue solve for Linux as well?
In the meantime, this seems to work for me at the moment as a workaround:
/** * Taken from {@link DockerClientConfigUtils#getDetectedDockerHostIp()} but removed * {@link DockerClientConfigUtils#IN_A_CONTAINER} because this always reports false. * * @return the ip address for the browser to connect to */privatestaticStringgetDetectedDockerHostIp() {
returnOptional.ofNullable(DockerClientFactory.instance().runInsideDocker(
cmd -> cmd.withCmd("sh", "-c", "ip route|awk '/default/ { print $3 }'"),
(client, id) -> {
try {
returnclient.logContainerCmd(id)
.withStdOut(true)
.exec(newLogToStringContainerCallback())
.toString();
} catch (Exceptione) {
returnnull;
}
}
))
.map(StringUtils::trimToEmpty)
.filter(StringUtils::isNotBlank)
.orElse(null);
}
Hi,
I ended up here after trying to understand why getTestHostIpAddress() is failing on my Mac. I understand that fixing it can be complicated, if possible at all. However, it would be great to have some checks on the current OS, and throw a custom exception on Mac saying something like "getTestHostIpAddress() is not currently working on Mac. See (link) for further details"
Thanks @bsideup for the additional context. I'm wondering if an additional method: getTestHost() would make sense? It would return a string that could be either an IP address or a hostname- ie docker.for.mac.host.internal. This doesn't solve the various issues you mention, but I imagine it would aid in solving the core problem by allowing more flexibility in reaching the test host.
IMHO, it's just an expected case to try to reach host machine from test containers e.g for Selenium Web Driver testing.
The documentation also supports this idea. It shows a getHostIpAddress
method. Was this an existing feature that was removed? https://www.testcontainers.org/usage/webdriver_containers.html
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this is a mistake, please reply to this comment to keep it open. If there isn't one already, a PR to fix or at least reproduce the problem in a test case will always help us get back on track to tackle this.
Sorry for letting this issue remain open for so long. There is a feature in 1.9.0 that makes connections from containers to the host vastly easier, and in a way that works regardless of the machine it is run on.
Sorry for letting this issue remain open for so long. There is a feature in 1.9.0 that makes connections from containers to the host vastly easier, and in a way that works regardless of the machine it is run on.
Activity
bsideup commentedon Jan 23, 2017
Hey @rnorth,
I'm wondering what's the status of this issue?
dbalakirev commentedon Mar 7, 2017
This is from the GenericContainer so I am not sure why this is mac specific?
How do you really run Selenium tests against services (webserver for example) on the host machine?
bsideup commentedon Mar 7, 2017
@dbalakirev Docker for Mac doesn't provide a way to connect to the host machine from containers.
I think Docker for Windows will fail as well.
It's not a good idea to connect to the host machine from your containers after all.
However, you can run your service under test in a container as well :)
dbalakirev commentedon Mar 29, 2017
@bsideup thanks for your answer.
The reason I'd be interested in this is to retrofit testcontainers to existing java webapps without changing the apps themselves. Meaning I'd like to use testcontainers-selenium so I don't need to install various browsers etc. And developers would be able to conveniently test their local apps.
rnorth commentedon Mar 29, 2017
We should act on this, as it's clear that it's not going to be 'fixed' in Docker for Mac.
@dbalakirev's use case (local apps) was the first use case that I created Testcontainers' selenium support for (way back), so I do really see a need to restore it, and it pains me that DfM doesn't support it.
In the short term docker machine works; I think it's incumbent on us now to try and find a way to make this possible with the 'native' implementations.
rwinch commentedon Aug 28, 2017
I'm also interested in support for connecting to a web application running on the host, but for a Linux based host. Do I need a separate issue or will this issue solve for Linux as well?
In the meantime, this seems to work for me at the moment as a workaround:
kiview commentedon Sep 21, 2017
Wouldn't this workaround work for D4M as well? Or is there no bridged network interface?
arcuri82 commentedon Oct 26, 2017
Hi,
I ended up here after trying to understand why getTestHostIpAddress() is failing on my Mac. I understand that fixing it can be complicated, if possible at all. However, it would be great to have some checks on the current OS, and throw a custom exception on Mac saying something like "getTestHostIpAddress() is not currently working on Mac. See (link) for further details"
drichelson commentedon Feb 5, 2018
I too have come across this issue. Newer Docker for Mac versions have a very easy way to work around this: https://docs.docker.com/docker-for-mac/networking/#known-limitations-use-cases-and-workarounds
I've built this into my Docker test fixtures and will try to put together a PR so it will be seamless.
bsideup commentedon Feb 5, 2018
Hi @drichelson,
We know about the workaround, but unfortunately, it's not that easy as you say :)
.localhostand.localsuffixes :DPR is always welcome, but please keep in mind all these nuances
drichelson commentedon Feb 5, 2018
Thanks @bsideup for the additional context. I'm wondering if an additional method:
getTestHost()would make sense? It would return a string that could be either an IP address or a hostname- iedocker.for.mac.host.internal. This doesn't solve the various issues you mention, but I imagine it would aid in solving the core problem by allowing more flexibility in reaching the test host.bahtiyarkaba commentedon Jun 5, 2018
IMHO, it's just an expected case to try to reach host machine from test containers e.g for Selenium Web Driver testing.
The documentation also supports this idea. It shows a getHostIpAddress
method. Was this an existing feature that was removed?
https://www.testcontainers.org/usage/webdriver_containers.html
stale commentedon Oct 28, 2018
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this is a mistake, please reply to this comment to keep it open. If there isn't one already, a PR to fix or at least reproduce the problem in a test case will always help us get back on track to tackle this.
rnorth commentedon Oct 28, 2018
Sorry for letting this issue remain open for so long. There is a feature in 1.9.0 that makes connections from containers to the host vastly easier, and in a way that works regardless of the machine it is run on.
Please see the release notes for 1.9.0.
Instead of obtaining a host IP address, the supported way is now to use this
exposeHostPortsfeature. Please give it a try if you can!rusakovStas commentedon Nov 15, 2018
Ohh i'm searched this for two days))
Thank's very mach for this link!