Open eiximenis opened 5 years ago
Looks like this has the same root-cause as https://github.com/docker/cli/issues/1404. Does this work if you temporarily hardcode the windows path? (not using the ENV-var substitution?)
Hi!
It works if I hardcode a windows path but using Linux Syntax (i. e. /c/tfs/...
). What is curious is that docker-compose config
returns paths in windows syntax even though Linux syntax were used in compose file (and that is what prevents me to use docker-compose config | docker stack deploy -c -
)
I found a solution (the difference is that I am using "docker-app" plugin but if you implement the same solution in your "docker compose" file, I think that it works), you can see it here:
https://github.com/mcadac/docker/blob/master/docker-app/gotemplate/README.md
I'm still running into this problem. My swarm masters are all linux (CentOS) and they have no idea how to deploy to windows nodes if I provide a windows volume bind path like so:
services:
app:
image: app:latest
volumes:
- Z:\hostfolder:C:\containerfolder
It also did not work for me if I changed it to:
services:
app:
image: app:latest
volumes:
- /z/hostfolder:/c/containerfolder
This is pretty discouraging :(
The volumes must be defined the verbose form and it must be the type "bind"
@mcadac Thanks -- just tried that and still no bueno:
services:
app:
image: app:latest
volumes:
- type: bind
source: /z/hostfolder
target: /c/containerfolder
invalid bind mount source, must be an absolute path: /z/hostfolder
What am I missing?
@thaJeztah I saw your merge! Thank you! When can we expect this to get released would you think?
This will likely go out in the August patch release for 18.09, and included in either 19.03.0 or the first patch release for 19.03 (19.03.1). You should be able to download nightly builds of the CLI from download.docker.com later today or tomorrow (not sure at what time "nightly" is built 😂)
Note that the fix will only address the "long" syntax; https://docs.docker.com/compose/compose-file/#long-syntax-3
The shorthand syntax (-v C:\hostpath:C:\container-path
) won't be fixed by that PR; the shorthand syntax is unfortunately quite ambiguous, and fixing that is non-trivial (if possible at all).
@thaJeztah I had another related question to this issue. Will your merge also resolve cross-platform service creation with npipe mount type? For example, I have a linux (centos) manager, and I want to create a service from that manager that only runs on my windows platform nodes:
docker service create --name portainer-agent-win --mode global --mount "type=npipe,source=\\.\pipe\docker_engine,target=\\.\pipe\docker_engine" --constraint 'node.platform.os == windows' --env AGENT_CLUSTER_ADDR=tasks.portainer-agent --network portainer-agent portainer/agent:windows1903-amd64-1.3.0
Using docker 19.03, from a linux manager node, it seems to complain about the mount path:
invalid mount config for type "npipe": invalid mount path: '\.\pipe\docker_engine'
I tried the above mount source/target paths in different ways (//, \, \, ...)
However, running that service create command from a windows manager, works like a charm. I do see that npipe support was added for compose/stack files, but perhaps not allowed in a cross-platform situation: https://github.com/docker/cli/pull/1195
@thaJeztah when you get a chance! Looking for some info on the above. Thank you!
-Drew
@Drewster727 hm.. could it be that if you're running that from a Linux command-line, that the shell treats the \
as an escape character, so
target=\\.\pipe\docker_engine
will be converted to
target=\.\pipe\docker_engine
Trying the following (I don't have a Windows node, but just to test the escaping idea);
docker service create --detach --name=test --mount "type=npipe,source=\\.\pipe\docker_engine,target=\\.\pipe\docker_engine" nginx:alpine
Inspecting the service spec (output formatted with jq
for readability):
docker service inspect --format '{{ json .Spec.TaskTemplate.ContainerSpec.Mounts}}' test
[
{
"Type": "npipe",
"Source": "\\.\\pipe\\docker_engine",
"Target": "\\.\\pipe\\docker_engine"
}
]
Which confirms that both the Source
and Target
path are now invalid; both have a single leading \
(\.\pipe\docker_engine\
)
Changing the command to use either escaping backslashes, or using single quotes make sure that the shell doesn't see the back-slashes as escape characters will prevent that;
Creating the service and escaping the back-slashes (\
-> \\
);
docker service create --detach --name=test --mount "type=npipe,source=\\\\.\\pipe\\docker_engine,target=\\\\.\\pipe\\docker_engine" nginx:alpine
docker service inspect --format '{{ json .Spec.TaskTemplate.ContainerSpec.Mounts}}' test
[
{
"Type": "npipe",
"Source": "\\\\.\\pipe\\docker_engine",
"Target": "\\\\.\\pipe\\docker_engine"
}
]
Single quotes (probably a better solution as it would work both on Windows and Linux shells):
docker service create --detach --name=test --mount 'type=npipe,source=\\.\pipe\docker_engine,target=\\.\pipe\docker_engine' nginx:alpine
docker service inspect --format '{{ json .Spec.TaskTemplate.ContainerSpec.Mounts}}' test
[
{
"Type": "npipe",
"Source": "\\\\.\\pipe\\docker_engine",
"Target": "\\\\.\\pipe\\docker_engine"
}
]
@thaJeztah I'm not sure why I didn't try the double slashes. I thought I had tried it, but that did the trick.
docker service create --name portainer-agent-win --mode global --mount "type=npipe,source=\\\\.\\pipe\\docker_engine,target=\\\\.\\pipe\\docker_engine" --constraint 'node.platform.os == windows' --network portainer-agent -e AGENT_CLUSTER_ADDR=tasks.portainer-agent portainer/agent:windows1903-amd64-1.3.0
Hopefully this helps someone else in the same situation. Thank you! Drew
haha, no worries! I also had to scratch my head a few times before I saw what's happening.
The single quotes are probably a bit easier to use, and might work cross-platform (linux/windows) but haven't tried on a Windows machine
@thaJeztah thanks again for the fix for this, 19.03.2 works like a charm!
Note that the fix will only address the "long" syntax; https://docs.docker.com/compose/compose-file/#long-syntax-3
The shorthand syntax (
-v C:\hostpath:C:\container-path
) won't be fixed by that PR; the shorthand syntax is unfortunately quite ambiguous, and fixing that is non-trivial (if possible at all).
I tried long version, it looks still not working. I am using version 19.03.4, did I config something wrong?
docker stack deploy -c .\test.yml mystack2
Stack.compose.docker.com "mystack2" is invalid: mystack2: Invalid value: "null": conversion to kube entities failed: C:\Users\xxx\Desktop\config\data\mssql: only absolute paths can be specified in mount source
Hey I am facing the same issue now days (docker version 19.03.5)
volumes:
- C:\config:C:\config
Not working! Actually, my service not getting started in the first place some why (normal docker-compose command will start my container!) Anything new with this issue?
@bryht your case looks slightly different, and looks to be related to the Kubernetes conversion. @chris-crone any ideas on that one?
@rong0312 the fix that was made only makes changes to the long-hand syntax, not the shorthand one; https://github.com/docker/cli/issues/1403#issuecomment-510511630
The shorthand syntax (-v C:\hostpath:C:\container-path) won't be fixed by that PR; the shorthand syntax is unfortunately quite ambiguous, and fixing that is non-trivial (if possible at all).
@chris-crone any ideas on that one?
It looks like that error is coming from Compose on Kubernetes: https://github.com/docker/compose-on-kubernetes/blob/master/internal/convert/volumes.go#L49
@silvin-lubecki or @aiordache can you PTAL?
I can't find a proper way to volume my stack's service. I tried to bind & volume in all variations, everything fails to volume. Can someone who succeeded in doing it explain how he has done it?
This problem relates only to 'docker stack deploy', my volume works as normal docker-compose up
@rong0312
docker
docker run --mount "type=bind,source=c:\temp\,target=c:\temp" someimage:latest
docker-compose
version: "3.7"
services:
test:
image: someimage:latest
volumes:
- type: bind
source: C:\temp
target: C:\temp
That help at all?
Finally found out the correct syntax when using Docker Desktop to deploy a stack with the local kubernetes cluster:
/run/desktop/mnt/host/c/Users/bla/bla:/home/bla/bla
as an example if you wanted to bind C:\Users\bla\bla to /home/bla/bla
@justinkb what version of docker (and docker desktop) are you running? IIRC, docker desktop performs some conversion to convert windows paths to the correct (internal) path to use for Docker Desktop (but not sure if that conversion is done when using kubernetes) @djs55 do you know?
Running the latest "stable" channel version
On Sat, May 16, 2020, 2:43 PM Sebastiaan van Stijn notifications@github.com wrote:
@justinkb https://github.com/justinkb what version of docker (and docker desktop) are you running? IIRC, docker desktop performs some conversion to convert windows paths to the correct (internal) path to use for Docker Desktop (but not sure if that conversion is done when using kubernetes) @djs55 https://github.com/djs55 do you know?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/docker/cli/issues/1403#issuecomment-629640047, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABVHKHOAFJVOWCQQ2K4RHTRR2C6HANCNFSM4FYKBFKA .
I believe /run/desktop/mnt/host
is the underlying mount point used in WSL 2 mode.
Docker Desktop uses an API proxy to try to hide some of these differences, but there was a regression in the latest 2.3.0.2 stable which we're attempting to fix. Perhaps try the experimental build mentioned here to see if it helps at all?
Description
I am using Docker CE For Windows (Version 2.0.0.0-beta1-win75 (19925) and using docker stack deploy to deploy a workload against the local k8s cluster.
If I define a volume using "linux like" syntax it works OK:
But If I use windows syntax it fails:
Then I receive on error:
Note that if instead of
c:\tfs\...
I use something like\c\tfs\...
(linux-syntax with no colon but with windows backslashes) I receive another error:This is very unfortunate, because under windows, docker-compose changes the format of Linux paths to windows paths when using "docker-compose config". So, if I have a compose file with one volume:
The output of
docker-compose config
is (linux slashes are converted to backslashes):But this format is not supported by
docker stack deploy
. This prevents me to usedocker-compose config | docker stack deploy -c -
.Output of
docker version
:Output of
docker info
:Additional environment details (AWS, VirtualBox, physical, etc.):