Partager des fichiers entre serveurs d’applications avec EFS

Introduction

Une application de téléversement fonctionne sur deux serveurs. Chacun conserve les fichiers sur son disque local : un client peut envoyer un fichier sur un serveur et obtenir « introuvable » sur l’autre. Fournissez une interface de fichiers partagée avec Amazon Elastic File System (EFS).

Terminez d’abord AWS VPC for Beginners et AWS EC2 and EBS for Beginners. Cet environnement indépendant fournit l’application, trois hôtes et leur réseau. Utilisez Terminal pour AWS CLI et SSH, et AWS View pour comparer les réponses réelles. La CLI est configurée : aucun compte AWS personnel ni ressource d’un exercice précédent n’est nécessaire. L’exercice porte sur le partage et la connexion, sans mesurer les performances ou la disponibilité en production.

Lien avec les certifications

Schéma conceptuel ; les identifiants réels figurent dans votre nouvel environnement.

Créer le stockage de l’application

Dans cette étape, observez le problème des fichiers locaux et créez votre système de fichiers partagé.

Travaillez dans /home/labex/project. Confirmez l’identité configurée sans afficher de secrets :

cd /home/labex/project
aws sts \
  get-caller-identity

L’ARN utilisateur se termine par labex-fs01-operator. resources.json contient le sous-réseau et le groupe de sécurité fournis. Chargez leurs identifiants pour utiliser les ressources réelles :

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"
aws ec2 \
  describe-instances \
  --filters Name=tag:Name,Values=application-a,application-b \
  --query 'Reservations[].Instances[].{Name:Tags[?Key==`Name`].Value|[0],IP:PrivateIpAddress,State:State.Name}'

Observez le problème local. HTTP PUT enregistre un fichier et HTTP GET le lit. Ces adresses donnent accès aux serveurs préparés :

curl -i -X PUT --data-binary 'A local upload' \
  http://127.0.0.1:8081/uploads/local-example.txt
curl -i http://127.0.0.1:8082/uploads/local-example.txt

A renvoie 201 Created, B renvoie 404 Not Found : son répertoire local contient d’autres fichiers. Vous pouvez aussi écrire et lire le même nom depuis les deux cartes AWS View.

EFS fournit un système partagé : les applications accèdent aux mêmes fichiers et répertoires avec NFS, le protocole Network File System. Créez d’abord le système. Le jeton identifie la requête de création ; l’étiquette Name facilite l’inspection et le nettoyage. --encrypted active le paramètre de chiffrement au repos du service. Le chiffrement du transport sera configuré au montage.

FS_ID=$(aws efs \
  create-file-system \
  --creation-token fs01-shared-uploads \
  --encrypted \
  --tags Key=Name,Value=fs01-shared-uploads \
  --query FileSystemId --output text)
echo "$FS_ID"
aws efs \
  describe-file-systems \
  --file-system-id "$FS_ID" \
  --query 'FileSystems[].{ID:FileSystemId,State:LifeCycleState,Encrypted:Encrypted}'

Attendez l’état available. La ressource existe, mais les applications ont encore besoin d’une cible accessible et d’un montage réel.

Connecter le système au sous-réseau des applications

Dans cette étape, fournissez un point de connexion NFS accessible et limitez l’accès aux serveurs d’applications.

Une cible de montage fournit un point de connexion réseau dans un sous-réseau. NFS utilise TCP 2049. Créez un groupe dédié et autorisez ce port depuis le groupe des applications fourni. Cette règle inclut les deux serveurs sans ouvrir NFS à toutes les adresses. Le serveur de référence indépendant appartient à un autre groupe et doit rester exclu.

EFS_GROUP_ID=$(aws ec2 \
  create-security-group \
  --group-name fs01-efs-access \
  --description 'NFS from the upload application servers' \
  --vpc-id "$VPC_ID" \
  --query GroupId --output text)
echo "$EFS_GROUP_ID"
aws ec2 \
  authorize-security-group-ingress \
  --group-id "$EFS_GROUP_ID" \
  --ip-permissions "IpProtocol=tcp,FromPort=2049,ToPort=2049,UserIdGroupPairs=[{GroupId=$APP_GROUP_ID}]"

Créez la cible dans le sous-réseau fourni et associez le nouveau groupe :

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"
aws efs \
  describe-mount-targets \
  --file-system-id "$FS_ID" \
  --query 'MountTargets[].{ID:MountTargetId,IP:IpAddress,State:LifeCycleState,AZ:AvailabilityZoneName}'
aws efs \
  describe-mount-target-security-groups \
  --mount-target-id "$MOUNT_TARGET_ID"

Attendez que la cible soit available. Les deux applications sont dans une seule zone de disponibilité ; une cible suffit à cette topologie. En production, prévoyez des cibles dans les zones où se trouvent les clients.

Monter les deux serveurs et observer le partage

Dans cette étape, connectez les applications à EFS et testez des téléversements dans les deux sens.

ssh_config permet de joindre chaque hôte. Un point de montage est le répertoire local permettant d’accéder au système distant. Créez /srv/shared sur les deux hôtes et montez la racine EFS :

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

lookupcache=positive interroge de nouveau le serveur pour les noms auparavant absents lorsqu’une autre application crée un fichier. Les nouveaux téléversements deviennent ainsi visibles pendant cet exercice court. Évaluez séparément les performances avant d’ajuster le cache en production. Consultez les options de cache des répertoires NFS Linux.

-t efs sélectionne l’assistant officiel. tls chiffre la connexion ; stunnel sélectionne son transport TLS pris en charge. ${FS_ID}:/ désigne la racine. Les outils nécessaires sont déjà installés.

Les nouveaux répertoires appartiennent initialement à root. Préparez un sous-répertoire pour l’utilisateur applicatif labex et configurez les deux applications :

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

L’application lit sa configuration à chaque requête, sans redémarrage. Inspectez les montages réels :

ssh -F ssh_config application-a 'findmnt -t nfs4 /srv/shared'
ssh -F ssh_config application-b 'findmnt -t nfs4 /srv/shared'

Les deux hôtes affichent NFS 4 sur /srv/shared. Avec TLS, la source du noyau peut être 127.0.0.1:/ : l’assistant transmet NFS par un tunnel chiffré local.

Envoyez un fichier par A, puis lisez-le par B :

curl -i -X PUT --data-binary 'Shared upload version 1' \
  http://127.0.0.1:8081/uploads/shared.txt
curl -i http://127.0.0.1:8082/uploads/shared.txt

B renvoie 200 OK et Shared upload version 1. Mettez-le à jour par B puis lisez-le par A pour tester le sens inverse :

curl -i -X PUT --data-binary 'Shared upload version 2' \
  http://127.0.0.1:8082/uploads/shared.txt
curl -i http://127.0.0.1:8081/uploads/shared.txt
ssh -F ssh_config application-a 'stat -c "%i %u:%g" /srv/shared/uploads/shared.txt'
ssh -F ssh_config application-b 'stat -c "%i %u:%g" /srv/shared/uploads/shared.txt'

Les deux applications lisent la version 2 et stat indique le même inode. Les montages indépendants donnent accès au même fichier EFS ; les répertoires locaux ne sont ni copiés ni synchronisés. Comparez également le fichier dans AWS View.

Les applications lisent le même fichier mis à jour. Les identifiants varient à chaque nouvel environnement.

Démonter et supprimer votre stockage

Dans cette étape, cessez d’utiliser le répertoire partagé et supprimez uniquement votre stockage.

Avant de supprimer le point de connexion, rétablissez le répertoire local fourni pour chaque application, puis démontez EFS :

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'

Si umount signale un répertoire occupé, quittez les shells utilisant /srv/shared avant de réessayer. Vérifiez la disparition des montages :

ssh -F ssh_config application-a 'findmnt -t nfs4'
ssh -F ssh_config application-b 'findmnt -t nfs4'

Aucun montage NFS ne doit rester. Sans correspondance, findmnt retourne le statut 1 ; c’est attendu ici.

Supprimez la cible de montage, puis le système de fichiers et enfin uniquement votre groupe de stockage dédié :

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

Attendez que MountTargets soit vide avant de poursuivre :

aws efs \
  delete-file-system --file-system-id "$FS_ID"
aws ec2 \
  delete-security-group --group-id "$EFS_GROUP_ID"
aws efs \
  describe-file-systems \
  --query 'FileSystems[?Name==`fs01-shared-uploads`].FileSystemId'
aws ec2 \
  describe-security-groups \
  --filters Name=group-name,Values=fs01-efs-access \
  --query 'SecurityGroups[].GroupId'

Les requêtes doivent retourner deux listes vides. Une requête autorisée réussie prouve la suppression ; une erreur réseau ou d’autorisation ne la prouve pas. Conservez les serveurs fournis, leurs groupes et leur sous-réseau.

Exécutez la vérification pour confirmer le nettoyage et la conservation des ressources préparées. Chaque exercice suivant démarre dans son propre environnement.

Résumé

Vous avez connecté deux applications au même système EFS avec une cible de montage, un accès NFS limité et des montages TLS. Les écritures réciproques et l’identité du fichier ont démontré un partage réel. Vous avez ensuite rétabli les répertoires locaux, démonté les clients et supprimé vos ressources dans l’ordre de dépendance.

Un système partagé ne sépare pas automatiquement les répertoires ni les identités POSIX. Le prochain exercice utilise des points d’accès pour établir ces limites.

Pour approfondir ce sujet, consultez la documentation AWS : Assistant de montage EFS et transport TLS; Règles réseau des clients et cibles de montage.