New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

getTestHostIpAddress is not possible under Docker for Mac beta #166

Closed
rnorth opened this Issue Jul 3, 2016 · 15 comments

Comments

Projects
None yet
9 participants
@rnorth
Member

rnorth commented Jul 3, 2016

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

This comment has been minimized.

Member

bsideup commented Jan 23, 2017

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

@dbalakirev

This comment has been minimized.

dbalakirev commented Mar 7, 2017

@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

This comment has been minimized.

Member

bsideup commented 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

This comment has been minimized.

dbalakirev commented 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

This comment has been minimized.

Member

rnorth commented 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

This comment has been minimized.

Contributor

rwinch commented 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:

	/**
	 * 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

This comment has been minimized.

Member

kiview commented Sep 21, 2017

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

@arcuri82

This comment has been minimized.

arcuri82 commented 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

This comment has been minimized.

drichelson commented 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

This comment has been minimized.

Member

bsideup commented Feb 5, 2018

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

This comment has been minimized.

drichelson commented 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- 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

This comment has been minimized.

bahtiyarkaba commented 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

This comment has been minimized.

stale bot commented 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.

@stale stale bot added the stale label Oct 28, 2018

@rnorth

This comment has been minimized.

Member

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

@rnorth rnorth closed this Oct 28, 2018

@rusakovStas

This comment has been minimized.

rusakovStas commented Nov 15, 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 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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment