-
Notifications
You must be signed in to change notification settings - Fork 18.6k
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
Docker Swarm on Docker Machine VirtualBox VM and Windows Path Issue #34997
Comments
I'm sure you're all quite busy, but is there a chance that someone could take a look at this? This behaviour makes it impossible to have a docker-compose.yml file that can be shared amongst members of my development team when I want to test operation within a local swarm instance, as we all use Windows as our development platform. |
/cc @dnephin @vdemeester |
Oh, I realized it's because this is running from a windows client on a linux swarmkit worker. I'm not sure where this translation is supposed to happen, but the client really doesn't have enough information to translate paths. It has no idea what platform will receive the task. |
I guess this is something that would need to be translated by Docker for Windows. That's really the only place it makes sense. |
cc @ebriney who might better remember how this part of the system works |
I think the problem is roughly that;
Not sure what the best approach is for that; make it behave the same as docker compose, or document that absolute paths are the recommended approach when deploying to a swarm (even more so, because when using services, the host path is not automatically created) |
@thaJeztah, the problem with requiring absolute paths is that the development environment is no longer reproducible. I'm in the situation where I want my development environment to be swarm, so I can perform configuration/secret sharing and various other swarm only features without manual hacking being required by the local developer, thus keeping the production and development environment consistent, which is supposed to be one of the main selling points of Docker. |
Seeing same issue, just trying to up a local haproxy on DfW in single node swarm. Funny thing is when I inspect the service I see the right path: "Mounts": [
{
"Type": "bind",
"Source": "/host_mnt/c/Workspace/devops/Services/haproxy/etc",
"Target": "/usr/local/etc/haproxy",
"ReadOnly": true
}
], But on the container it's a windows path: "Mounts": [
{
"Type": "bind",
"Source": "C:\\Workspace\\devops\\Services\\haproxy\\etc",
"Target": "/usr/local/etc/haproxy",
"ReadOnly": true
}
], The yaml: version: "3"
services:
haproxy:
image: haproxy:alpine
ports:
- 80:80
- 443:443
- 25:25
volumes:
- .\etc:/usr/local/etc/haproxy:ro I tried all kinds of paths, windows paths, linux paths, path in the moby box. None of them actually work. I get what stack does and what it's intended for but IMO there's no reason that this shouldn't just work. |
Same issue on windows server 2019, plus docker desktop, plus swarm, plus linux containers.
There are 2 nodes in the swarm, both windows server 2019. The manager is in windows container mode when I created the swarm. The worker is in linux container mode, when I joined it to the swarm. |
@dazinator If the daemon is running on wsl2, you probably need to access the drive through some |
I have just rebuilt 2 x fresh windows 10 vm's on Azure, using latest docker CE install with WSL2 backend to create a simple swarm, and I have the same issue. What follows is more information about the setup, along with all the different variations of path formats I tried and the error for each VM'sOS: Windows (Windows 10 21h1-pro)
Installed docker desktop - using wsl2 backend. The swarm was then initialised on VM 1 by:-
VM 2, which has docker desktop still running in "linux container" mode, was then joined to the swarm successfully, after making sure windows firewall ports were open on both machines. Failed attemptsI am running the following steps on the manager node to try to deploy a compose file to the swarm that uses a readily available linux container, and tries to mount a file from the host into it. With each attempt, I repeat the following:-
Here is the
Here is a summary of all the values I have tried for the source path along with the errors.
OutcomeCan anyone please explain if what I am trying to do is supported, and if so, what the working |
@thaJeztah |
Description
When running a Docker Swarm cluster on a
docker-machine
created VirtualBox VM, using Windows 7 as the Docker client OS, I have issues when using bind mounts in adocker-compose.yml
file that is being consumed bydocker stack deploy -c docker-compose.yml <service_name>
.What happens is that the relative path name for the bind mount defined in the
docker-compose.yml
file is not properly modified so that the VirtualBox boot2docker VM can map it to a shared volume. Instead, it looks like a standard Windows path which can't be handled.If I feed this same
docker-compose.yml
file intodocker-compose
, it handles the path translation for me and the bind mount works fine.Steps to reproduce the issue:
docker-compose.yml
file with the following contents:mount-me
directory in the same folder as thedocker-compose.yml
file.docker stack deploy --compose-file docker-compose.yml test
Describe the results you received:
Describe the results you expected:
I expected the container to come up like it does with
docker-compose
.Here's a working example using the same
docker-compose.yml
file as was illustrated in the replication steps:Additional information you deem important (e.g. issue happens only occasionally):
The issue is 100% reproducible. If I manually create the service with
docker run
, while specifying the mount path, I have to write it out as/c/Users/joel.gerber/test/mount-me
in order for it to work. I believe the issue is thatdocker stack deploy
, when utilizing the relative path specified in thedocker-compose.yml
file, does not properly modify the path before sending it to the boot2docker Docker daemon. As a result, he cannot load the path, which causes service creation to fail.Output of
docker version
:Output of
docker info
:Additional environment details (AWS, VirtualBox, physical, etc.):
Client OS: Windows 7 Business Edition
Docker OS: boot2docker established with docker-machine running on VirtualBox
The text was updated successfully, but these errors were encountered: