Open FernandoMiguel opened 6 years ago
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.
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.
my userdata
my task definition
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 showsbut when running from ECS
it mounts the volume as BIND Documentation https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_data_volumes.html doesnt really help here