Pourquoi ne puis-je pas monter mes volumes Amazon EFS sur mes tâches AWS Fargate ?
Lorsque je monte mes volumes Amazon Elastic File System (Amazon EFS) sur mes tâches AWS Fargate, des erreurs se produisent.
Brève description
Amazon EFS fournit une solution de stockage persistante pour vos tâches Fargate en vue de partager des fichiers et des données entre différentes tâches.
Les problèmes suivants peuvent vous empêcher de monter vos volumes Amazon EFS sur vos tâches Fargate :
- Le système de fichiers Amazon EFS n'est pas configuré correctement.
- Le rôle Gestion des identités et des accès AWS (AWS IAM) pour la tâche Amazon Elastic Container Service (Amazon ECS) ne dispose pas des autorisations requises.
- Certains problèmes sont liés aux configurations du réseau et d'Amazon Virtual Private Cloud (Amazon VPC).
Pour résoudre les erreurs liées aux tâches Amazon Elastic Container Service (Amazon ECS) qui ne démarrent pas, utilisez le runbook AWSSupport-TroubleshootECSTaskFailedToStart. Reportez-vous ensuite aux étapes de dépannage correspondant à votre problème.
Résolution
Trouver la tâche qui n'a pas pu démarrer
Important :
- Utilisez le runbook AWSSupport-TroubleshooTECSTaskFailedToStart dans la même Région AWS où sont situées les ressources de votre cluster ECS.
- Lorsque vous utilisez le runbook, vous devez utiliser également le dernier ID de tâche ayant échoué. Si la tâche ayant échoué fait partie du service Amazon ECS, utilisez la dernière tâche ayant échoué dans le service. La tâche ayant échoué doit être visible dans ECS:DescribeTasks lors de l'exécution de l'automatisation. Par défaut, les tâches ECS arrêtées sont visibles pendant 1 heure après le passage à l'état Arrêté. L'utilisation du dernier identifiant de tâche ayant échoué permet d'éviter que le nettoyage de l'état de la tâche n'interrompe l'analyse durant l'automatisation.
Pour obtenir des instructions sur la façon de lancer le runbook, consultez AWSSupport-TroubleshootECSTaskFailedToStart. En fonction des résultats de l'automatisation, utilisez l'une des étapes de dépannage suivantes.
Résolvez la tâche en fonction du message d'erreur
Lorsque vous essayez de monter le volume EFS sur votre tâche Fargate, l'une des erreurs suivantes peut se produire :
« ResourceInitializationError: échec de l’invocation des commandes utils EFS pour configurer les volumes EFS : stderr: b'mount.nfs4: Connexion expirée : échec de l’exécution de la commande utils EFS utils ; code: 32 »
Ces erreurs s'affichent lorsque votre tâche Fargate ne parvient pas à se connecter au système de fichiers EFS en raison de l’expiration de la connexion. Pour résoudre cette erreur, essayez les étapes de dépannage suivantes :
- Ouvrez la console Amazon EFS.
- Dans le volet de navigation, choisissez Systèmes de fichiers.
- Choisissez le système de fichiers que vous souhaitez vérifier en choisissant son nom ou l'ID du système de fichiers.
- Choisissez Réseau pour afficher la liste des cibles de montage existantes.
- Choisissez Manage (Gérer).
Vous pouvez consulter le groupe de sécurité et les règles entrantes du groupe de sécurité pour les cibles de montage.
Assurez-vous que la règle entrante du groupe de sécurité autorise le trafic en provenance du groupe de sécurité des tâches Fargate sur le port 2049. Vérifiez que le trafic réseau est autorisé au niveau du sous-réseau. Pour ce faire, vérifiez que la liste de contrôle d'accès réseau autorise le trafic entre le système de fichiers et la tâche. Si le trafic n'est pas autorisé, modifiez les règles en conséquence. Pour plus d'informations, consultez la section Sécurité dans Amazon Virtual Private Cloud.
« ResourceInitializationError: échec d’invocation des commandes utils EFS pour configurer les volumes EFS : stderr: mount.nfs4: Réinitialisation de la connexion par un pair : échec de l’exécution de la commande utils EFS ; code : 32 »
Cette erreur s'affiche pour l'une des raisons suivantes :
- Vous avez monté le système de fichiers EFS immédiatement après l'avoir créé.
- Le groupe de sécurité de la cible de montage n'autorise pas le trafic entrant en provenance des tâches Fargate sur le port 2049.
- Vous utilisez AWS App Mesh et le trafic sortant vers le port 2049 est bloqué en raison des règles de proxy.
Pour résoudre cette erreur, procédez comme suit :
- Jusqu'à 90 secondes peuvent s'écouler pour la propagation intégrale des enregistrements DNS dans une région AWS après la création d'une cible de montage. Si vous créez et montez les systèmes de fichiers par programmation, par exemple à l'aide d'un modèle AWS CloudFormation, implémentez une condition d'attente.
- Vérifiez que la règle du groupe de sécurité entrant associée aux cibles de montage du système de fichiers EFS autorise le trafic sur le port 2049 à partir des tâches Fargate.
- Si vous utilisez App Mesh, assurez-vous que la configuration de votre proxy spécifiée dans la TaskDefinition inclut 2049 en tant que egressignoredPorts.
« ResourceInitializationError : échec de l’exécution de la commande utils EFS : stderr : Échec de dépannage "fs-xxxxxxxxxxx.efs.us-east-1.amazonaws.com" - Vérifiez l’exactitude de l’ID de votre système »
Cette erreur s'affiche pour l'une des raisons suivantes :
- La cible de montage du système de fichiers EFS n'est ni créée ni disponible dans une zone de disponibilité où les tâches Fargate sont lancées.
- Vous utilisez un serveur DNS personnalisé dans le VPC.
- Les noms d'hôtes DNS du VPC sont désactivés. Les noms d'hôtes DNS sont désactivés par défaut.
Pour résoudre cette erreur, essayez ce qui suit :
- Assurez-vous que la cible de montage du système de fichiers EFS se trouve dans la même zone de disponibilité que la tâche Fargate. Vous pouvez afficher la zone de disponibilité, le sous-réseau et le groupe de sécurité de la cible de montage dans la console Amazon EFS. Vérifiez ensuite que la cible de montage utilise la même zone de disponibilité et le même sous-réseau que la tâche Fargate.
- Si vous avez spécifié un serveur DNS personnalisé pour les options DHCP de votre VPC au lieu d'AmazonProvidedDNS, veillez à configurer des redirecteurs DNS conditionnels. Les redirecteurs DNS doivent envoyer les requêtes DNS des ressources AWS (*.amazonaws.com) au serveur DNS par défaut du VPC à l'adresse VPC CIDR .2 ou 169.254.169.253. Pour en savoir plus, consultez la sectionComment configurer la résolution DNS entre les réseaux sur site et AWS à l'aide d'AWS Directory Service et de Microsoft Active Directory.
« ResourceInitializationError : échec de l’exécution de la commande utils EFS : stderr : b'mount.nfs4: accès refusé par le serveur lors du montage 127.0.0.1:/' : échec d’exécution de la commande utils EFS ; code : 32 »
Cette erreur s'affiche lorsque les politiques et autorisations suivantes interdisent l'accès au système de fichiers :
- La politique du système de fichiers
- La politique des rôles des tâches
- Les autorisations au niveau du système de fichiers POSIX
L'accès à un système de fichiers EFS peut être contrôlé par des autorisations définies dans les ressources suivantes :
- La liste de contrôle d'accès au réseau
- Groupes de sécurité
- Politiques du système de fichiers EFS
- Politique IAM du rôle des tâches ECS
- Un fichier POSIX
Pour plus d'informations, consultez la sectionGuide du développeur sur l'utilisation d'Amazon EFS avec Amazon ECS et AWS Fargate — Partie 2.
Pour résoudre cette erreur, vérifiez si la politique du système de fichiers ou la politique IAM du rôle de tâche ECS refuse l'accès au système de fichiers. Si ces politiques refusent des autorisations, modifiez-les pour accorder des autorisations d'accès au système de fichiers. Si la politique du système de fichiers n'existe pas, alors l'accès au système de fichiers est accordé par défaut à tous les administrateurs lors de la création.
Informations connexes
Création de systèmes de fichiers Amazon EFS
Création et gestion des cibles de montage et groupes de sécurité
Le montage du système de fichiers échoue immédiatement après la création du système de fichiers
Contenus pertinents
- demandé il y a 2 anslg...
- demandé il y a 2 anslg...
- demandé il y a 2 moislg...
- demandé il y a un anlg...
- Réponse acceptéedemandé il y a un moislg...
- AWS OFFICIELA mis à jour il y a 5 mois
- AWS OFFICIELA mis à jour il y a 2 ans
- AWS OFFICIELA mis à jour il y a 6 mois
- AWS OFFICIELA mis à jour il y a 7 mois