Amazon EMR - Yum Update Boostrap Aktion schlägt auf Slave

Question

Gehen Sie diese Frage umschreiben, weil ich eine Menge aktualisierter Informationen erhalten habe.

Mein Problem ist wie folgt:

Ich habe einen EMR-Cluster mit 1 Master-Knoten und 1 Slave-Knoten. Der Slave-Knoten ist so konfiguriert, dass er ungehindert auf das offene Internet zugreifen kann (ich weiß, dass dies ein Sicherheitsrisiko darstellt).

Wenn ich ein Setup dieses Cluster mit einer Bootstrap-Aktion, die einfach sudo yum -y update nennt, schlägt es, zu sagen, dass die Bootstrap-Aktion auf dem Slave-Knoten ausgefallen (es gelingt immer auf Master)

Wenn jedoch SSH in den Slave-Knoten und manuell versuchen, sudo yum -y update auszuführen, ist der Vorgang erfolgreich auf dem 5.5 EMR-Paket.

Ich bin nicht in der Lage, weiter zu debuggen, warum dies passiert, weil EMR, nach meiner besten Kenntnis, es richtig konfiguriert hat, keine Protokolle zu S3 kopiert (das Protokollkopieren ist bestenfalls sporadisch) und CloudWatch nimmt keine auf Logs von der VPC, was das Debuggen dieses Problems ziemlich unklar macht.

Alle Informationen wären willkommen.

Edit: Ich konnte meine CloudWatch VPC Logs funktionieren (anscheinend hatte meine IAM nicht die Trust-Beziehung zum Hochladen von Protokollen), und es zeigt eine Menge von REJECTs, während der Master-Knoten scheint nicht zu zeigen irgendwelche Ablehnungen. Was lässt mich vermuten, dass es eine Autokonfiguration gibt, die mich daran hindert, Yum-Pakete ordnungsgemäß herunterzuladen?

Answer 1

In der Tradition, obskure Fragen zu stellen und sie selbst zu lösen, lassen Sie mich meine Mitigation teilen.

Es stellt sich heraus Dies ist ein Problem in der EMR-5.5.0 Release-Label. Das Herunterstufen auf EMR-5.3.0 behob meine Skriptprobleme und nun läuft das Skript normal wie erwartet.

Es scheint, als ob die Zeit/Art, in der das Skript ausgeführt wird, in 5.5.0 geändert wurde.