Terraform-aws-github-runner: dev-usw2-scale-up failure: "Error al manejar el evento SQS" "Rutinas PEM: get_name: no hay línea de inicio en Sign.sign"

Creado en 28 jul. 2020  ·  7Comentarios  ·  Fuente: philips-labs/terraform-aws-github-runner

Resumen

Resultado de ejecución de dev-usw2-scale-up: fallido

pasos para reproducir

Activar mediante confirmación en la aplicación configurada con la aplicación github requerida según los documentos / README en este repositorio y https://040code.github.io/2020/05/25/scaling-selfhosted-action-runners

¿Cuál es el comportamiento actual de los errores ?

ERROR Error: error: 0909006C : rutinas PEM
(ver el seguimiento completo del error / salida a continuación)

¿Cuál es el comportamiento correcto esperado?

El compromiso con el repositorio configurado provoca la ejecución de la función lambda y el escalado o implementación necesarios de la instancia puntual de AWS EC2.

Registros y / o capturas de pantalla relevantes

La falla / error más reciente al comprometerse con el repositorio de github configurado con la aplicación github configurada para mirar
CloudWatch: CloudWatch Logs: Grupos de registros: / aws / lambda / dev-usw2-scale-up
disponible en github gist aquí:

gist-file-aws-lambda-dev-usw2-scale-up-error

Posibles correcciones

A primera vista, parece que podría estar relacionado con un error de certificado / clave.

Quién puede abordar el problema

Solicitando validación y sugerencias de resolución

Otros enlaces / referencias

Gracias

Comentario más útil

Gracias @compiaffe . Parece que se requieren permisos adicionales que no están especificados en el archivo README.
Ahora no tengo más errores en ningún registro de lambda / cloudwatch, y veo el archivo action-runners.zip en el bucket de S3, y puedo seguir el README y ver la funcionalidad esperada _excepto_ la creación de la instancia puntual, que parece ser mi último problema.

ref: escalado-corredores-de-acción-autohospedados # poniendo-todo-junto

En caso de que construyas, los corredores no están iniciando ni registrándose. Lo mejor que puede hacer es seguir el rastro. En la aplicación GitHub hay una página de configuración avanzada donde puede ver los eventos enviados al webhook. Cuando el evento no sea aceptado, verifique el punto final y el secreto. A continuación, puede verificar los registros del webhook y escalar lambda en Cloud Watch. Por último, puede inspeccionar el registro de datos de usuario de EC2. El acceso a través de SSM (MP: ¿debería ser ssh?) Está habilitado de forma predeterminada. Simplemente seleccione conectarse a la instancia e inspeccione el registro /var/log/user_data.log.

El punto de error es después de lambda y cloudwatch, y el siguiente paso de solución de problemas es inspeccionar los datos de usuario de EC2 (registros), pero esto es un poco difícil porque no tengo una instancia cuando las instancias de spot no se están implementando.

Gracias por su asistencia.

Todos 7 comentarios

Vi exactamente este mismo problema si hiciste una codificación base64 de la clave PEM SIN la
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----

Parece que necesita tomar el contenido completo del archivo .pem y codificarlo en base64.

¡Gracias @compiaffe ! eso fue definitivamente un problema.

Definitivamente sería útil tener algo como esto en el archivo README / docs:

  • 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

He vuelto a implementar y ahora veo el siguiente error de SQS en la función de escalamiento de lambda, '¿es curioso si ha visto este antes?

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)"     ] }

Gracias.

@ cmcconnell1 sí, lo he visto en uno. Verifique la entrada del registro antes, es probable que muestre una llamada API a un punto final de Github respondida con 403.

Tuve que otorgar permisos a la aplicación Github para acciones, comprobaciones y corredores autohospedados, pero parece que no necesito darle acceso a la administración.

No olvide ingresar a la instalación en la organización o repositorio y permitir la solicitud de más / diferentes permisos.

Gracias @compiaffe . Parece que se requieren permisos adicionales que no están especificados en el archivo README.
Ahora no tengo más errores en ningún registro de lambda / cloudwatch, y veo el archivo action-runners.zip en el bucket de S3, y puedo seguir el README y ver la funcionalidad esperada _excepto_ la creación de la instancia puntual, que parece ser mi último problema.

ref: escalado-corredores-de-acción-autohospedados # poniendo-todo-junto

En caso de que construyas, los corredores no están iniciando ni registrándose. Lo mejor que puede hacer es seguir el rastro. En la aplicación GitHub hay una página de configuración avanzada donde puede ver los eventos enviados al webhook. Cuando el evento no sea aceptado, verifique el punto final y el secreto. A continuación, puede verificar los registros del webhook y escalar lambda en Cloud Watch. Por último, puede inspeccionar el registro de datos de usuario de EC2. El acceso a través de SSM (MP: ¿debería ser ssh?) Está habilitado de forma predeterminada. Simplemente seleccione conectarse a la instancia e inspeccione el registro /var/log/user_data.log.

El punto de error es después de lambda y cloudwatch, y el siguiente paso de solución de problemas es inspeccionar los datos de usuario de EC2 (registros), pero esto es un poco difícil porque no tengo una instancia cuando las instancias de spot no se están implementando.

Gracias por su asistencia.

¿Sigues enfrentando un problema?

@npalm superamos esto, me faltaba el inicio / final del certificado. Sin embargo, todavía estamos bloqueados con la etiqueta v0.2.0 sin implementación de las instancias puntuales y sin indicaciones en los registros de errores que indiquen fallas / problemas. AIR, el efecto neto fue el mismo que en https://github.com/philips-labs/terraform-aws-github-runner/issues/104 aunque no vemos ningún error de permiso. He estado de vacaciones y ahora veo que hay una versión de etiqueta 0.3.0 y 0.4.0 con la que comenzaré a probar. Gracias.

Tengo el mismo problema, utilicé la rama de desarrollo / 0.0.5, y también hice una codificación base64 (incluidos los bits BEGIN y END) y guardé el valor en el archivo variables.tf como se muestra a continuación, pero sigo recibiendo el error: . (Error: error: 0909006C : rutinas PEM

image

¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

npalm picture npalm  ·  11Comentarios

mcaulifn picture mcaulifn  ·  13Comentarios

rjcoupe picture rjcoupe  ·  15Comentarios

mkryva picture mkryva  ·  17Comentarios

Kostiantyn-Vorobiov picture Kostiantyn-Vorobiov  ·  6Comentarios