⭐️GitHub Actions: JIT runner（Just-In-Time）

1 ジョブだけ動いて消える self-hosted runner。

1 ジョブ = ワークフローの jobs: の 1 つが 1 回実行されること。matrix なら組み合わせごと、Re-run も別ジョブ扱い。

登場人物

  • 管理役: GitHub App の秘密鍵を持ち、API を叩いて runner を用意する側（ARC のコントローラや自作サーバ）。runner とは別物
  • runner: ジョブを実行するマシン。秘密鍵は持たない

登録方法は 2 つ

違いは「誰が登録するか」だけ。

registration token: 管理役がトークンを取る → runner が自分で登録する
JIT config        : 管理役が登録まで済ませる → runner は起動するだけ

registration token の流れ

管理役
  1. 秘密鍵で JWT を作る（最大 10 分有効）
  2. JWT → installation access token（1 時間有効）
  3. installation access token → registration token（1 時間有効）
  4. registration token を runner に渡す
runner
  5. config.sh --token で登録。このとき runner 用の鍵ペアを作り、公開鍵を GitHub に送る
  6. run.sh でジョブを待つ。以降は 5 の鍵で認証するので registration token は用済み

4 の渡し方は GitHub の仕様の外で、自分で作る。例:

  • 管理役に「registration token を返すエンドポイント」を用意し、runner の VM が起動時に叩いて取る

手動登録（Settings → Actions → Runners → New self-hosted runner）も中身は同じ。画面に表示される config.sh --token XXX の XXX が registration token で、1〜3 を管理役の代わりに人間が画面でやっているだけ。

JIT config の流れ

1〜2 は同じ。3 で generate-jitconfig を叩くと、その時点で登録が済み、認証情報（base64）が返る。runner は run.sh --jitconfig で起動するだけで、1 ジョブ終わると自動で登録解除される。

比較

registration tokenJIT config
登録する人runner管理役
使い方常駐も使い捨て（--ephemeral）も可使い捨てのみ
向いている少数を手で立てるオートスケール

公式の推奨

公式が推しているのは「使い捨て（ephemeral）」。常駐 runner でのオートスケールは非推奨。

常駐だと前のジョブの影響が次に残る:

  • セキュリティ: 乗っ取られた runner が、次のジョブ（別リポジトリの秘密情報など）も受け取る
  • 痕跡: 前のジョブのファイル・認証情報・インストール物が残り、次のジョブから見える / 結果が変わる
  • オートスケール: 止めた常駐 runner にジョブが割り当てられることがある。使い捨ては 1 runner 1 ジョブなので起きない

補足:

  • 使い捨てなら registration token + --ephemeral でも JIT でもよい。どちらかを推す記述はない
  • Kubernetes 向けの公式の仕組み ARC（Actions Runner Controller）が推奨されている

参考: