Resultado de ejecución de dev-usw2-scale-up: fallido
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
ERROR Error: error: 0909006C : rutinas PEM
(ver el seguimiento completo del error / salida a continuación)
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.
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
A primera vista, parece que podría estar relacionado con un error de certificado / clave.
Solicitando validación y sugerencias de resolución
Gracias
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
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
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.