JIT runner とは？ジャストインタイムの runner 登録

JIT（just-in-time）runner は、boot の直前に生成された使い捨ての登録設定で起動されるため、runner はちょうど 1 つの job を拾って、その後消えることができます。

GitHub は ephemeral runner 向けに作られた just-in-time 登録フローをサポートしています。再利用可能な registration token の代わりに、単一の runner に紐づいた 1 回限りの設定を生成します。これは autoscale される使い捨てのマシンに理想的です。

2 つの登録モデル

従来の登録は registration token を使って runner をリポジトリや組織に追加し、長寿命の runner でしばしば再利用されます。JIT 登録は、1 回実行されて削除される特定の runner のために 1 回限りの設定を生成し、クリーンアップすべき残留登録がありません。

なぜ JIT が ephemeral runner に適しているのか

設定が使い捨てであるため、マシンが破棄されたときに古い runner 登録が残りません。これにより runner のリストがクリーンに保たれ、オフラインの「ゴースト」runner が GitHub の UI に蓄積するのを防ぎます。

セキュリティの観点

JIT 設定はスコープが限定され短命であるため、漏洩した設定は、任意の runner を登録できる長寿命の registration token よりもはるかに危険性が低いです。使い捨ての認証情報は、より小さい影響範囲です。

JIT と cold start

JIT 登録は cold start の経路です。設定を生成し、インスタンスを起動し、登録し、実行します。オーバーフローには JIT を、通常のケースには warm pool を組み合わせることで、毎回 cold start を払うことなくクリーンな使い捨て runner が得られます。

マネージド runner の JIT

マネージドプラットフォームは内部で JIT 登録を使い、各 ephemeral runner が 1 つの job のためにクリーンに登録され、何も残しません。Latchkey ではこれは自動です - 自分で設定を生成したり古い登録をクリーンアップしたりすることは決してありません。

重要なポイント

JIT runner は、起動直前に生成された 1 回限りの設定を使います。
ephemeral なマシンが残す古い登録を回避します。
使い捨ての認証情報がセキュリティの影響範囲を縮小します。
JIT は通常 cold start の経路で、warm pool によって補完されます。