Feature: Enable multiple EFS volumes and mount points

[MiroDojkic]

Multiple EFS Volumes and Mount Points Support

This PR adds support for configuring multiple EFS volumes and mount points in the MongoDB and ECS services, along with improved documentation.

Changes

Features

• Added support for configuring multiple EFS volumes and mount points for ECS and Mongo
• Configures a single EFS access point with limited access only to /data
  • this was included to support the best practice of not running containers as root user
  • owner is the first non-root user (POSIX 1000)
  • full access for owner
  • read+execute for others
• Added default persistent storage configuration for Mongo component

Documentation

• Added documentation for persistent storage configuration in README
• Updated Mongo component's persistentStorageConfig parameter documentation

API Changes

Mongo Service

The Mongo service now comes with a default persistent storage configuration. Alternatively, user can provide volumes and mount points with the same config data structure:

persistentStorageConfig: {
  volumes: [{ name: 'mongo' }],
  mountPoints: [{
    sourceVolume: 'mongo',
    containerPath: '/data/db'
  }]
}

[MiroDojkic]

@droguljic I've yet to add examples and some default options, but I wanted to first verify with you if this approach makes sense.

I can see us using multiple volumes and mount points. I assume we'd usually use the same EFS instance in most use cases.
If we ever see a need to use more than one, it should be relatively easy to expose through composition.
To keep the experience relatively seamless, we could expose some predefined configurations that can be passed down.

[droguljic]

@droguljic I've yet to add examples and some default options, but I wanted to first verify with you if this approach makes sense.

I can see us using multiple volumes and mount points. I assume we'd usually use the same EFS instance in most use cases. If we ever see a need to use more than one, it should be relatively easy to expose through composition. To keep the experience relatively seamless, we could expose some predefined configurations that can be passed down.

Makes sense, looks good to me.

[droguljic]

@MiroDojkic

"Configures a single EFS access point with limited access only to /data (full access for owner, read+execute for others) (@droguljic anything else worth mentioning?)"

I would add that owner is first created non-root user, and this was included to support best practice to not run containers as root.

[mbareta]

Should we name these magic numbers? For example const ROOT_USER_ID = 1000;.

[mbareta]

Should we put this in a variable so it has a name? For example READ_PERMISSIONS.

[mbareta]

TIL about ?? operator 😄