No variable substitution in service names

[AndreSteenveld]

Description

In 2016 there was a bug-report or feature request with the same title as this one. link At the time it wasn't resolved as the issue seemed to be resolved better by using the compose project name. Since then the include element has been added and I think this might be worth reconsidering.

I ran in to this because I'd like to define a few template services so I wrote the following file (shortened for brevity):

# abstract-service.yaml
services:
  "$APP_NAME":
    build: { args: [ "APP_NAME=${APP_NAME}" ] }

# service.env
APP_NAME=fancy

# docker-compose.yaml
include:
  - path: ./abstract-service.yaml
    env_file: ./service.env

services: { }

Then running docker compose config I'd expect something along these lines:

services:
  fancy:
    build: { args : [ "APP_NAME=fancy" ] }

Obviously this doesn't work and throws a rather predictable validating /.../docker-compose-gist/abstract-service.yaml: services Additional property $APP_NAME is not allowed

Gist for convenience: link

[mattwalo32]

Hi Andre,

Correct me if I'm wrong, but it seems like this issue is more related to compose-spec, specifically, compose-spec/compose-go. Under the hood it looks like Docker Compose uses the compose-go library to do all of the parsing of yaml files.

Unless Docker is willing to break the compose-spec to support this feature, it seems like this would need to be taken up with the maintainers of the compose-spec.

[ndeloof]

interpolation indeed only applies to values, not keys in a compose.yaml file maybe we should also support this where a user-defined key is expected (like services sub-elements) to be discussed under compose-spec umbrella