Separar directorios de aplicaciones con puntos de acceso

Introducción

Dos aplicaciones necesitan almacenamiento compartido, pero cada una debe trabajar en su propio directorio. Configura puntos de acceso EFS con una raíz y una identidad POSIX específicas para cada montaje y observa archivos y propietarios reales.

Completa primero Compartir archivos entre servidores de aplicaciones con EFS. Esta VM independiente proporciona nuevos servidores y una subred; no reutiliza el sistema anterior. Usa Terminal para AWS CLI y SSH y AWS View para comparar respuestas. No necesitas una cuenta AWS personal.

Relación con certificaciones

Esquema conceptual; consulta los identificadores de tu nuevo entorno.

Preparar un sistema compartido y una conexión NFS

En este paso, crea el almacenamiento y el punto de conexión restringido de ambas aplicaciones.

Trabaja en /home/labex/project e identifica la red preparada. AWS CLI ya está configurada:

cd /home/labex/project
aws sts \
  get-caller-identity
SUBNET_ID=$(jq -r .subnet_id resources.json)
APP_GROUP_ID=$(jq -r .application_group_id resources.json)
VPC_ID=$(jq -r .vpc_id resources.json)
echo "$SUBNET_ID"
echo "$APP_GROUP_ID"
echo "$VPC_ID"

Crea un nuevo sistema EFS. Las aplicaciones usarán el mismo recurso, mientras que sus puntos de acceso seleccionarán directorios distintos:

FS_ID=$(aws efs \
  create-file-system \
  --creation-token fs02-application-files \
  --encrypted \
  --tags Key=Name,Value=fs02-application-files \
  --query FileSystemId --output text)
echo "$FS_ID"

Crea un grupo de almacenamiento dedicado:

EFS_GROUP_ID=$(aws ec2 \
  create-security-group \
  --group-name fs02-efs-access \
  --description 'NFS for the upload application servers' \
  --vpc-id "$VPC_ID" \
  --query GroupId --output text)
echo "$EFS_GROUP_ID"

Permite TCP 2049 desde el grupo de aplicaciones. Esta regla permite conexiones NFS; no elige el directorio ni la identidad de una aplicación:

aws ec2 \
  authorize-security-group-ingress \
  --group-id "$EFS_GROUP_ID" \
  --ip-permissions "IpProtocol=tcp,FromPort=2049,ToPort=2049,UserIdGroupPairs=[{GroupId=$APP_GROUP_ID}]"

Crea el destino de montaje en la subred preparada:

MOUNT_TARGET_ID=$(aws efs \
  create-mount-target \
  --file-system-id "$FS_ID" \
  --subnet-id "$SUBNET_ID" \
  --security-groups "$EFS_GROUP_ID" \
  --query MountTargetId --output text)
echo "$MOUNT_TARGET_ID"

Inspecciona los estados y espera a que ambos recursos estén available:

aws efs \
  describe-file-systems \
  --file-system-id "$FS_ID" \
  --query 'FileSystems[].{ID:FileSystemId,State:LifeCycleState}'
aws efs \
  describe-mount-targets \
  --file-system-id "$FS_ID" \
  --query 'MountTargets[].{ID:MountTargetId,IP:IpAddress,State:LifeCycleState}'

Crear puntos de acceso para cada aplicación

En este paso, define la raíz y la identidad de archivos de cada montaje.

Un punto de acceso es una entrada a EFS específica para una aplicación. Su raíz se convierte en / dentro del montaje y su usuario POSIX sustituye la identidad de las operaciones del cliente. POSIX identifica usuarios con un UID numérico y grupos con un GID.

Crea el punto de acceso de A:

AP_A_ID=$(aws efs \
  create-access-point \
  --file-system-id "$FS_ID" \
  --posix-user Uid=2001,Gid=2001 \
  --root-directory 'Path=/app-a,CreationInfo={OwnerUid=2001,OwnerGid=2001,Permissions=700}' \
  --tags Key=Name,Value=fs02-app-a \
  --query AccessPointId --output text)
echo "$AP_A_ID"

Si /app-a no existe, CreationInfo proporciona propietario y permisos. 700 da al propietario lectura, escritura y recorrido del directorio y no concede esos permisos a otros usuarios. El UID/GID del punto coincide con el propietario.

Crea otro punto con distinta raíz e identidad:

AP_B_ID=$(aws efs \
  create-access-point \
  --file-system-id "$FS_ID" \
  --posix-user Uid=2002,Gid=2002 \
  --root-directory 'Path=/app-b,CreationInfo={OwnerUid=2002,OwnerGid=2002,Permissions=700}' \
  --tags Key=Name,Value=fs02-app-b \
  --query AccessPointId --output text)
echo "$AP_B_ID"

Inspecciona ambas definiciones:

aws efs \
  describe-access-points \
  --file-system-id "$FS_ID" \
  --query 'AccessPoints[].{ID:AccessPointId,Root:RootDirectory.Path,User:PosixUser,Creation:RootDirectory.CreationInfo}'

Las raíces son /app-a y /app-b, con identidades 2001:2001 y 2002:2002. La siguiente etapa prueba el comportamiento real; la configuración por sí sola no demuestra el límite.

El punto restringe la raíz y la identidad del montaje que lo selecciona. Por sí solo no impide que un cliente autorizado elija otro punto. En producción, IAM y las políticas del sistema pueden limitar los puntos permitidos. Aquí se estudian directorios y comportamiento POSIX.

Observar directorios separados y propietarios impuestos

En este paso, monta ambos puntos y demuestra que nombres idénticos corresponden a archivos diferentes.

Monta el punto de A en A. Los montajes con punto de acceso requieren TLS:

ssh -F ssh_config application-a \
  "sudo mkdir -p /srv/shared && sudo mount -t efs -o tls,stunnel,lookupcache=positive,accesspoint=${AP_A_ID} ${FS_ID}:/ /srv/shared"

lookupcache=positive vuelve a consultar nombres antes ausentes cuando otra aplicación crea un archivo. Esto hace observable la práctica breve; ajustar la caché en producción exige evaluar rendimiento por separado. Consulta las opciones de caché NFS de Linux.

Monta el punto de B en B:

ssh -F ssh_config application-b \
  "sudo mkdir -p /srv/shared && sudo mount -t efs -o tls,stunnel,lookupcache=positive,accesspoint=${AP_B_ID} ${FS_ID}:/ /srv/shared"

Ambos usan /srv/shared, pero en A representa /app-a y en B representa /app-b. Configura cada aplicación para usar directamente la raíz de su punto:

ssh -F ssh_config application-a \
  'printf "{\"upload_directory\":\"/srv/shared\"}\n" | sudo tee /etc/uploads-app/config.json'
ssh -F ssh_config application-b \
  'printf "{\"upload_directory\":\"/srv/shared\"}\n" | sudo tee /etc/uploads-app/config.json'

Escribe private.txt mediante A e intenta leerlo mediante B:

curl -i -X PUT --data-binary 'Private upload for application A' \
  http://127.0.0.1:8081/uploads/private.txt
curl -i http://127.0.0.1:8082/uploads/private.txt

A devuelve 201 Created y B 404 Not Found. Crea ahora el archivo propio de B con el mismo nombre:

curl -i -X PUT --data-binary 'Private upload for application B' \
  http://127.0.0.1:8082/uploads/private.txt
curl -i http://127.0.0.1:8081/uploads/private.txt
curl -i http://127.0.0.1:8082/uploads/private.txt

A conserva su contenido y B devuelve el suyo. Usa private.txt y Read upload en ambas tarjetas de AWS View.

Inspecciona los montajes y las identidades reales:

ssh -F ssh_config application-a 'findmnt -t nfs4 /srv/shared; stat -c "%i %u:%g" /srv/shared/private.txt'
ssh -F ssh_config application-b 'findmnt -t nfs4 /srv/shared; stat -c "%i %u:%g" /srv/shared/private.txt'

Los inodes son distintos y los propietarios son 2001:2001 y 2002:2002. La aplicación se ejecuta como labex, pero el servidor aplica la identidad del punto.

Incluso una escritura de root mediante el montaje de A usa esa identidad:

ssh -F ssh_config application-a \
  'printf "Access-point identity also applies to root callers\n" | sudo tee /srv/shared/root-caller.txt; stat -c "%u:%g" /srv/shared/root-caller.txt'

El propietario es 2001:2001. EFS aplica identidades numéricas sin necesitar cuentas locales llamadas 2001 y 2002.

El montaje de A expone /app-a, no toda la raíz EFS. El directorio hermano de B no es un subdirectorio del montaje de A:

ssh -F ssh_config application-a 'ls -a /srv/shared'
ssh -F ssh_config application-a 'cat /srv/shared/app-b/private.txt'

El último comando devuelve No such file or directory, aunque B puede leer su archivo existente. Las raíces montadas independientemente y los contenidos distintos demuestran separación. Acceder a .. desde el punto local lleva al directorio padre local, no al directorio hermano de EFS.

El mismo nombre tiene contenidos distintos en dos raíces. Los identificadores varían entre entornos.

Eliminar puntos de acceso y almacenamiento

En este paso, libera los montajes y elimina solo tus recursos de almacenamiento.

Restaura los directorios locales antes de desmontar:

ssh -F ssh_config application-a \
  'printf "{\"upload_directory\":\"/srv/uploads\"}\n" | sudo tee /etc/uploads-app/config.json'
ssh -F ssh_config application-b \
  'printf "{\"upload_directory\":\"/srv/uploads\"}\n" | sudo tee /etc/uploads-app/config.json'
ssh -F ssh_config application-a 'sudo umount /srv/shared'
ssh -F ssh_config application-b 'sudo umount /srv/shared'

Elimina los dos puntos y confirma que no queda ninguno en el sistema:

aws efs \
  delete-access-point \
  --access-point-id "$AP_A_ID"
aws efs \
  delete-access-point \
  --access-point-id "$AP_B_ID"
aws efs \
  describe-access-points \
  --file-system-id "$FS_ID"

AccessPoints debe estar vacío. Eliminar un punto borra su definición, no los archivos de su directorio. Ahora se elimina todo este sistema desechable y sus datos:

aws efs \
  delete-mount-target \
  --mount-target-id "$MOUNT_TARGET_ID"
aws efs \
  describe-mount-targets \
  --file-system-id "$FS_ID"

Espera a que MountTargets esté vacío antes de continuar:

aws efs \
  delete-file-system \
  --file-system-id "$FS_ID"
aws ec2 \
  delete-security-group \
  --group-id "$EFS_GROUP_ID"

Confirma respuestas exitosas y vacías para tus recursos con nombre:

aws efs \
  describe-file-systems \
  --query 'FileSystems[?Name==`fs02-application-files`].FileSystemId'
aws ec2 \
  describe-security-groups \
  --filters Name=group-name,Values=fs02-efs-access \
  --query 'SecurityGroups[].GroupId'

Ambas consultas devuelven listas vacías. Conserva servidores, grupos y subred preparados y ejecuta la comprobación.

Resumen

Usaste dos puntos de acceso para seleccionar raíces e identidades POSIX distintas en un mismo EFS. Los nombres idénticos contenían datos diferentes y el servidor impuso la propiedad incluso a clientes root. Después desmontaste y eliminaste los puntos, el destino y el sistema desechable.

La conectividad de red, la selección del montaje y los permisos de directorio son capas distintas. La siguiente práctica las usa para diagnosticar una conexión EFS.

Para ampliar este tema, consulta la referencia de AWS: Raíces, identidades y alcance de autorización de puntos de acceso.