getTestHostIpAddress is not possible under Docker for Mac beta

[rnorth]

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.

[bsideup]

Hey @rnorth,
I'm wondering what's the status of this issue?

[dbalakirev]

@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?

[bsideup]

@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]

@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]

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]

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
	 */
	private static String getDetectedDockerHostIp() {
		return Optional.ofNullable(DockerClientFactory.instance().runInsideDocker(
				cmd -> cmd.withCmd("sh", "-c", "ip route|awk '/default/ { print $3 }'"),
				(client, id) -> {
					try {
						return client.logContainerCmd(id)
								.withStdOut(true)
								.exec(new LogToStringContainerCallback())
								.toString();
					} catch (Exception e) {
						return null;
					}
				}
		))
		.map(StringUtils::trimToEmpty)
		.filter(StringUtils::isNotBlank)
		.orElse(null);
	}

[kiview]

Wouldn't this workaround work for D4M as well? Or is there no bridged network interface?

[arcuri82]

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]

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]

Hi @drichelson,

We know about the workaround, but unfortunately, it's not that easy as you say :)

1. it depends on a host's OS, with different DNS names on Mac and Windows
2. There is no such on Linux
3. There are two versions, with .localhost and .local suffixes :D
4. Doesn't work with remote Docker

PR is always welcome, but please keep in mind all these nuances

[drichelson]

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.

[bahtiyarkaba]

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]

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]

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 exposeHostPorts feature. Please give it a try if you can!

[rusakovStas]

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 exposeHostPorts feature. Please give it a try if you can!

Ohh i'm searched this for two days))
Thank's very mach for this link!