Containers-roadmap: ecs mounts volumes as bind

[FernandoMiguel]

my userdata

echo "XXX.efs.eu-west-1.amazonaws.com:/ /var/lib/docker/volumes nfs4 vers=4.1,defaults 0 0" >> /etc/fstab
mount -a && docker volume create --label OVPN_DATA OVPN_DATA

my task definition

  volume {
    name      = "OVPN_DATA"
  }

```
"mountPoints": [
{
"containerPath": "/etc/openvpn",
"sourceVolume": "OVPN_DATA"
}

if I run from the EC2 host 
`docker run -v OVPN_DATA:/etc/openvpn -d -p 443:1194/tcp --cap-add=NET_ADMIN kylemanna/openvpn`
docker inspect shows
  ```
      "Mounts": [
            {
                "Type": "volume",
                "Name": "OVPN_DATA",
                "Source": "/var/lib/docker/volumes/OVPN_DATA/_data",
                "Destination": "/etc/openvpn",
                "Driver": "local",
                "Mode": "z",
                "RW": true,
                "Propagation": ""
            }
        ],

but when running from ECS

        "Mounts": [
            {
                "Type": "bind",
                "Source": "/var/lib/docker/volumes/OVPN_DATA/_data",
                "Destination": "/etc/openvpn",
                "Mode": "",
                "RW": true,
                "Propagation": "rprivate"
            }
        ],

it mounts the volume as BIND
Documentation https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_data_volumes.html doesnt really help here

[jahkeup]

Hi @FernandoMiguel, unfortunately using unmanaged volumes in an ECS Task definition isn't a supported configuration. This persistent storage scenario is one we'd certainly consider facilitating in the future though. If you would elaborate on your use-case we can take that feedback and track this issue as a feature request. In the meantime you can work around this limitation by mounting the NFS share elsewhere on the host and use that path to mount the desired directory into your containers.

[mixja]

One problem with the bind mount is that it sets root permissions on the underlying volume, making it harder to manage applications that run as non-root.

With volume mounts you can have this defined in a Dockerfile:

# Create public volume
RUN mkdir /public
RUN chown app:app /public
VOLUME /public

And if you use a volume mount for this volume, assuming the application is running as user "app" in the example above, it will have ownership on that volume and be able to read/write data.

Having bind mounts means you have to pre-create a path that will be mapped to the volume on the underlying Docker Engine with the correct permissions. This requires you to create a user with same UID/GID as your containers, and orchestrate creation of the path. This mixes container concerns with Docker Engine concerns which is difficult to manage and really violates many of the principles of what Docker is trying to achieve.