Terraform-aws-github-runner: dev-usw2-scale-up failure: «Не удалось обработать событие SQS» «Подпрограммы PEM: get_name: нет начальной строки в Sign.sign»

Созданный на 28 июл. 2020  ·  7Комментарии  ·  Источник: philips-labs/terraform-aws-github-runner

Резюме

dev-usw2-scale-up Результат выполнения: сбой

Действия по воспроизведению

Запуск через фиксацию в настроенном приложении с необходимым приложением github в соответствии с документами / README в этом репо и https://040code.github.io/2020/05/25/scaling-selfhosted-action-runners

Каково текущее поведение ошибки ?

ОШИБКА Ошибка: ошибка: 0909006C : подпрограммы PEM
(см. полную трассировку ошибок ниже)

Какое ожидаемое правильное поведение?

Фиксация настроенного репо вызывает выполнение лямбда-функции и необходимое масштабирование или развертывание спотового экземпляра AWS EC2.

Соответствующие журналы и / или снимки экрана

Самый последний сбой / ошибка при фиксации настроенного репозитория github с приложением github, настроенным для просмотра
CloudWatch: Журналы CloudWatch: Группы журналов: / aws / lambda / dev-usw2-scale-up
доступно в github gist здесь:

gist-file-aws-lambda-dev-usw2-ошибка масштабирования

Возможные исправления

На первый взгляд кажется, что это может быть связано с ошибкой сертификата / ключа?

Кто может решить проблему

Запрос проверки и предложения по разрешению

Другие ссылки / ссылки

Спасибо

Самый полезный комментарий

Спасибо @compiaffe . Похоже, требуются дополнительные разрешения, которые не указаны в README.
Теперь у меня больше нет ошибок в каких-либо журналах лямбда / облачного наблюдения, и я вижу файл action-runners.zip в корзине S3, и я могу следить за README и видеть ожидаемую функциональность, за исключением создания спотового экземпляра - это похоже, это моя последняя проблема.

ref: scaling-selfhosted-action-runners # собирать все вместе

В случае сборки бегуны не запускаются и не регистрируются. Лучшее, что вы можете сделать, - это следовать по следу. В приложении GitHub есть страница расширенных настроек, где вы можете увидеть события, отправленные на веб-перехватчик. Если событие не принято, дважды проверьте конечную точку и секрет. Затем вы можете проверить журналы на наличие веб-перехватчика и увеличить лямбду в облачных часах. Наконец, вы можете проверить журнал данных пользователя EC2. Доступ через SSM (MP: это должен быть ssh?) По умолчанию включен. Просто выберите подключение к экземпляру и просмотрите журнал /var/log/user_data.log.

Точка ошибки находится после лямбда-выражения и облачного наблюдения, и следующим шагом по устранению неполадок является проверка пользовательских данных EC2 (журналов), но это немного сложно, поскольку у меня нет экземпляра, когда спотовые экземпляры не развертываются.

Спасибо за помощь.

Все 7 Комментарий

Я видел ту же самую проблему, если вы выполняли кодировку base64 ключа PEM БЕЗ
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----

Похоже, вам нужно взять полное содержимое файла .pem и кодировать его в base64.

Спасибо @compiaffe ! это определенно было проблемой.

Было бы определенно полезно иметь что-то подобное в 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

Я повторно развернул и теперь вижу следующую ошибку SQS в функции увеличения масштаба лямбда: «интересно, видели ли вы это раньше?»

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

Спасибо.

@ cmcconnell1 да я видел на одном. Перед тем как проверить запись в журнале, она, скорее всего, покажет API-вызов конечной точки Github, на который был получен ответ 403.

Мне пришлось дать приложению Github разрешения для действий, проверок и автономных запусков, но, похоже, нет необходимости предоставлять ему доступ к администрированию.

Не забудьте войти в установку в организации или репозитории и разрешить запрос дополнительных / разных разрешений.

Спасибо @compiaffe . Похоже, требуются дополнительные разрешения, которые не указаны в README.
Теперь у меня больше нет ошибок в каких-либо журналах лямбда / облачного наблюдения, и я вижу файл action-runners.zip в корзине S3, и я могу следить за README и видеть ожидаемую функциональность, за исключением создания спотового экземпляра - это похоже, это моя последняя проблема.

ref: scaling-selfhosted-action-runners # собирать все вместе

В случае сборки бегуны не запускаются и не регистрируются. Лучшее, что вы можете сделать, - это следовать по следу. В приложении GitHub есть страница расширенных настроек, где вы можете увидеть события, отправленные на веб-перехватчик. Если событие не принято, дважды проверьте конечную точку и секрет. Затем вы можете проверить журналы на наличие веб-перехватчика и увеличить лямбду в облачных часах. Наконец, вы можете проверить журнал данных пользователя EC2. Доступ через SSM (MP: это должен быть ssh?) По умолчанию включен. Просто выберите подключение к экземпляру и просмотрите журнал /var/log/user_data.log.

Точка ошибки находится после лямбда-выражения и облачного наблюдения, и следующим шагом по устранению неполадок является проверка пользовательских данных EC2 (журналов), но это немного сложно, поскольку у меня нет экземпляра, когда спотовые экземпляры не развертываются.

Спасибо за помощь.

По-прежнему сталкиваетесь с проблемой?

@npalm мы прошли через это, мне не хватало начала / конца сертификата. Однако мы по-прежнему заблокированы тегом v0.2.0 без развертывания спотовых экземпляров и без указаний в журналах ошибок, указывающих на сбой / проблему. AIR, чистый эффект был таким же, как и в https://github.com/philips-labs/terraform-aws-github-runner/issues/104, хотя мы не видим никаких ошибок разрешений. Я был в отпуске и теперь вижу, что есть версии тегов 0.3.0 и 0.4.0, с которыми я начну тестирование. Спасибо.

У меня такая же проблема, я использовал ветку разработки / 0.0.5, а также сделал кодировку base64 (включая биты BEGIN и END) и сохранил значение в файле variables.tf, как показано ниже, но все еще получаю ошибку: . (Ошибка: ошибка: 0909006C : процедуры PEM

image

Была ли эта страница полезной?
0 / 5 - 0 рейтинги