Mounting a volume to a target containing a colon (:)

[couling]

Description

Binding a volume into a target path containing a colon (:) appears to be a missing feature. If it is possible then it's not documented. While colons are less common they have always been valid in a *nix path and are a plain old US ASKII character present on (almost?) every keyboard around the world.

There's some discussion in #12553 discussing this as a bug. But what I'm actually stuck with is the apparently missing feature. The workaround discussed in the bug ticket only applies to bind mounts by setting create_host_path. But what I'm looking for is a way to do the same for type: volume.

This is something that is possible via docker itself:

docker volume crete foo
docker run -it --rm --mount type=volume,src=foo,dst=/foo/bar:baz ubuntu

This ought to then be possible via docker compose.

---

As one hard example: I ran into this trying to emulate some google cloud behaviour for local testing. Google Cloud SQL will bind mount a postgres socket file into the container at something like: /cloudsql/bar-baz:europe-west4:foo-db-1234567890.

This simplest way to achieve this should be to mount a single volume into two containers:

• /var/run/postgresl in the postgres container
• /cloudsql/bar-baz:europe-west4:foo-db-1234567890 in the app container

The existence of colons in the path here is non-negotiable. I don't get to chose how google Cloud SQL works, and I do need to test that app code correctly handles connecting to this postgres socket despite the existence of colons in the DSN/URL

[tobiasdam]

nocopy: true of the volume long syntax seems to function as a workaround, if you don't need the behavior of nocopy: false (more info here).

services:
  test:
    image: alpine
    volumes:
      - type: volume
        source: test
        volume:
          nocopy: true
        target: /te:st
    command: tail -f /dev/null
volumes:
  test:

This seems to trigger compose to use the Mount API and works like create_host_path for bind mounts.
Unfortunately, the use of the Bind API and the Mount API are inconsistent and not well documented.

[ndeloof]

For legacy reasons 🥲 compose syntax didn't introduced an explicit mount attribute to match the docker/cli flags, so Compose has to select the engine API (Bind or Mount) to use for service volumes depending on configured option, with preference for Bind as both API are not strictly interchangeable 🤪
The result is that, if you want to explicitly use --mount with compose, you have to use the long syntax with an option that isn't available wit a bind mount

[couling]

@ndeloof Seems a shame that the existance of a colon in the target doesn't count as an "option that isn't available with bind mount".

It might otherwise have been nice to have a simple switch in the long form that lets us chose which API to go via. Is there an intentional seperation between docker's semantics and capabilities and docker compose's?

[ndeloof]

Is there an intentional seperation between docker's semantics and capabilities and docker compose's?

nope, this is all legacy from Docker Swarm to adopt and tweak the compose file format

Seems a shame that the existance of a colon in the target doesn't count as an "option that isn't available with bind mount".

Using Mount API is not equivalent to Bind so this is not a transparent choice. We could adopt this approach, still this could bring more confusion to an already crazy situation we have to deal with.

I wonder we should:

1. introduce an explicit mount section, to better align with docker/cli flag
2. introduce an optional mount attribute on volume for user to opt-in for the mount API

[couling]

Using Mount API is not equivalent to Bind so this is not a transparent choice. We could adopt this approach, still this could bring more confusion to an already crazy situation we have to deal with.

You're right, of course. That could get confusing.

IMHO the second of your two options feels more elegant. The first is perhaps better guarded against (hypothetical) drift between docker mount and volume API in the future.

Perhaps your option 2 could be a three way choice between "auto", "mount", "volume" with default to "auto" for existing behaviour.

The advantage of this over a simple boolean is that it allows users to force the behaviour they intended, even if that was to use "volume" and get a friendly error if their options aren't supported.