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

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

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

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

サポートされている自動スケールソリューション

actions/actions-runner-controller (ARC) プロジェクトは、Kubernetes ベースのランナーオートスケーラーです。 GitHub では、デプロイするチームに Kubernetes の専門知識と経験がある場合は ARC が推奨されます。

詳細については、「Actions Runner Controller について」および「アクションランナーコントローラーのサポートについて」を参照してください。

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

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

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

Warning

エフェメラルランナーのランナーアプリケーションログファイルは、トラブルシューティングや診断のために外部ログストレージソリューションに転送する必要があります。エフェメラルランナーをデプロイする必要はありませんが、GitHub では、運用環境にエフェメラルランナー自動スケールソリューションをデプロイする前に、ランナーログが転送され、外部に保持されることを推奨しています詳しくは、「自己ホストランナーのモニタリングとトラブルシューティング」を参照してください。

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

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

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

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

または、REST API を使って、エフェメラル Just-In-Time ランナーを作成することもできます。詳しくは、「セルフホステッドランナーの REST API エンドポイント」を参照してください。

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

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

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

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

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

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

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

Warning

メジャーリリース、マイナーリリース、パッチリリースなどソフトウェアに対してリリースされたすべての更新プログラムは利用可能な更新プログラムと見なされます。 30 日以内にソフトウェアを更新しないと、GitHub Actions サービスはランナーへのジョブをキューに入れなくなります。さらに、重要なセキュリティ更新プログラムが必要な場合、GitHub Actions サービスは、更新されるまで、ランナーへのジョブをキューに入れません。

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

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

workflow_job Webhook について詳しくは、「Webhook のイベントとペイロード」をご覧ください。
Webhook の使用方法については、「Webhook ドキュメント」をご覧ください。

認証の要件

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

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

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

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

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

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

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

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

この記事の内容