Skip to content
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

Allow multiple volumes with managed EFS for a single service #2921

Open
efekarakus opened this issue Oct 14, 2021 · 4 comments
Open

Allow multiple volumes with managed EFS for a single service #2921

efekarakus opened this issue Oct 14, 2021 · 4 comments
Labels
size/M We should be able to deliver roughly 1 medium issue in a sprint. type/feature Issues that are new feature requests. type/request Issues that are created by customers.

Comments

@efekarakus
Copy link
Contributor

We should enable more than one storage.volumes with managed EFS for a single service.

Ask

Original ask: #1559 (comment)

Today users are limited to a single EFS access point per service:

storage:
  volumes:
    frontend:
      efs:
        uid: 123
        gid: 123
      path: /var/data

If they try to use the same EFS filesystem for multiple volumes like this:

storage:
  volumes:
    v1:
      efs:
        uid: 123
        gid: 123
      path: /etc/mount1
    v2:
      efs:
        uid: 456
        gid: 456
      path: /etc/mount2

We return the following error:

validate "storage": cannot specify more than one managed volume per service

Programming model

  1. In order to support multiple access points for a single service we need to transform the following resource into a list:
    {{- if .Storage.ManagedVolumeInfo}}
    AccessPoint:
  2. We need to assign a new RootDirectory.Path for the additional access points. Today, we hard-code it to the service name like "frontend". The proposal is to do <svcName>-<volumeName>.
    RootDirectory:
    Path: !Sub '/{{.Storage.ManagedVolumeInfo.DirName}}'
  3. Update the IAM policy in the TaskRole to grant access to multiple access points:
    {{- if .Storage.ManagedVolumeInfo}}
    - PolicyName: 'GrantAccessCopilotManagedEFS'
    PolicyDocument:
@efekarakus efekarakus added type/feature Issues that are new feature requests. type/request Issues that are created by customers. size/M We should be able to deliver roughly 1 medium issue in a sprint. labels Oct 14, 2021
@FraserThompson
Copy link

Just in case this helps prioritize this... Multiple access points is essential for running CMSs like Drupal (probably others) which save user files in multiple locations. For example:

Public filesystem in /opt/drupal/web/sites/default/files
Private fileystem /opt/drupal/private

A single access point couldn't meet this use case. It's possible with externally managed filesystems, but having all this managed by Copilot would be much more convenient.

@efekarakus
Copy link
Contributor Author

Hi @FraserThompson ! out of curiosity wouldn't this scenario be satisfied with:

storage:
  volumes:
    frontend:
      efs: true
      path: /opt/drupal

Or am I misunderstanding a step?

@FraserThompson
Copy link

Hi @efekarakus ! This would work to persist files, yes, but as far as I can tell it would go against best practices.

The other contents of /opt/drupal come from the Docker image and should only exist in ephemeral storage because they're not stateful. The only stateful data is contained in those two directories.

Ideally you could put all files you want persisted into one directory and make that an EFS volume, but Drupal doesn't offer full control over where these files can be.

Also there are other factors, like we might want to share just the public files with an NGINX sidecar so it can serve static assets. We might have another sidecar running Solr for search, and this will also need to persist the search index somewhere. I don't think it would make sense for all of these to persist their data to the same place.

For reference the AWS example for Drupal on ECS uses one filesystem with multiple access points for each directory they want to persist. Unless I'm misunderstanding something (which is entirely possible) I don't think we can do this right now with Copilot.

@hardeepjethwani
Copy link

We should enable more than one storage.volumes with managed EFS for a single service.

Ask

Original ask: #1559 (comment)

Today users are limited to a single EFS access point per service:

storage:
  volumes:
    frontend:
      efs:
        uid: 123
        gid: 123
      path: /var/data

If they try to use the same EFS filesystem for multiple volumes like this:

storage:
  volumes:
    v1:
      efs:
        uid: 123
        gid: 123
      path: /etc/mount1
    v2:
      efs:
        uid: 456
        gid: 456
      path: /etc/mount2

We return the following error:

validate "storage": cannot specify more than one managed volume per service

Programming model

  1. In order to support multiple access points for a single service we need to transform the following resource into a list:
    {{- if .Storage.ManagedVolumeInfo}}
    AccessPoint:
  2. We need to assign a new RootDirectory.Path for the additional access points. Today, we hard-code it to the service name like "frontend". The proposal is to do <svcName>-<volumeName>.
    RootDirectory:
    Path: !Sub '/{{.Storage.ManagedVolumeInfo.DirName}}'
  3. Update the IAM policy in the TaskRole to grant access to multiple access points:
    {{- if .Storage.ManagedVolumeInfo}}
    - PolicyName: 'GrantAccessCopilotManagedEFS'
    PolicyDocument:

Hi @efekarakus , Do we have any update on this issue resolution?

mergify bot pushed a commit that referenced this issue Jan 23, 2024
…ice (#5631)

This is the easiest possible fix for the issue, we got an internal ticket requesting a fix for this so I wanted to get a basic fix out for review first and iterate if this causes issues.

Related #2921 



By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the Apache 2.0 License.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
size/M We should be able to deliver roughly 1 medium issue in a sprint. type/feature Issues that are new feature requests. type/request Issues that are created by customers.
Projects
None yet
Development

No branches or pull requests

3 participants