Je vais réécrire cette question parce que j'ai reçu beaucoup d'informations mises à jour.Amazon EMR - Action de Boostrap de mise à jour de Yum échoue sur l'esclave
Ma question est la suivante:
J'ai un cluster DME avec 1 nœud maître et 1 nœud esclave. Le nœud Slave est configuré pour avoir accès à l'Internet ouvert sans entrave (je sais que c'est un risque de sécurité).
Lorsque je configurer ce groupe avec une action d'amorçage qui appelle simplement sudo yum -y update, il échoue, en disant que l'action d'amorçage a échoué sur le noeud esclave (il réussit toujours maître)
Cependant, si SSH dans le nœud esclave et essayez manuellement d'exécuter sudo yum -y update, l'opération réussit sur le package EMR 5.5.0. Je ne parviens pas à déboguer plus loin pourquoi pourquoi cela se produit parce que, malgré ma meilleure connaissance l'ayant configuré correctement, EMR ne copie pas de journaux à S3 (la copie de journal est au mieux sporadique) et CloudWatch ne ramasse aucun journaux à partir du VPC, ce qui rend le débogage de ce problème assez obscur.
Toute information serait appréciée. Edit: J'ai réussi à faire fonctionner mes journaux CloudWatch VPC (apparemment, mon IAM n'avait pas la relation Trust pour télécharger les logs), et il y a beaucoup de REJECTs alors que le nœud principal ne semble pas montrer tout REJET. ce qui me fait présumer qu'il y a une autoconfiguration qui se passe et m'empêche de télécharger correctement les paquets yum?