moby: templated volume name syntax not supported in compose v3 format?
Description
Trying to play with the new templating features in 1.13, I wanted to template a volume name in a docker-compose.yml
file for deployment with docker stack deploy
. I got an undefined volume
error, however.
Steps to reproduce the issue:
- Create a v3
docker-compose.yml
file:
version: '3.1'
services:
redis:
image: redis
volumes:
- "redisVol-{{.Task.Slot}}:/data"
volumes:
redisVol-1:
driver: local
- Attempt to deploy this:
$ docker stack deploy -c docker-compose.yml redis
undefined volume: redisVol-{{.Task.Slot}}
Describe the results you received:
An error: undefined volume: redisVol-{{.Task.Slot}}
Describe the results you expected:
Expected the volume reference to match š
Additional information you deem important (e.g. issue happens only occasionally):
Output of docker version
:
Client:
Version: 1.13.1-rc1
API version: 1.25
Go version: go1.7.4
Git commit: 2527cfc
Built: Sat Jan 28 00:43:00 2017
OS/Arch: darwin/amd64
Server:
Version: 1.13.1-rc1
API version: 1.25 (minimum version 1.12)
Go version: go1.7.4
Git commit: 2527cfc
Built: Sat Jan 28 00:43:00 2017
OS/Arch: linux/amd64
Experimental: true
Output of docker info
:
Containers: 32
Running: 7
Paused: 0
Stopped: 25
Images: 250
Server Version: 1.13.1-rc1
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Swarm: active
NodeID: pxwtehg7hjvgrzd7z1yhwrna8
Is Manager: true
ClusterID: xerj566k9hqteqrznvkyg3z6f
Managers: 1
Nodes: 1
Orchestration:
Task History Retention Limit: 5
Raft:
Snapshot Interval: 10000
Number of Old Snapshots to Retain: 0
Heartbeat Tick: 1
Election Tick: 3
Dispatcher:
Heartbeat Period: 5 seconds
CA Configuration:
Expiry Duration: 3 months
Node Address: 192.168.65.2
Manager Addresses:
192.168.65.2:2377
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 03e5862ec0d8d3b3f750e19fca3ee367e13c090e
runc version: 2f7393a47307a16f8cee44a37b262e8b81021e3e
init version: 949e6fa
Security Options:
seccomp
Profile: default
Kernel Version: 4.9.6-moby
Operating System: Alpine Linux v3.5
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 1.952 GiB
Name: moby
ID: 72VG:JFL4:ITTA:T6HT:HZ6S:3XKE:ASDY:YB3S:32EF:FQJS:AVHS:HFQQ
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
File Descriptors: 90
Goroutines: 199
System Time: 2017-02-06T20:13:35.084216266Z
EventsListeners: 2
No Proxy: *.local, 169.254/16
Username: hairyhenderson
Registry: https://index.docker.io/v1/
Experimental: true
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Additional environment details (AWS, VirtualBox, physical, etc.):
Docker for Mac Version 1.13.1-rc1-beta40 (15241)
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 5
- Comments: 19 (8 by maintainers)
Ok, did a little more playing around and this seems to work (though TBH feels a little far from ideal):
This is at least workable for now.
thanks @dnephin.
This doesnāt work:
BUT! This works!
I didnāt realize external volumes would be created automatically, but I guess that makes sense.
Scaling works too:
š
This is really needed for scalable stateful docker āservicesā Each task in a service should be able to specify its own persistent volume.
Since this is already supported by the docker service command line using templates for volumes, there should be some way to specify it via the docker compose YML file as well.(when deployed using docker stack deploy)
From the ādocker for azureā docs - https://docs.docker.com/docker-for-azure/persistent-data-volumes/#use-a-unique-volume-per-task
There is currently no way to achieve this via docker stack deploy using the compose YML file. As pointed out in the discussion it is possible to use ālocalā volume and bind mounts but not custom volume drivers like rexray/ebd or cloudstor:aws etc. Looks like a bug to me.
This works with bind mounts which is useful for people using NFS/etc:
The older bind mount syntax also works. (unlike volume-name in this issue)
ex:
Docker 20.10 finally gave us hostnames that resolve.
So deployments like this, that used to require 4 services, are now almost possible :-
@hairyhenderson I cannot find any documentation regarding this feature. Can you clarify how you came across this?
I was about to close this, but then I realized that this causes a problem if I want to deploy the stack multiple times with different stack names (because the volume is
external
).I suppose for this to work as expected itād have to be possible to set the name of the volume separately from the key:
Iād then expect a volume to be created named
<stack name>_redisVol-1
(obviously, this doesnāt work)
@chrisbecke Great! When you say almost possible, what is still missing? I havenāt tried this in a while, but you should be able to combine the volume definitions into one (disk1ā¦disk4 to just disk) if you put the
{{.Task.Slot}}
into the volume name there.command
should also support it.When using
external
, the volume is expected to be created up-front (āexternalā). Having.Task.Slot
in the template for an external volume wonāt work, because that information is not available for a global āvolumeā definition, but only for a ātaskā that uses the volume.The volume name under
services
in a Compose file is not the actual volume name. Itās a reference to a volume defined in the top levelvolumes
section of the Compose file.It might work if you add:
Otherwise you might have to use external volumes: