Terraform-aws-github-runner: Автоматизируйте создание оффлайн раннера

Созданный на 6 февр. 2021  ·  11Комментарии  ·  Источник: philips-labs/terraform-aws-github-runner

Текущий подход требует, чтобы у нас всегда был зарегистрирован автономный раннер. Эти автономные раннеры удаляются github каждые 60 дней. Поэтому было бы удобно автоматизировать процесс, чтобы сохранить 1 автономный бегун, чтобы мы могли вернуться к 0.

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

Зарегистрируйтесь через экземпляр ED2

Используйте тот же механизм, который мы используем для раскрутки бегунов с дополнительной лямбдой, которые выполняют только пользовательские данные до этапа конфигурации. А также убедитесь, что экземпляр ec2 отключен

Обратный процесс конфигурации egineer github

Создайте lamda, использующую HTTP-вызовы github на основе обратного проектирования, см. Https://github.com/actions/runner/issues/558

Запускаем конфиг в лямбде

Создайте лямбда, которая может запускать конфигурацию через слой лямбда

enhancement help wanted

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

@npalm Я выяснил большую часть логики, URL-адресов и т. д., связанных с регистрацией бегуна. Я планирую создать модуль python, чтобы справиться с этим, используя python 3x и запросы. Вероятно, это будет в эти выходные, когда я уйду с работы.

Если вы предпочитаете реализовать его самостоятельно, я могу поделиться своими заметками о процессе, которые я собрал до этого.

Я искренне думаю, что хочу потратить больше времени на отслеживание всего процесса, чтобы он мог фактически вытаскивать и выполнять рабочие процессы, но регистрация нового участника была для меня обязательной.

В основном процесс, который я обнаружил, работает:
Получите токен бегуна через api, используя pat или app creds
Отправьте токен на секретную конечную точку, получите обратно данные json с новой секретной конечной точкой и jwt
Используйте jwt для аутентификации через заголовок носителя auth, используя недавно обнаруженную конечную точку, можно запрашивать существующие «агенты» (как они называются в API), добавлять новых или обновлять существующие.

Очевидно, здесь задействованы дополнительные детали, включая создание ключа RSA и кучу заголовков. Дальше регистрации пока не заглядывал ...

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

@npalm Я выяснил большую часть логики, URL-адресов и т. д., связанных с регистрацией бегуна. Я планирую создать модуль python, чтобы справиться с этим, используя python 3x и запросы. Вероятно, это будет в эти выходные, когда я уйду с работы.

Если вы предпочитаете реализовать его самостоятельно, я могу поделиться своими заметками о процессе, которые я собрал до этого.

Я искренне думаю, что хочу потратить больше времени на отслеживание всего процесса, чтобы он мог фактически вытаскивать и выполнять рабочие процессы, но регистрация нового участника была для меня обязательной.

В основном процесс, который я обнаружил, работает:
Получите токен бегуна через api, используя pat или app creds
Отправьте токен на секретную конечную точку, получите обратно данные json с новой секретной конечной точкой и jwt
Используйте jwt для аутентификации через заголовок носителя auth, используя недавно обнаруженную конечную точку, можно запрашивать существующие «агенты» (как они называются в API), добавлять новых или обновлять существующие.

Очевидно, здесь задействованы дополнительные детали, включая создание ключа RSA и кучу заголовков. Дальше регистрации пока не заглядывал ...

@gertjanmaas Думаю, вам понравится комментарий выше

@ miked63017 дайте мне знать, если вы не

Изменить: не уверен, видели ли вы, но это недавно выпущено для Python: https://github.blog/2020-12-18-learn-about-ghapi-a-new-third-party-python-client-for- the-github-api /

@npalm @mcaulifn вот ссылка, она все еще довольно бета-версия и плохо документирована, но я думаю, мы можем сказать то же самое о API бегунов / действий в целом :-)

https://github.com/miked63017/pyghrunner

@mcaulifn в RE для модуля ghapi выглядит круто, но большинство этих вызовов являются недокументированными частями api и, вероятно, могут быть изменены.

В целом похоже, что это должно работать. Планируете ли вы добавить его в это репо?

@gertjanmaas какое-нибудь мнение?

@npalm @mcaulifn не уверен, есть ли у меня контекст, чтобы добавить его сюда в это репо, я лично работаю в операторе GKE, чтобы сделать то же самое, но полагал, что это может помочь другим поделиться некоторым простым кодом для интеграции с другими проектами. Кажется, это довольно частый запрос на эту функцию. Если вы хотите, чтобы я попробовал добавить сюда через PR, возможно, я могу потратить немного времени на эти выходные.

Я быстро просмотрел код Python, и он, кажется, подтверждает то, что я видел, когда пытался его реконструировать некоторое время назад. Было бы здорово, если бы это можно было реализовать здесь. Устали вручную добавлять оффлайн бегунов: P

@gertjanmaas, где я запускаю (эквивалент) этого кода (в частной библиотеке), мы просто запускаем несколько методов периодически или в ответ на событие и перезаписываем предыдущий «виртуальный бегун». Мы в основном просто используем его как заполнитель, поэтому задания ставятся в очередь, а не завершаются с ошибкой, потому что не существует бегунов с метками. Затем мы смотрим на детали задания и запускаем соответствующий бегун с соответствующими метками по мере необходимости и с флагом --once .

У меня все еще есть планы по дальнейшему исследованию создания полностью настраиваемого бегуна, скорее всего, написанного на python, который затем можно будет встроить в другие места. Просто это еще не было для меня приоритетом.

Как насчет отмены регистрации бегуна?

Офлайн-раннер в основном необходимо воссоздавать каждые 30 дней, чтобы в организации никогда не было 0 бегунов.

Это тоже следует автоматизировать.

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