containers-roadmap icon indicating copy to clipboard operation
containers-roadmap copied to clipboard

Feature request: override mount points for each task

Open dinvlad opened this issue 8 years ago • 15 comments

Hi Team,

Would it be possible to introduce an option to override volume mount path for each task? Right now, we have to register a new task definition just so we could change the mount path on a per-container basis. This introduces additional headache in how to keep track of various definitions, and is also rate limited by the task registration rate.

Our use case is batch processing of various datasets, where the container parameters don't change but the location of the dataset on the local host must be unique for each container/task. E.g. we would have all of our datasets under /datasets/<job_id> on the host, where job_id is unique for each task. One workaround is to pass an environmental variable JOB_ID and have each container read/write to its prefixed location, e.g. if /datasets is mounted to /data in all containers, then each container would gracefully access only /data/<JOB_ID>. However, this provides only minimal isolation of tasks in untrusted environments. I.e. if one task 'misbehaves', it can access everything under /data, including datasets used by other tasks.

It seems like Docker run's -v option maps directly to the containerPath option of a task definition, so is there any reason it cannot be currently overridden for each task, just like environmental variables? We wouldn't even need to change the volume itself, which can remain an immutable part of the task definition.

Thanks

dinvlad avatar Jul 21 '17 06:07 dinvlad

@dinvlad thanks for the suggestion and identifying a use case for it! We are tracking this as a feature request.

jahkeup avatar Aug 07 '17 18:08 jahkeup

Would be nice tho have this feature. I have a similar usecase and need to define separated taskdefinitions for each dataset

tobinski avatar Sep 05 '17 07:09 tobinski

@jahkeup We do have a similar usecase. Please let us know there is some progress in this feature request or if there's a workaround for this.

GitShaffi avatar Jul 26 '18 06:07 GitShaffi

Any update on this @jahkeup - I want to start jupyterlab data-science environments and have each container in its own directory on EFS, so isolating each container like this is really important.

I could register new tasks - but the rate limit of 1/s is too low, any thoughts?

eoinmurray avatar Aug 08 '18 14:08 eoinmurray

Any progress on this case? we have similar use case. We are creating directories in EFS for each task and mount these directories for each fargate container.

jsding avatar Nov 03 '20 00:11 jsding

Same here. It would make it much easier to run CI jobs in isolation. Each job would mount a different directory from EFS.

cutsoy avatar Apr 28 '21 09:04 cutsoy

Same here would be great for our jupyter environment

dzerhusen avatar Jun 18 '21 14:06 dzerhusen

Same here would be great for our jupyter environment

+1 for our Jupyter environment too where we use efs for user volumes

rhlarora84 avatar Jul 13 '21 03:07 rhlarora84

I have a similar case— user data needs to be mapped into an untrusted environment, and the only way to handle this seems to either be to make an unreasonable number of task definitions, or manually run containers on EC2 instances.

What's the likelihood this'll be implemented?

trbabb avatar Aug 21 '21 00:08 trbabb

I have a similar case— user data needs to be mapped into an untrusted environment, and the only way to handle this seems to either be to make an unreasonable number of task definitions, or manually run containers on EC2 instances.

What's the likelihood this'll be implemented?

It has only been 4 years of wait ! Should have been a day 1 thing given the docker -v feature.

rhlarora84 avatar Aug 21 '21 01:08 rhlarora84

I'd do it myself, if I had access to the code! This would save me a ton of trouble.

trbabb avatar Aug 21 '21 01:08 trbabb

I think your best bet is giving more :+1:s to this issue so it gets a higher priority :wink: Otherwise, it's unlikely to be addressed, just considering the sheer number of open issues here and likely limited resources of the AWS team in charge (I'm not blaming them btw, this is inherently hard; just think how teams work in other companies, it's all very similar).

Or, if you are on paid support, another (maybe even better) way is to advocate with them, so you could get a chance to talk to a PM about your use cases. I've had a number of positive interactions this way (but I can't advocate for this issue anymore, since my current employer is not using AWS much; I would, otherwise).

dinvlad avatar Aug 21 '21 02:08 dinvlad

Please prioritize this request, it is enormously useful and naturally maps to docker run -v volume mount options. As already mentioned above, it will resolve tons of pain for us as AWS API users.

sergiy-kozak avatar Sep 24 '21 09:09 sergiy-kozak

A feature request open for half a decade 😑 . Anyone else here who has found a work around?

sagard21 avatar Feb 21 '23 19:02 sagard21

Really needed it for one of our use case, but there's no way I could find out to do this. Please prioritize this.

tremendoustj avatar Apr 24 '24 08:04 tremendoustj