Skip to content
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

Resolve issues with Docker Compose when running under Docker for Windows #306

Closed
rnorth opened this issue Mar 3, 2017 · 4 comments
Closed

Comments

@rnorth
Copy link
Member

rnorth commented Mar 3, 2017

Re this on #297, it seems that Docker Compose has an issue when using Docker for Windows.

We are releasing Docker for Windows support so as not to delay any further, but docker compose support still needs to be fixed.

rnorth added a commit that referenced this issue Mar 12, 2017
## [1.2.0] - 2017-03-12
### Fixed
- Fix various escaping issues that may arise when paths contain spaces (#263, #279)
- General documentation fixes/improvements (#300, #303, #304)
- Improve reliability of `ResourceReaper` when there are a large number of containers returned by `docker ps -a` (#295)

### Changed
- Support Docker for Windows via TCP socket connection (#291, #297, #309). _Note that Docker Compose is not yet supported under Docker for Windows (see #306)
- Expose `docker-java`'s `CreateContainerCmd` API for low-level container tweaking (#301)
- Shade `org.newsclub` and Guava dependencies (#299, #292)
- Add `org.testcontainers` label to all containers created by Testcontainers (#294)
@kmruiz
Copy link

kmruiz commented Apr 26, 2017

Hi,

I reproduced the problem on my Windows 10 machine when using docker-compose on a docker for some tests. I downloaded the source code of the library and found what I think is the problem.

On method org.testcontainers.containers.GenericContainer#addFileSystemBind you build a path using MountableFile, but this path is incorrect. On Docker for Windows, this Java process will run on Windows, but the docker runs into a Linux VM under Hyper-V.

Building this path in the wrong way will make docker-compose unable to communicate with the underlying docker system that it's on Linux, because it's using a Windows path.

A fast check is, if you ignore the MountableFile and pass to binds.add the raw hostPath, it will work for almost all Docker-Compose tests. There is one issue with org.testcontainers.junit.DockerComposeOverrideTest#testEnvVar but looks like it's another issue with paths again (but not with docker-compose interaction itself).

Hope this info helps. I will investigate further because I want to use this lib on Windows (on Linux already works fine).

PS: the patch for making the test pass on W10

@Override
    public void addFileSystemBind(String hostPath, String containerPath, BindMode mode) {

        // final MountableFile mountableFile = MountableFile.forHostPath(hostPath);
        binds.add(new Bind(hostPath, new Volume(containerPath), mode.accessMode));
    }

@kiview
Copy link
Member

kiview commented Apr 27, 2017

Nice work :)
You can put the patch in a PR if you like.

@kmruiz
Copy link

kmruiz commented Apr 27, 2017

I'm trying to solve the problem with the failing test. Looks like there are some problems when resolving file paths when working with Hyper-V because Linux paths need to be written as is, but seems that Windows paths need to be translated to the mount point of Hyper-V.

If I make it work I will send you a PR :)

@kiview
Copy link
Member

kiview commented Feb 26, 2018

This has been fixed some time ago, i.e. in #514.

@kiview kiview closed this as completed Feb 26, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants