Interpolation of environment variables in `volumes` section

[carletes]

I have something like this in my docker-compose.yml:

services:
    foo:
        volumes:
          - usr-local-${GIT_BRANCH}:/usr/local:ro

volumes:
    usr-local-${GIT_BRANCH}:
        external: true

It seems that docker-compose does not like the interpolated variable in the volumes section:

$ docker-compose ps
ERROR: The Compose file '/Users/.../docker-compose.yml' is invalid because:
volumes value Additional properties are not allowed ('usr-local-${GIT_BRANCH}' was unexpected)
$

I'm running:

$ docker-compose --version
docker-compose version 1.8.1, build 878cff1
$

Is the interpolation of environment variables in the volumes section not supported, or am I doing something wrong in my docker-compose.yml?

[shin-]

This is expected behavior - Compose only does variable interpolation in values, not keys. See Daniel's comment here.

[zeilush]

Will this ever be supported?

[shin-]

@zeilush We haven't yet heard a compelling reason to do so. In 99% of cases, the people that have asked for this feature can achieve what they're trying to do by specifying a different COMPOSE_PROJECT_NAME.

[kknox]

I ran into this issue today, in my attempt to create versioned named volumes. If I build a container with versioned software (a tool like [gcc 5.x] or a library [boost-1.6x]), and I want to import that volume into another container (for build or CI), I would like the named volume to have a unique name, so that I can have multiple versions of that tool or library live side-by-side.

Docker-compose allows yml authors to give containers unique names with .container_name, which has a value and therefore can use environment variable substitution. Perhaps the [volumes] service could allow a .volume_name attribute such that the yml author could assign unique volume name values with a .env file.

[shin-]

@kknox You can use the

external:
  name: myvolume-${VERSION}

structure: https://docs.docker.com/compose/compose-file/#external-1

[kknox]

I think that doesn't work (I tried it yesterday); docker-compose expects the container to already exist and complains. I build my container/named-volumes with docker-compose build <service>

[glensc]

How about changing volumes syntax so the name is value, not key. the declaration looked weird in first place, never seen foo: {} declaration before.

in v2.0:

volumes:
  myapp_${ENV}_db: {external: true}
  myapp_${ENV}_source: {external: true}
  myapp_nginx_socks: {external: true}

my proposal for 2.1:

volumes:
 db:
   name: myapp_${ENV}_db
   external: false
 source:
   name: myapp_${ENV}_source
   external: false
 nginx:
   name: myapp_nginx_socks
   external: true

and in .yml the "db", "source", "nginx" are used when referring to volume. the actual name can be whatever, and is used to name volume in docker. not used when referecing volume from services.

[dnephin]

That doesn't really match what we do for other things. Both services and networks work the same way as volumes do in 2.0.

The key is a local identifier. Compose uses the local identifier and adds the project name to keep them unique. An explicit name is only used when you need to re-use some external volume.

I don't think your example of the 2.0 config is correct. It would be this:

volumes:
  db:
    external:
      name: myapp_${ENV}_db
...

[DavidAntliff]

Is there a known workaround to this issue to date? I have the names of externally created volumes passed to docker-compose as environment variables and I don't see a way to refer to them with docker-compose v3.x syntax.

EDIT: I've found a syntax that seems to work with v3.5, for anyone else coming across this:

volumes:
  db:
    name: ${VOLUME_NAME}
    external: true

services:
  myservice:
    volumes:
      - db:/path