Allow an environment variable to be used for an array field (e.g. devices:)

[jamshid]

Not sure what the syntax would be exactly, but I would like to supply an optional and variable set of devices to an docker-compose.yml service.

Seems more flexible if the variable is a string and literally substituted, but maybe shell array variables should be used instead.

DEVICES=   # empty set, as a string
DEVICES=()   # or, empty set, as an array?
DEVICES='"/dev/sdb:/dev/sdb", "/dev/sdc:/dev/sdc"'   # as a string
DEVICES=("/dev/sdb:/dev/sdb" "/dev/sdc:/dev/sdc")   # or as an array?

foo:
   devices: [ ${DEVICES} ]   # not sure of the best syntax
   image: ...

It would be great if this syntax allowed "appending" to an existing hard-coded array.

foo:
   volumes: [ "/var/foo", ${EXTRA_VOLUMES} ]   # not sure of the best syntax
   image: ...

Without this feature, I can't use docker-compose directly and instead have to do unnatural things with yml substitution scripts and "docker-compose -f -".

PS: I don't know what's up with docker-compose and Swarm "services" on your roadmap. IMO Compose and the yml service definitions are a really nice way to define both simple and complicated environments.

[dustinschultz]

Relevant Stackoverflow question: https://stackoverflow.com/questions/50919605/docker-compose-variable-substitution-interpolation-with-list-map-or-array-va

[nevmerzhitsky]

Please, implement this. Tuning networks list via orchestration of compose/swarm configs is really terrible.

[WaterYue]

how about the new version, is the new version resolved array environment variable issue ? @dustinlacewell Do you know if there have new solution about this?

[woodongwong]

In some cases, I had to use some flashy operations, just in certain situations.

extra_hosts: [
      "${EXTRA_HOST_0-localhost0:127.0.0.1}", "${EXTRA_HOST_1-localhost1:127.0.0.1}",
      "${EXTRA_HOST_2-localhost2:127.0.0.1}", "${EXTRA_HOST_3-localhost3:127.0.0.1}"
]

EXTRA_HOST_0=server0:10.0.0.10
EXTRA_HOST_1=server1:10.0.0.11

[MaurizioCasciano]

Any news about this issue?
https://stackoverflow.com/questions/72459205/docker-compose-yaml-how-to-populate-single-line-array-from-environment-variable

[ndeloof]

I wonder we could support bash array syntax

  devices: ${DEVICES[*]}

about the .env file format to define an array, using DEVICES =(xxx,yyy) could have some side effect on existing configuration, so I would suggest we require each value to be set:

DEVICES[0]="/dev/sda:/dev/sda"
DEVICES[1]="/dev/sdb:/dev/sdb"
DEVICES[2]="/dev/sdc:/dev/sdc"

we also could rely on bash append operator to distinguish arrays definition with use of parentheses in a regular value:

DEVICES+=("/dev/sda:/dev/sda" "/dev/sdb:/dev/sdb")

[KuzMaxOriginal]

I second this, it would be nice to see that in future versions!

[MiltiadisKoutsokeras]

I just came up with a scenario for this: the Google SQL Auth Proxy requires a list of connection names to corresponding database servers. This could be passed as a single array environment variable and expand on command usage:

services:
  cloud_sql_auth_proxy:
    image: gcr.io/cloud-sql-connectors/cloud-sql-proxy:latest
    platform: linux/amd64
    restart: unless-stopped
    command: ["--unix-socket=/cloudsql", "${SQL_CONNECTIONS[*]}"]
    user: root

[boguszj]

@ndeloof If you're open to it, I could give this a stab, but since it's my first look at the codebases I might be vastly underestimating the issue here. So before I commit to anything, it would be cool to know if I'm at least close with the scope. So if we were to implement your suggestion with bash-like syntax (devices: ${DEVICES[*]}) in it's most basic form, we would need to:

• make changes to the spec (mainly interpolation I suppose?)
• implement the changes in compose-go
  • write some kind of parsing for the new syntax (kinda like the template module)
  • incorporate that parsing in the interpolation module
  • add the test cases in relevant modules (wherever interpolation is used)
• bump the compose-go version & update some docs in the main repo

Am I even close? Or not at all?

[ndeloof]

@boguszj definitely not a "good first issue" to look into.