Skip to main content

このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2023-01-18. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise にアップグレードします。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせく� さい

セルフホステッド ランナーによる自動スケーリング

Webhook イベントに応答して、セルフホステッド ランナーを自動的にスケーリングできます。

注: GitHub ホステッド ランナーは、現在 GitHub Enterprise Server でサポートされていません。 GitHub public roadmap で、今後の計画的なサポートの詳細を確認できます。

自動スケーリングについて

特定のラベルで受信した Webhook イベントに応答して、環境内のセルフホステッド ランナーの数を自動的に増減できます。 たとえば、queued アクティビティを含む workflow_job Webhook イベントを受信するたびに、新しいセルフホステッド ランナーを追� するオートメーションを作成できます。このイベントは、新しいジョブが処理できる状態であることを通知します。 Webhook のペイロードにはラベル データが含まれているため、ジョブが要求しているランナーの種類を識別できます。 ジョブが完了したら、workflow_jobcompleted アクティビティに応答してランナーを削除するオートメーションを作成できます。

GitHub は、ランナーの自動スケーリングに使用できる 2 つのオープンソース プロジェクトを推奨し、それらと密接に連携しています。 ニーズに応じて、一方または両方のソリューションが適している可能性があります。

これらの自動スケーラーを設定する詳しい手� �については、次のリポジトリをご覧く� さい。

各ソリューションには、考慮すべき重要な特定の詳細が含まれる� �合があります。

機能actions-runner-controllerterraform-aws-github-runner
ランタイ� KubernetesLinux と Windows VM
サポートされているクラウドAzure、アマゾン ウェブ サービス、Google Cloud Platform、オンプレミスアマゾン ウェブ サービス
ランナーをスケーリングできる� �所Enterprise、Organization、リポジトリのレベル。 ランナー ラベルとランナー グループ別。Organization とリポジトリのレベル。 ランナー ラベルとランナー グループ別。
ランナーをスケーリングする方法Webhook イベント、スケジュール、プル ベースWebhook イベント、スケジュール (Organization レベルのランナーのみ)

自動スケーリングにエフェメラル ランナーを使用する

GitHub は、エフェメラル セルフホステッド ランナーで自動スケーリングを実装することをお勧めします。永続的なセルフホステッド ランナーでの自動スケーリングはお勧めしません。 特定のケースでは、GitHub は、ジョブがシャットダウン中に永続的ランナーに割り当てられないことを保証できません。 エフェメラル ランナーであれば、GitHub はランナーに 1 つのジョブしか割り当てないため、これを保証できます。

この方法では、オートメーションを使ってジョブごとにクリーンな環境を提供できるため、ランナーをエフェメラル システ� として管理できます。 これは、以前のジョブから機密リソースが公開されるのを制限する役に立ち、侵害されたランナーが新しいジョブを受け取るリスクを軽減するのにも役立ちます。

環境にエフェメラル ランナーを追� するには、config.sh を使ってランナーを登録するときに --ephemeral パラメーターを指定します。 たとえば次のような点です。

./config.sh --url https://github.com/octo-org --token example-token --ephemeral

その後、ランナーが 1 つのジョブを処理すると、GitHub Actions サービスによって自動的に登録解除されます。 その� �合、登録解除後にランナーをワイプする独自のオートメーションを作成できます。

注: ジョブに特定の種類のランナー用のラベルが付いていて、その種類に一致するものを使用できない� �合、ジョブがキューに入れられてすぐに失敗することはありません。 そうではなく、24 時間のタイ� アウト期間が切れるまで、ジョブはキューに残ります。

自動スケーリングに Webhook を使用する

workflow_job Webhook から受信したペイロードを使って、独自の自動スケーリング環境を作成できます。 この Webhook は、リポジトリ、Organization、Enterprise のレベルで使用でき、このイベントのペイロードには、ワークフロー ジョブのライフサイクルのステージに対応する action キーが含まれています (たとえば、ジョブが queuedin_progresscompleted のとき)。 その� �合、これらの Webhook ペイロードに応答して独自のスケーリング オートメーションを作成する必要があります。

認証の要件

API を使って、リポジトリと Organization のセルフホステッド ランナーを登録および削除できます。 自動スケーリングの実装で、API の認証を行うには、アクセス トークンまたは GitHub アプリを使用できます。

アクセス トークンには、次のスコープが必要です。

  • プライベート リポジトリの� �合は、repo スコープでアクセス トークンを使います。
  • パブリック リポジトリの� �合は、public_repo スコープでアクセス トークンを使います。
  • Organization の� �合は、admin:org スコープでアクセス トークンを使います。

GitHub アプリを使って認証を行うには、次のアクセス許可を割り当てる必要があります。

  • リポジトリの� �合は、administration アクセス許可を割り当てます。
  • Organization の� �合は、organization_self_hosted_runners アクセス許可を割り当てます。

API を使って、Enterprise のセルフホステッド ランナーを登録および削除できます。 自動スケーリングの実装で API の認証を行うには、アクセス トークンを使用できます。

アクセス トークンには、manage_runners:enterprise スコープが必要です。