コンテンツへスキップ
LatchkeyLatchkeyLatchkey home
ドキュメントメニュー

プロビジョニングの仕組み

GitHub でジョブがキューに入ってからランナーがピックアップするまでに何が起きるか: ウォームプール、ジャストインタイム登録によるコールドスタート、同時実行の上限、そしてジョブが待たされる理由。

GitHub が latchkey-* ラベル付きのジョブをキューに入れると、Webhook が即座に Latchkey に伝え、Latchkey は 1 つの判断を下します: ジョブを既にウォームなランナーに渡すか、そのために新しいマシンを起動するか。あなたがその判断を目にすることはありませんが、それがほぼ即座に開始するジョブと、マシンの起動を待つジョブの違いであり、このページで扱う内容の大半を説明するものです。

01ジョブがキューに入るGitHub が latchkey-* ラベルを対象とするジョブをキューに入れます
02Webhookジョブがキューに入った瞬間に GitHub が Latchkey に通知します
03スケールアップの判断ウォームランナーがジョブを引き受けるか、新しいマシンが起動します
04ピックアップウォーム: ランナーが既にオンラインなら約 2 秒。コールド: 新しいマシンが起動してジャストインタイムで登録します。
05実行して破棄ジョブはマシン上で単独で実行され、マシンはその後終了されます
約 2 秒
ウォームピックアップ
ウォームランナーが既にオンラインの場合
JIT
コールドスタート
新しいマシン、ジャストインタイムで登録
1
VM あたりのジョブ
すべてのランナーはジョブの後に破棄されます
4h
ジョブの上限
マシンは 4 時間で終了されます

ウォームピックアップ vs コールドスタート#

ウォームピックアップ は、事前にプロビジョニングされたランナーがあなたのワークスペース向けに既にオンラインだったことを意味します: ジョブはそのままそのランナーに渡され、約 2 秒で開始します。コールドスタート は、適合するウォームランナーがなかったことを意味します: そのジョブのためだけに新しいマシンが起動し、ジャストインタイムの単回使用構成で GitHub に登録し、その後あなたのステップを実行します。どちらのパスも終わり方は同じです: ランナーは正確に 1 つのジョブを引き受け、ジョブが終了するとマシンは終了されます。

ウォームプール#

プランウォームプール
Developerウォームな latchkey-small ランナー 1 台とパーク済み容量
Launch同じベースライン: ウォームランナー 1 台とパーク済み容量
Scale同じベースライン: ウォームランナー 1 台とパーク済み容量

現在はすべてのプランが同じウォームのベースラインを受け取り、その対象は latchkey-small のみです: 常時オンのウォームランナー 1 台と、オンデマンドで再開するパーク済みマシンです。それを超えるもの、およびより大きなサイズを要求するジョブは、コールドスタートします。ウォーム容量はアイドル中に何のコストもかかりません。課金はジョブの分単位であり、アイドル状態のウォームランナーはジョブを実行していないからです。

常にエフェメラル#

プロビジョニングがマシンを再利用することは決してありません。ウォームでもコールドでも、ランナーは正確に 1 つのジョブを引き受け、その後ディスクとともに終了されます。GitHub の実行ビューでランナー名が実行ごとに変わるのはこのためであり、ジョブがローカルディスクに書き込んだものがジョブ終了時に消えるのもこのためです。この設計のセキュリティ面、すなわちジャストインタイムの認証情報、プライベートネットワーキング、暗号化された単回使用ディスクについては、セキュリティアーキテクチャ で扱います。

同時実行#

ワークスペースは開始時点で最大 40 の同時ビジーランナー を実行し (Launch プランの数値。プラン変更後は Developer が 20、Scale が 80。Enterprise の上限は契約で定められます)、カウントされるのはビジーなランナーだけです: アイドル状態のウォームランナーがスロットを消費することは決してないため、ウォーム容量があなたの実際のジョブと競合することはありません。バーストが一度にあなたの上限数を超える場合、あふれたジョブはスロットが空くまでキューに留まり、その後自動的に開始します。何もエラーにならず、何も失われません。GitHub Actions では、上限に達した時点ですでにアイドル状態だったウォームランナーは、待っていたその 1 つのジョブを受け取るため、ワークスペースはそのようなランナー 1 台につき最大で上限より 1 つ多いジョブを実行していることがあります。Latchkey が数値を守るためにランナーを停止することはありません。ピーク時に定期的にキュー待ちが発生するなら、より高い上限が利用可能です。サポートに連絡してください。

ハードな境界#

  • ジョブの上限は 4 時間 です。ジョブがまだ実行中でも、マシンは 4 時間で終了されます。
  • ランナーは x86_64 上の Ubuntu 24.04 LTS のみです: Windows、macOS、arm64、GPU ホストはありません。
  • ランナーは AWS us-east-1 で実行されます。

ディスクサイズやプランごとのカスタム構成数を含む完全な表は、上限と同時実行数 にあります。

ジョブが queued のまま留まる理由#

プロビジョニングがランナーを起動できない、または起動しない場合、GitHub 側にエラーはありません。ジョブはただ待ちます。これは設計によるものです: latchkey-* ラベルを対象とするジョブは、エラーになるのではなく GitHub でキューに留まります。よくある原因:

  • ラベルのタイプミス: どの構成もラベルに一致しないため、何もジョブをピックアップしません。
  • リポジトリが監視されていない、またはランナーの 構成が無効になっている。
  • 課金またはトライアルのブロック: 期限切れのトライアル、失効したサブスクリプション、またはカードなしトライアルで使い切った無料ティア。これが起きると "Managed runner blocked" 通知が、1 日に最大 1 回発火します。
  • カスタムランナーのイメージがまだビルド中: そのラベルを対象とするジョブは、ビルドが完了するまで待ちます。
  • ワークスペースが ビジーランナーの上限 (開始時点で 40、Launch プランの数値) に達している: スロットが空き次第、ジョブは開始します。

各原因の確認方法を含む、症状ごとのウォークスルーは トラブルシューティング にあります。

ジョブが queued のまま止まるのはなぜですか?

ウォームの基準容量を超えて待機している場合は、そのジョブのために新しいマシンがコールドスタート中です。それ以外は何かがブロックしています。ラベル、監視設定、構成、請求、進行中のイメージビルド、同時実行の上限のいずれかを、この順で確認してください。

ウォームピックアップとコールドスタートの違いは?

ウォームピックアップは既に稼働中のマシンにジョブを渡し、ランナーが既にオンラインなら約 2 秒です。コールドスタートは Just-in-Time 登録で新しいマシンを用意するため、より長くかかります。現在はすべてのプランが同じウォーム基準を持ち、常時稼働のウォームランナー 1 台に加えて latchkey-small の待機容量が用意されます。

アイドル状態のウォームランナーは同時実行の上限に数えられますか?

数えられません。あなたのワークスペースの同時ランナー数 (開始時点で 40 台) はビジー状態のランナーのみを数えるため、仕事を待っているウォーム容量が上限を消費することはありません。

References