Terraform-aws-github-runner: dev-usw2-scale-up failure: "Fehler bei der Behandlung des SQS-Ereignisses" "PEM-Routinen:get_name:no start line at Sign.sign"

Ich habe genau das gleiche Problem gesehen, wenn Sie eine Base64-Kodierung des PEM-Schlüssels OHNE die gemacht haben
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----

Es scheint, dass Sie den vollständigen Inhalt der .pem-Datei nehmen und diesen mit base64 codieren müssen.

Danke @compiaffe ! das war definitiv ein Thema.

Es wäre auf jeden Fall hilfreich, so etwas in der README/docs zu haben:

• GITHUB_KEY=$(base64 ./myapp-aws-github-runner.2020-07-29.private-key.pem) ; cat $GITHUB_KEY > encoded_key.out now use this entire file as the github_app_key_base64 value

Ich habe neu bereitgestellt und sehe jetzt den folgenden SQS-Fehler in der Lambda-Scale-Up-Funktion: „Werden Sie neugierig, ob Sie diesen schon einmal gesehen haben?

2020-07-29T12:38:43.476-07:00 | 2020-07-29T19:38:43.476Z    e67a6201-6e39-50c8-94f7-359abc4954cd    ERROR   Invoke Error    {     "errorType": "Error",     "errorMessage": "Failed handling SQS event",     "stack": [         "Error: Failed handling SQS event",         "    at _homogeneousError (/var/runtime/CallbackContext.js:12:12)",         "    at postError (/var/runtime/CallbackContext.js:29:54)",         "    at callback (/var/runtime/CallbackContext.js:41:7)",         "    at /var/runtime/CallbackContext.js:104:16",         "    at /var/task/index.js:17333:16",         "    at Generator.throw (<anonymous>)",         "    at rejected (/var/task/index.js:17315:65)",         "    at processTicksAndRejections (internal/process/task_queues.js:97:5)"     ] }

Dankeschön.

@cmcconnell1 ja, ich habe bei einem gesehen. Überprüfen Sie vorher den Log-Eintrag, es wird wahrscheinlich ein API-Aufruf an einen Github-Endpunkt angezeigt, der mit 403 beantwortet wird.

Ich musste der Github-App Berechtigungen für Aktionen, Prüfungen und selbst gehostete Runner erteilen, aber anscheinend muss ich ihr keinen Zugriff auf die Verwaltung gewähren.

Vergessen Sie nicht, in die Installation in der Organisation oder im Repository einzusteigen und die Anforderung weiterer/anderer Berechtigungen zuzulassen.

Danke @compiaffe . Anscheinend sind zusätzliche Berechtigungen erforderlich, die nicht in der README-Datei angegeben sind.
Ich habe jetzt keine Fehler mehr in Lambda/Cloudwatch-Protokollen und sehe die Datei action-runners.zip im S3-Bucket und kann der README-Datei folgen und die erwartete Funktionalität sehen, _außer_ der Spot-Instanzerstellung - das scheint mein letztes Problem zu sein.

ref: skalierung-selfhosted-action-runners#putting-all-together

Falls Sie Läufer bauen, starten oder registrieren sich nicht. Das Beste, was Sie tun können, ist, der Spur zu folgen. In der GitHub-App gibt es eine Seite mit erweiterten Einstellungen, auf der Sie die an den Webhook gesendeten Ereignisse sehen können. Wenn das Ereignis nicht akzeptiert wird, überprüfen Sie den Endpunkt und das Geheimnis. Als Nächstes können Sie die Protokolle für den Webhook überprüfen und Lambda in Cloud Watch hochskalieren. Schließlich können Sie die EC2-Benutzerdatenprotokollierung einsehen. Der Zugriff über SSM (MP: soll das ssh sein?) ist standardmäßig aktiviert. Wählen Sie einfach Verbindung mit der Instanz herstellen und überprüfen Sie das Protokoll /var/log/user_data.log.

Der Fehlerpunkt liegt nach Lambda und Cloudwatch, und der nächste Schritt zur Fehlerbehebung besteht darin, die EC2-Benutzerdaten (Protokolle) zu überprüfen. Dies ist jedoch etwas schwierig, da ich keine Instanz habe, in der die Spot-Instanzen nicht bereitgestellt werden.

Vielen Dank für Ihre Hilfe.

Stehen Sie immer noch vor einem Problem?

@npalm wir haben das überstanden Ich habe den Anfang / das Ende des Zertifikats verpasst. Wir sind jedoch immer noch mit dem v0.2.0-Tag blockiert, ohne dass die Spot-Instanzen bereitgestellt werden und in den Fehlerprotokollen keine Hinweise auf Fehler/Probleme enthalten sind. AIR, der Nettoeffekt war der gleiche wie in https://github.com/philips-labs/terraform-aws-github-runner/issues/104, obwohl wir keine Berechtigungsfehler sehen. Ich war im Urlaub und sehe jetzt, dass es eine 0.3.0- und 0.4.0-Tag-Version gibt, mit der ich anfangen werde zu testen. Dankeschön.

Ich habe das gleiche Problem, ich habe den Entwicklungszweig / 0.0.5 verwendet und auch eine base64-Kodierung (einschließlich der BEGIN- und END-Bits) durchgeführt und den Wert in der Datei variables.tf wie unten gespeichert, aber immer noch die Fehlermeldung: . (Fehler: error:090906C :PEM routines:get_name :no start line at Sign.sign (internal/crypto/sig.js:105:29)) und direkt danach ERROR Invoke Error {"errorType":"Error"," errorMessage":"Behandeln des SQS-Ereignisses fehlgeschlagen"