Skip to main content

セルフホステッド ランナーの概要

独自のランナーをホストして、GitHub Actionsワークフロー中でジョブの実行に使われる環境をカスタマイズできます。

セルフホステッド ランナーの概要

セルフホステッド ランナーとは、GitHub.com の GitHub Actions からジョブを実行するためにデプロイおよび管理するシステムです。 GitHub Actionsに関する詳細については、「GitHub Actions を理解する」を参照してください。

セルフホステッド ランナーを使用すると、ハードウェア、オペレーティング システム、ソフトウェア ツールを、GitHub ホステッド ランナーよりも細かく制御できます。 セルフホステッド ランナーを使用すると、大規模なジョブを実行するための処理能力やメモリのニーズを満たすカスタム ハードウェア構成の作成、ローカル ネットワークで利用可能なソフトウェアのインストール、GitHub ホステッド ランナーで提供されていないオペレーティング システムの選択が行えます。 セルフホステッド ランナーは、物理または仮想にでき、コンテナー内、オンプレミス、またはクラウドに配置できます。

管理階層のさまざまなレベルでセルフホストランナーを追加できます。

  • リポジトリレベルのランナーは、単一のリポジトリ専用です。
  • Organization レベルのランナーは、Organization 内の複数のリポジトリのジョブを処理できます。
  • Enterprise レベルのランナーは、Enterprise アカウントの複数の Organization に割り当てることができます。

ランナーマシンは、GitHub Actionsのセルフホストランナーアプリケーションを使ってGitHubに接続します。 GitHub Actionsランナーアプリケーションはオープンソースです。 ランナー リポジトリでイシューを投稿およびファイルできます。 新しいバージョンがリリースされると、ランナー アプリケーションでは、ランナーにジョブが割り当てられたとき、またはジョブが割り当てられなかった場合はリリースから一週間以内に、それ自体を自動的に更新します。

セルフホスト ランナーは、GitHub Actions に 14 日以上接続されないと、GitHub から自動的に削除されます。 エフェメラル セルフホストランナーは、GitHub Actions に 1 日以上接続されないと、GitHub から自動的に削除されます。

セルフホスト ランナーのインストールと使用の詳細については、「自己ホストランナーの追加」および「ワークフローでのセルフホストランナーの利用」を参照してください。

GitHub-ホステッド ランナーとセルフホステッド ランナーとの違い

GitHub-ホステッド ランナーを使用すると、ワークフローを迅速かつ簡単に実行することができます。セルフホステッド ランナーを使用すると、独自のカスタム環境でワークフローを実行するための高度な構成が可能な方法です。

GitHubホストランナー

  • オペレーティング システム、プリインストールされたパッケージとツール、セルフホステッド ランナー アプリケーションの自動更新プログラムを受け取ります。
  • GitHubによって管理及びメンテナンスされます。
  • ジョブを実行するたびにクリーンなインスタンスを提供します。
  • GitHubプランの無料の分を使います。無料の分を超えると、分単位のレートが適用されます。

セルフホステッド ランナー:

  • セルフホステッド ランナー アプリケーションの自動更新プログラムのみを受け取りますが、ランナーの自動更新プログラムを無効にすることもできます。 セルフホステッド ランナーでのランナー ソフトウェアの更新プログラムの制御について詳しくは、「セルフホステッド ランナーによる自動スケーリング」をご覧ください。 オペレーティング システムとその他すべてのソフトウェアは、お客様の責任で更新する必要があります。
  • 既に料金を支払っているクラウド サービスまたはローカル マシンを使用することができます。
  • ハードウェア、オペレーティング システム、ソフトウェア、セキュリティの要件に合わせてカスタマイズできます。
  • ジョブを実行するたびにクリーンなインスタンスを用意する必要はありません。
  • GitHub Actions と一緒に無料で使用できますが、ランナー マシンのメンテナンス コストはユーザーの負担となります。

セルフホストランナーマシンに対する要求

以下の要求を満たしていれば、いかなるマシンもセルフホストランナーとして利用できます。

  • マシン上にセルフホストランナーアプリケーションをあなたがインストールして実行できること。 詳細については、「セルフホスト ランナーをサポートするアーキテクチャとオペレーティング システム」を参照してください。
  • そのマシンがGitHub Actionsと通信できる。 詳細については、「セルフホスト ランナーと GitHub との通信」を参照してください。
  • そのマシンが、実行しようとしている種類のワークフローに対して十分なハードウェアリソースを持っていること。 セルフホストランナーアプリケーションそのものは、最小限のリソースしか必要としません。
  • Dockerコンテナアクションあるいはサービスコンテナを使うワークフローを実行したいなら、Linuxのマシンを使い、Dockerがインストールされていなければなりません。

セルフホスト ランナーの自動スケーリング

受信した Webhook イベントに応じて、環境内のセルフホスト ランナーの数を自動的に増減できます。 詳しくは、「セルフホステッド ランナーによる自動スケーリング」を参照してください。

Usage limits (使用状況の制限)

セルフホストランナーを使用する場合、GitHub Actions の使用にはいくつかの制限があります。 これらの制限は変更されることがあります。

  • ワークフローの実行時間 - 各ワークフローの実行は 35 日までに制限されます。 ワークフローの実行がこの制限に達すると、そのワークフローの実行はキャンセルされます。 この期間には、実行時間と、待機と承認に費やされた時間が含まれます。
  • ジョブの待ち時間 - 少なくとも 24 時間キューに入れられているセルフホスト ランナーの各ジョブはキャンセルされます。 キューの実際の時間は、キャンセルされるまでに最大 48 時間に達する可能性があります。 この制限内にセルフホストランナーがジョブの実行を開始しなければ、ジョブは終了させられ、完了に失敗します。
  • API 要求 - 1 つのリポジトリの全アクションで 1 時間に実行できる GitHub API への要求は、最大 1,000 です。 要求超過になると、それ以上の API 呼び出しは失敗し、それによってジョブが失敗する可能性があります。
  • ジョブ マトリックス - ジョブマトリックスは、ワークフローの実行ごとに最大で256のジョブを生成できます。 この制限は、GitHub ホスト ランナーとセルフホステッド ランナーの両方に適用されます。
  • ワークフロー実行キュー - リポジトリあたり 10 秒間隔で 500 を超えるワークフロー実行をキューに入れることはできません。 ワークフローの実行がこの制限に達すると、そのワークフローの実行は終了させられ、完了に失敗します。
  • セルフホステッド ランナーの登録 - 1 つのランナー グループに最大 10,000 個のセルフホステッド ランナーを登録できます。 この制限に達すると、新しいランナーを追加できなくなります。

セルフホストランナーのワークフローの継続性

GitHub Actionsサービスが一時的に利用できなくなっている場合、ワークフローの実行はトリガーされてから30分以内にキューイングされていなければ、破棄されます。 たとえば、ワークフローがトリガーされ、そしてGitHub Actionsサービスが31分以上利用できなければ、そのワークフローの実行は処理されません。

セルフホストランナーをサポートするアーキテクチャとオペレーティングシステム

セルフホストランナーアプリケーション用には、以下のオペレーティングシステムがサポートされています。

Linux

  • Red Hat Enterprise Linux 8 以降
  • CentOS 8 以降
  • Oracle Linux 8 以降
  • Fedora 29以降
  • Debian 10 以降
  • Ubuntu 20.04 以降
  • Linux Mint 20 以降
  • openSUSE 15.2 以降
  • SUSE Enterprise Linux (SLES) 15 SP2 以降

Windows

  • Windows 10 (64 ビット)
  • Windows 11 64 ビット
  • Windows Server 2016 64 ビット
  • Windows Server 2019 64-bit
  • Windows Server 2022 64 ビット

macOS

  • macOS 11.0 (Big Sur) 以降

アーキテクチャ

セルフホストランナーアプリケーションでは、次のプロセッサアーキテクチャがサポートされています。

  • x64 - Linux、macOS、Windows。
  • ARM64 - Linux、macOS、Windows (現在ベータ版)。
  • ARM32 - Linux。

セルフホストランナーとGitHubとの通信

セルフホスト ランナーでは、GitHub に接続して、ジョブの割り当てを受け取り、ランナー アプリケーションの新しいバージョンをダウンロードします。 セルフホスト ランナーでは、HTTPS の ロング ポーリング を使用します。これは GitHub に対して 50 秒間接続を開き、レスポンスがない場合はタイムアウトして新しいロング ポーリングを作成します。 アプリケーションは、GitHub Actionsジョブを受け付けて実行するためにマシン上で動作していなければなりません。

セルフホステッド ランナーが GitHub.com への接続を開くので、ユーザーはセルフホステッド ランナーへのインバウンド接続を行うことを GitHub に許可する必要はありません。

下記の GitHub ホストと通信するのに、アップロードおよびダウンロード速度が 70 kbps 以上の適切なネットワーク アクセスがマシンにあることを確認する必要があります。 一部のホストは重要なランナー操作で必要となり、他のホストは特定の機能でのみ必要となります。

REST API を使用して、GitHub に関するメタ情報 (GitHub サービスの IP アドレスなど) を取得できます。 使用されるドメインと IP アドレスの詳細については、「メタデータ用 REST API エンドポイント」を参照してください。

注: 下記のドメインの一部は、CNAME レコードを使用して構成されます。 ファイアウォールによっては、すべての CNAME レコードに対して規則を再帰的に追加する必要がある場合があります。 CNAME レコードは今後変更される可能性があり、下記のドメインのみが一定のままであることに注意してください。

重要な操作に必要:

Shell
github.com
api.github.com
*.actions.githubusercontent.com

ダウンロード アクションに必要:

Shell
codeload.github.com

ジョブサマリー、ログ、ワークフロー アーティファクトのアップロード/ダウンロードに必要:

Shell
results-receiver.actions.githubusercontent.com
*.blob.core.windows.net

ランナー バージョンの更新に必要:

Shell
objects.githubusercontent.com
objects-origin.githubusercontent.com
github-releases.githubusercontent.com
github-registry-files.githubusercontent.com

OIDC トークンを取得するために必要:

Shell
*.actions.githubusercontent.com

パッケージまたはコンテナーを GitHub パッケージにダウンロードまたは発行するために必要です。

Shell
*.pkg.github.com
ghcr.io

Git Large File Storage に必要

Shell
github-cloud.githubusercontent.com
github-cloud.s3.amazonaws.com

さらに、ワークフローで他のネットワーク リソースへのアクセスが必要になる場合があります。

GitHub Organizationあるいは Enterprise アカウントでIPアドレス許可リストを使うなら、セルフホストランナーのIPアドレスを許可リストに追加しなければなりません。 詳細については、GitHub Enterprise Cloud のドキュメントの「Organization に対する許可 IP アドレスを管理する」または「Enterprise でセキュリティ設定のポリシーを適用する」を参照してください。

セルフホストランナーは、プロキシサーバーと合わせて使うこともできます。 詳しくは、「セルフホストランナーとプロキシ サーバーを使う」を参照してください。

一般的なネットワーク接続の問題のトラブルシューティングの詳細については、「セルフホストランナーのモニタリングとトラブルシューティング」を参照してください。

セルフホスト ランナーのセキュリティ

セルフホストランナーは、プライベートリポジトリでのみ利用することをおすすめします。 これは、ワークフロー内でコードを実行する pull request を作成することで、パブリック リポジトリのフォークによって、セルフホステッド ランナー マシン上で危険なコードが実行される可能性があるからです。

それぞれのGitHubホストランナーは常にクリーンな隔離された仮想マシンになり、ジョブの実行が終わると破棄されるので、GitHubホストランナーではこれは問題にはなりません。

セルフホスト ランナー上で実行される信頼できないワークフローでは、マシンやネットワーク環境に大きなセキュリティ リスクがもたらされます。これは特に、マシンでジョブにまたがって環境が保持される場合に当てはまります。 リスクには以下のようなものがあります。

  • マシン上での悪意あるプログラムの実行
  • マシンのランナーのサンドボックスからの脱却
  • マシンのネットワーク環境へのアクセスの露出
  • 望まないもしくは危険なデータのマシン上への保存

セルフホスト ランナーのセキュリティ強化の詳細については、「GitHub Actions のセキュリティ強化」を参照してください。

セルフホステッド ランナーの使用を制限する

Organization の所有者は、リポジトリ レベルのセルフホステッド ランナーの作成を許可するリポジトリを選択できます。 。

詳細については、「Organization について GitHub Actions を無効化または制限する」を参照してください。