Skip to main content

現在、GitHub AE は限定的リリースです。

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

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

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

特定のラベルで受信した 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 時間のタイムアウト期間が切れるまで、ジョブはキューに残ります。

セルフホステッド ランナーでランナー ソフトウェアの更新を制御する

既定では、ランナー ソフトウェアの新しいバージョンが利用可能になると、セルフホステッド ランナーは自動的にソフトウェアの更新を実行します。 コンテナーでエフェメラル ランナーを使用している場合は、新しいランナー バージョンがリリースされたときに、ソフトウェアの更新が繰り返される可能性があります。 自動更新をオフにすると、コンテナー イメージのランナー バージョンを独自のスケジュールで直接更新できます。

ソフトウェアの自動更新をオフにして、ソフトウェアの更新プログラムを自分でインストールするには、config.sh を使ってランナーを登録するときに、--disableupdate フラグを指定します。 たとえば次のような点です。

./config.sh --url https://github.com/YOUR-ORGANIZATION --token EXAMPLE-TOKEN --disableupdate

自動更新を無効にした場合でも、自分でランナーのバージョンを定期的に更新する必要があります。 GitHub Actions に新機能がある場合は、GitHub Actions サービスとランナー ソフトウェアの 両方 で変更する必要があります。 ソフトウェアを更新しないと、GitHub Actions の新機能を利用するジョブをランナーで正しく処理できない場合があります。

自動更新を無効にする場合は、ランナーの新しいバージョンが利用可能になってから 30 日以内に、バージョンを更新する必要があります。 actions/runner リポジトリでリリースの通知にサブスクライブすることもできます。 詳しくは、「通知を設定する」を参照してください。

ランナーの最新バージョンをインストールする方法については、最新リリースのインストール手順をご覧ください。

注: 30 日以内にソフトウェアを更新しないと、GitHub Actions サービスはランナーへのジョブをキューに入れなくなります。 さらに、重要なセキュリティ更新プログラムが必要な場合、GitHub Actions サービスは、更新されるまで、ランナーへのジョブをキューに入れません。

自動スケーリングに 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 スコープが必要です。