SSM sendet Befehl an die EC2-Instance Fehlgeschlagen

8

Ich versuche, mit boto3 ssh-Befehle auf EC2-Instanzen auszuführen. Ich habe diesen Leitfaden gelesen: Ссылка und ich habe alles von dem gemacht, was sie dort geschrieben haben, aber ich bekomme eine Fehlermeldung:

%Vor%

Ausgabe:

%Vor%

Wenn ich versuche, Befehl mit awscli zu senden, bekomme ich das gleiche Problem:

%Vor%

jemand weiß, wie man es löst?

    
Udi Goldberg 16.02.2017, 16:46
quelle

2 Antworten

7

Dies kann passieren, wenn Sie keinen SSM-Agenten haben installiert auf der Instanz, auf die Sie zugreifen möchten. Führen Sie für eine Liste von Instanzen, in denen Sie SSM-Befehle ausführen können, aus:

%Vor%

Von dort können Sie eine Instanz-ID abrufen und dann den Befehl send_command mit dieser Instanz ausführen.

    
Brady Dowling 22.02.2017, 00:54
quelle
2

Wie in hier in der AWS-Fehlerbehebungsleitfaden dokumentiert, gibt es eine Reihe von mögliche Ursachen für diesen Fehler.

Die akzeptierte Antwort aws ssm describe-instance-information sucht nach Instanzen, die beide in einem gültigen Zustand verfügbar sind und auf denen der SSM-Agent installiert ist, sodass mehrere Schritte zur Fehlerbehebung in einer Zeile (nett;)) behandelt werden.

Wenn Sie boto3 verwenden, kann dasselbe mit:

erreicht werden %Vor%

Ich bin mir nicht sicher, ob es Berechtigungen prüft, aber nehme an. Wenn Ihre instance_id in der Liste fehlt, können Sie die korrekten Berechtigungen sicherstellen, indem Sie Schritt für Schritt hier .

Allerdings gibt es noch eine andere Ursache (zuletzt aber definitiv nicht zuletzt , da es nicht offensichtlich ist):

Neu erstellte Instanzen benötigen etwas Zeit, um in der describe_instance_information -Liste angezeigt zu werden .

Dies ist selbst nach dem Warten , dass die Instanz die Nacherstellung abgeschlossen hat. So zum Beispiel:

%Vor%

Hervorhebung dieses Problems (falls vorhanden - es war sicherlich für mich).

Dies kann aufgrund der Zeit sein, die zur Ausführung des UserData-Skripts benötigt wird (siehe dieser SO-Post für eine möglicherweise zusammenhängende Diskussion über das Warten auf den Abschluss von Benutzerdaten ), aber ich kann es nicht sagen (ohne mehr Aufwand, als ich will zu nehmen!), ob es das ist, oder nur die Zeit in AWS, die seine Dienstdatenbank aktualisiert.

Um dies zu lösen, schrieb ich einen kurzen Kellner (mit einer Zeitüberschreitungsausnahme, um andere Fehlermodi zu behandeln), der wiederholt describe_instance_information () anrief, bis die Instanz-ID in der Liste auftauchte.

    
thclark 09.08.2017 13:28
quelle