-
Notifications
You must be signed in to change notification settings - Fork 321
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Fargate] [Volumes]: Allow at least EFS mounts to Fargate Containers #53
Comments
ECS now allows for volumes to be mounted at task level, not host only.. |
@FernandoMiguel : Does that mean that EFS is now supported by Fargate? |
Thanks everyone for this request. It would really be awesome if you could give us a little more detail about your need for this feature: For example, which workloads / applications that require EFS would you want to deploy on ECS? Would also love to hear about any potential use-cases or interests in using the newly released FSx file system. |
We'd very much like to see support for EFS in fargate. I imagine there's a multitude of applications - the one we have is that we (Idealstack) are doing website hosting in ECS, and want to support common PHP-based web apps such as wordpress, drupal, peoples custom PHP code etc. These typically require shared storage if you want to cluster them and autoscale, and don't support S3 in general. So for instance the AWS reference architecture for wordpress, magento or drupal all use EFS But I would imagine in any situation where users want persistant storage wth unix filesystem semantics EFS is going to be helpful, particularly where you are moving existing apps into fargate. There's a lot of frustration on the internet over the lack of EFS support in fargate dating to when it was first released. FSx filesystems aren't something we use, but would probably also have similar applications, as would EBS support. Something similar to the new volume driver support for (non-fargate) ECS would be great, even if only certain AWS-managed drivers that supported a few common targets such as EFS, EBS and/or FSx were supported With EFS in fargate we could support more effective autoscaling of these kinds of apps compared to EC2-based architectures (since a container can boot in seconds versus minutes to create an instance and add a container instance in ECS). This would be a killer feature for our product. Lack of EFS support stops us from supporting Fargate at the moment though. |
adding to @jonathonsim -there are quite some open-source services that are not built cloud-native:
Many of those tools just need a persistent storage for minimal writes. |
As original author, I'll give you some my use-cases:
The counter-pressure on why NOT to use ECS: That escape-hatch becomes an opportunity for hard-work-creep. Opens up new AMIs, custom Linuxes, host drivers, firewalls, authentication, and more. It's too much opportunity opened up only to give someone the ability to mount stage storage so their wordpress plugin can generate code on the fly. |
Our use case would be mounting a volume read-only which contains static data (in our case the reference genome) instead of having to put this data in the image or download it from S3 every time we start a container. |
This would be extremely helpful. We have a task that we'd like to run in Fargate that currently involves pulling around 30GB of data in from S3 each time it runs; we can do this in EC2 or on ECS containers, but it would save us a ton of headaches if we could load it directly into a Fargate volume. |
Yes, this would be awesome! Even this AWS whitepaper on WordPress "best practices" in the "stateless web tier" references using EFS to store plugin files https://d1.awsstatic.com/whitepapers/wordpress-best-practices-on-aws.pdf Exactly what we are trying to achieve with Fargate. This would allow [plugin/cms] updates to happen on the fly [by WP admins]. |
That is actually something that you don't want because than you don't hava atomic deployment. But EFS in fargate does have use cases. For example shared file cache for compiled templates. |
What we need is for WordPress admins to be able to add plugins on their own. Even the whitepaper suggests this in a "stateless web tier". |
+1 here, we've been waiting for this feature since Fargate was launched. We have lots of applications with a high ratio of connections waiting to be migrated into Fargate to make use of autoscaling feature but we need to be able to mount the same EFS to these services in order to share some information between containers |
That feature isn't supported currently by Fargate. In addition @abby-fuller IMHO it should be labelled as Fargate. |
Having EFS + fargate would allow me to skim off 5-6 minutes of my deployments. It would also provide extra flexibility/agility for adjusting configs during triage time. I could deploy to the EFS mount with the ability of instant upgrades/rollbacks through something like deployer rather than needing to build a new docker image + deploying that to an ASG/Cluster with hardcoded configs built into them and wait for the replace action to occur in cloud formation. |
Our use cases involve running stateful workloads, such as cluster state (software requires file systems), custom databases, and CloudFoundry migration -- for workloads requiring file systems. Would love this feature, though we are looking at a more mature EKS as well. |
Hi, I'd like to ask if there is an ETA for this. Fargate is one of the platforms that we are looking into for migrating our service and NFS/EFS support is a very important feature that our service uses; and knowing the ETA will be very helpful for planning our schedule. Thanks. |
It would be really helpful to know more about EFS/NFS volume mounting on containers running on Fargate, and if this is going to be implemented in the near future. I am currently looking for a solution to connect jupyterhub to fargate. For data scientists to save their notebooks in their jupyter instance (running in the container), we need to mount a volume. So they can continue their work the next time they log in. Other options would need us to keep a large EC2 instance running all the time. This would cost a lot for every new user. |
I'm doing something very similar with RStudio... |
AWS says they are working on EFS support for ECS with Fargate, if I may believe this post: https://forums.aws.amazon.com/thread.jspa?messageID=816397&tstart=0 |
this feature would allow for rehosting of existing applications with minimal effort. Desperately required! |
I would like to operate a FTPS/SFTP server with scalable/durable storage. |
Do we have any ETA for that?? |
We really need this feature. ECS at EC2 is a headache - autoscaling groups, cloudinit, mount directory to host, mount to task... Awful. |
@teamfighter awful? was 4 lines of code for efs, and another 4 for the task definition |
@FernandoMiguel I didnt told that it's impossible. I told that it is uncomfortable solution. |
Has anyone tried to mount an s3 bucket inside a container running on fargate with s3fs? This may be a (temporary) solution to persist files to s3. I am currently using s3fs to mount/share files between ec2 instances, and it works like a charm! |
pretty PLEASE don't use s3fs.... S3 is object storage... trying to treat it as persistent storage is a terrible idea @juultje123 |
Excellent news, thanks for the update. |
Amazing work.After a long time. Happy to hear |
Thank you @coultn! Been waiting for this one for a while. |
Great news! |
@coultn After reading the blog post, it suggests that this support is for ECS-only workloads, to cover both EC2 and Fargate launch types. No mention is made of Fargate workloads in EKS. So, I'm assuming that's out of scope for this release? If so, that's fine. Just trying to clarify because I also see the EKS label on this issue and the issue was closed. |
Great! Is there a corresponding item to follow for CloudFormation support? |
You are correct in your assumption @mikesir87. We are working to enable this scenario for EKS. Stay tuned. |
Opened an issue for CloudFormation support |
Is there an issue that we can follow for that support @mreferre? |
Amazing that EFS got to be supported, what about EBS? 😢 @coultn |
Is this possible to configure with CloudFormation? |
@synth not yet but we are working on getting that support shipped asap. We do know it is in high demand. Stay tuned. |
good news! this's what we're looking for to migrate some of our existing stateful workload to Fargate |
Have been trying to find a way to get this working and only now found this thread. Now it makes sense why it has been failing for me from CloudFormation. Eagerly awaiting this feature in CloudFormation |
@mreferre Is there an ETA for Cloudformation support of EFS for Fargate? We are eagerly waiting for that feature |
@uherberg we are actively working on it. I don't have more details to share at this time. Stay tuned. We will update this post when CloudFormation support is introduced. Thanks for your patient. |
are we able to use EFS mounts from other accounts? we have a pair of VPCs peered and mounting the EFS share cross-account works on ec2 (after fixing DNS by specifying the IP of the mount in /etc/hosts), but for Fargate we're only passing the mount name. |
@hlarsen this won't work because of DNS resolution. It would work with a shared VPC among the two accounts though but not with two separate VPCs. Can you open a new GH issue with this specific request so that we can track it? Thanks. |
Has CloudFormation support been introduced? I'm thinking about including the EFS resource in the template to be able to reference its id in the TaskDefinition |
Yes, it was. I was able to successfully use it.
ср, 3 лют. 2021, 13:22 користувач Stefano <[email protected]> пише:
… @mreferre <https://github.com/mreferre> Is there an ETA for
Cloudformation support of EFS for Fargate? We are eagerly waiting for that
feature
@uherberg <https://github.com/uherberg> we are actively working on it. I
don't have more details to share at this time. Stay tuned. We will update
this post when CloudFormation support is introduced. Thanks for your
patient.
Has CloudFormation support been introduced? I'm thinking about including
the EFS resource in the template to be able to reference its id in the
TaskDefinition
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#53 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAA2N5ZSU35GCYGWPRBJGS3S5EWXNANCNFSM4GKCYBVQ>
.
|
Yes. I apologize, I committed to update the thread when we announced support and I didn't. Sorry. Here for the official announcement: https://aws.amazon.com/about-aws/whats-new/2020/08/amazon-ecs-announces-cloudformation-support-for-amazon-efs-volumes/ |
No problem at all @mreferre ! Attempting right now, hopefully as successful as @diraven Getting Here's the relevant parts of the template:
|
I don't have a working example handy so it's hard for me to see what could be wrong. Do you have the other parts of the CFN template out on purpose? ( |
Thanks for you reply. Included the The error shows up in the Do you maybe have a working example of a template? |
There are other parts to check (such as the security groups). I am not great at debugging CFN templates this way. I have a few suggestions that may put you on the right track.
To generate the corresponding CFN template from the compose file you just run |
Tell us about your request
Allow mounting of at least EFS volumes (if nothing more generic or extensible) onto Fargate tasks.
Which service(s) is this request for?
Fargate
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
We're in en-masse plans to migrate to Fargate. We're 100% in agreement with having stateless containers talking to stable external storage over the network (S3, DynamoDB). We'll do it sooner or later. You won't lose business without this.
This is an empathetic ask - if we could mount at LEAST EFS volumes to support those external workloads (stuff we don't build, but rather download), then it allows a large life-and-shift to Fargate, getting rid of Docker for AWS and ECS and gives us one consistent team-wide technology to consume, while we the factor out those dependencies cleanly.
Are you currently working around this issue?
We use Docker Swarm using the old DFA CloudFormation stack. Looked into ECS before volume plugins were supported and just the 2-3 level steps was awful (create volume, mount on host, remember where it is on host, launch task, mount directory to volume, mount volume to container.)
The text was updated successfully, but these errors were encountered: