Terraform-aws-github-runner: falha dev-usw2-scale-up: "Falha ao lidar com evento SQS" "Rotinas PEM: get_name: sem linha inicial em Sign.sign"

Criado em 28 jul. 2020  ·  7Comentários  ·  Fonte: philips-labs/terraform-aws-github-runner

Resumo

Resultado da execução dev-usw2-scale-up: falhou

Passos para reproduzir

Acione via commit no aplicativo configurado com o aplicativo github necessário de acordo com docs / README neste repo e https://040code.github.io/2020/05/25/scaling-selfhosted-action-runners

Qual é o comportamento do bug atual?

ERROR Error: error: 0909006C : Rotinas PEM
(veja rastreamento de erro completo / out abaixo)

Qual é o comportamento correto esperado?

O compromisso com o repo configurado causa a execução da função lambda e exige o aumento de escala ou a implantação da instância local do AWS EC2.

Registros e / ou capturas de tela relevantes

A falha / erro mais recente ao confirmar com o repositório github configurado com o aplicativo github configurado para assistir
CloudWatch: CloudWatch Logs: Grupos de log: / aws / lambda / dev-usw2-scale-up
disponível no github gist aqui:

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

Possíveis correções

À primeira vista, parece estar relacionado a um erro de certificado / chave?

Quem pode resolver o problema

Solicitando validação e sugestões de resolução

Outros links / referências

Obrigado

Comentários muito úteis

Obrigado @compiaffe . Parece que são necessárias permissões adicionais que não estão especificadas no README.
Agora não tenho mais erros em nenhum log lambda / cloudwatch, e vejo o arquivo action-runners.zip no intervalo S3, e posso seguir o README e ver a funcionalidade esperada _except_ a criação de instância pontual - que parece ser meu último problema.

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

No caso de você construir, os corredores não estão iniciando ou se registrando. O melhor que você pode fazer é seguir o rastro. No aplicativo GitHub, há uma página de configurações avançadas onde você pode ver os eventos enviados para o webhook. Quando o evento não for aceito, verifique o endpoint e o segredo. Em seguida, você pode verificar os logs do webhook e dimensionar lambda no Cloud Watch. Finalmente, você pode inspecionar o registro de dados do usuário EC2. O acesso via SSM (MP: deve ser ssh?) É habilitado por padrão. Basta selecionar conectar-se à instância e inspecionar o log /var/log/user_data.log.

O ponto de erro é após o lambda e o cloudwatch, e a próxima etapa de solução de problemas é inspecionar os dados do usuário EC2 (logs), mas isso é um pouco difícil, pois não tenho uma instância quando as instâncias pontuais não estão sendo implantadas.

Obrigado pela sua ajuda.

Todos 7 comentários

Eu vi exatamente o mesmo problema se você fizesse uma codificação em base64 da chave PEM SEM o
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----

Parece que você precisa pegar o conteúdo completo do arquivo .pem e codificá-lo em base64.

Obrigado @compiaffe ! isso era definitivamente um problema.

Seria definitivamente útil ter algo assim no 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

Reimplantei e agora vejo o seguinte erro SQS na função de aumento de escala lambda, estou curioso para saber se você já viu 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)"     ] }

Obrigada.

@ cmcconnell1 sim, eu vi em um. Verifique a entrada de registro antes, provavelmente mostrará uma chamada de API para um endpoint do Github respondido com 403.

Eu tive que dar ao aplicativo Github permissões para ações, verificações e corredores auto-hospedados, mas não parece precisar dar a ele acesso à administração.

Não se esqueça de ir para a instalação na organização ou repo e permitir a solicitação de mais / diferentes permissões.

Obrigado @compiaffe . Parece que são necessárias permissões adicionais que não estão especificadas no README.
Agora não tenho mais erros em nenhum log lambda / cloudwatch, e vejo o arquivo action-runners.zip no intervalo S3, e posso seguir o README e ver a funcionalidade esperada _except_ a criação de instância pontual - que parece ser meu último problema.

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

No caso de você construir, os corredores não estão iniciando ou se registrando. O melhor que você pode fazer é seguir o rastro. No aplicativo GitHub, há uma página de configurações avançadas onde você pode ver os eventos enviados para o webhook. Quando o evento não for aceito, verifique o endpoint e o segredo. Em seguida, você pode verificar os logs do webhook e dimensionar lambda no Cloud Watch. Finalmente, você pode inspecionar o registro de dados do usuário EC2. O acesso via SSM (MP: deve ser ssh?) É habilitado por padrão. Basta selecionar conectar-se à instância e inspecionar o log /var/log/user_data.log.

O ponto de erro é após o lambda e o cloudwatch, e a próxima etapa de solução de problemas é inspecionar os dados do usuário EC2 (logs), mas isso é um pouco difícil, pois não tenho uma instância quando as instâncias pontuais não estão sendo implantadas.

Obrigado pela sua ajuda.

Ainda está com problemas?

@npalm nós https://github.com/philips-labs/terraform-aws-github-runner/issues/104, embora não vejamos nenhum erro de permissão. Estou de férias e vejo agora que há uma versão de tag 0.3.0 e 0.4.0 com a qual começarei os testes. Obrigada.

Estou tendo o mesmo problema, usei o build branch / 0.0.5 e também fiz uma codificação base64 (incluindo os bits BEGIN e END) e salvei o valor no arquivo variables.tf abaixo, mas ainda obtendo o erro: . (Erro: erro: 0909006C : Rotinas PEM

image

Esta página foi útil?
0 / 5 - 0 avaliações

Questões relacionadas

mkryva picture mkryva  ·  17Comentários

npalm picture npalm  ·  11Comentários

rjcoupe picture rjcoupe  ·  15Comentários

mcaulifn picture mcaulifn  ·  13Comentários

Kostiantyn-Vorobiov picture Kostiantyn-Vorobiov  ·  6Comentários