An EFS file system is now one Docker volume, floci-efs-<file system id>,
that every mount of it shares, as on AWS:
- An access point or ECS rootDirectory mounts its folder of that volume
(Docker volume subpath), so a mount of the file system root sees every
access point's files, and Lambda and ECS see each other's. Before, each
access point (Lambda) or root directory (ECS) got its own volume.
- An access point's root directory is created on first use from its
CreationInfo, every missing directory on the path with its owner and
permissions; without CreationInfo a missing root directory is refused.
- A Lambda function runs as the access point's POSIX user and secondary
groups. ECS tasks keep their own user, as on AWS.
- CreateAccessPoint validates RootDirectory.Path, CreationInfo and
PosixUser the way EFS does.
- DeleteFileSystem removes the file system's volume.
Each mount target is now a real EC2 network interface in its subnet, so
its address comes from the subnet's lease table and no instance is handed
it, and a privileged helper container serves the volume over NFSv4.1 at
that address on the VPC's Docker network (kernel nfsd, image built
locally from docker/efs-nfs-server.Dockerfile). A mount target is
creating until its server answers. The embedded DNS server resolves
[zone.]fs-id.efs.region.amazonaws.com to a mount target, so an EC2
instance mounts the file system with AWS's own commands (NFS client or
amazon-efs-utils without tls). Servers come back after a restart, their
addresses re-reserved first. floci.services.efs.nfs-servers turns it off.
Two EC2 fixes this needed:
- DeleteNetworkInterface returns the interface's addresses to the subnet;
they stayed leased until restart, also for ECS awsvpc tasks.
- A VPC whose CIDR is substituted keeps each subnet at its declared
offset inside the substitute range, instead of the next free slice in
declaration order, so the plan and persisted addresses survive a
restart that loads subnets in another order.
Zakaria