Hi,
I am trying to get secrets working with a service using Docker for Windows with Windows Containers, my top level compose file (Can add overrides if necessary) below:
version: '3.1'
secrets:
web_connectionstring:
file: .\docker-secrets\web_connectionstring
services:
web:
image: jonjam/web:latest
secrets:
- web_connectionstring
When I build I get the following error:
Cannot create container for service web: invalid volume spec "/run/secrets/web_connectionstring": invalid volume specification: '\run\secrets\web_connectionstring'
Hence my question are secrets supported on Windows Containers? Or am I missing something.
It's still a work in progress on the engine's end: https://github.com/moby/moby/pull/32208
After that, there'll probably be more work needed for docker-compose
to support it, so it might not come simultaneously (but if you deploy with docker stack deploy
instead, it will be available)
cc @dnephin
@shin- Thanks a lot for confirming this 馃憤.
I spent a lot of time today trying to work out what I was doing wrong. As Windows Containers become more mainstream, it might be good idea on docker documentation to state whether a feature is supported with Windows containers.
@shin- I think i am receiving the same error, but it looks (on my end) like the secrets are just not being translated to their unix-y paths.
here's a snippet from docker-compose config
secrets:
clouds.yaml:
file: C:\Users\tim\f5-ansible\devtools\secrets\clouds.yaml
....
secrets:
- source: cloudsyaml
target: clouds.yaml
volumes:
- /c/Users/tim/f5-ansible:/here:rw
version: '3.3'
Note that the volumes are translated fine, just the secrets are not. This is with COMPOSE_CONVERT_WINDOWS_PATHS=1
set.
Am I seeing the same thing that @JonJam is seeing?
Any news on this? @shin / @dnephin
I am also interested in this. I am facing with this issue on Docker Toolbox. :( It is just working fine on docker for windows (as linux containers)
Same issue here.
I spent a lot of time today trying to work out what I was doing wrong. As Windows Containers become more mainstream, it might be good idea on docker documentation to state whether a feature is supported with Windows containers.
@JonJam I would also like a (more useful) runtime notice if a feature is used that is not fully implmented yet. Or perhaps even better: don't release fully implemented features.
@Scofield62 I didn't manage to make secrets work with docker-compose and Docker Toolbox. I think main problem is Docker Toolbox doesn't support docker-compose 3.1 well. And you need 3.1 (3.0 didn't support secrets). I suggest to you to buy Windows Pro on Ebay for 4$.
From what can I share with others:
Secrets works for me on Windows Pro with Docker 18.09.0, build 4d60db4and docker-compose version 1.23.2 BUT only if I cast docker-compose from cmd. From linux subsystem it doesn't work, also doesn't work from windows powershell, where I get error:
ERROR: for <service> Cannot start service <service>: error while creating mount source path '/host_mnt/c/.../.secrets/mysecret.json': mkdir /host_mnt/c: file exists
Once part with secret is removed from my docker-compose, it works everywhere.
@shin- I think i am receiving the same error, but it looks (on my end) like the secrets are just not being translated to their unix-y paths.
here's a snippet from
docker-compose config
secrets: clouds.yaml: file: C:\Users\tim\f5-ansible\devtools\secrets\clouds.yaml .... secrets: - source: cloudsyaml target: clouds.yaml volumes: - /c/Users/tim/f5-ansible:/here:rw version: '3.3'
Note that the volumes are translated fine, just the secrets are not. This is with
COMPOSE_CONVERT_WINDOWS_PATHS=1
set.Am I seeing the same thing that @JonJam is seeing?
I have a fix for the secrets path conversion. I still might have to use the env variable COMPOSE_CONVERT_WINDOWS_PATHS so compose doesn't convert paths when using windows containers but its working for linux containers, which was my problem.
Fix: #6595
Is there any work around available that docker compose 3.5 secrets work with docker toolbox 19.03.1 on Windows 8?
I see the same issue as @JonJam mentioned.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically closed because it had not recent activity during the stale period.
Most helpful comment
I am also interested in this. I am facing with this issue on Docker Toolbox. :( It is just working fine on docker for windows (as linux containers)