セルフホステッド ランナーの概要
セルフホステッド ランナーとは、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 時間キューに入れておくことができます。 この制限内にセルフホストランナーがジョブの実行を開始しなければ、ジョブは終了させられ、完了に失敗します。
- API 要求 - 1 時間に実行できる GitHub API への要求は、1 つのリポジトリの全アクションで最大 1000 までです。 要求超過になると、それ以上の API 呼び出しは失敗し、それによってジョブが失敗する可能性があります。
- ジョブ マトリックス - ジョブマトリックスは、ワークフローの実行ごとに最大で256のジョブを生成できます。 この制限は、GitHub ホスト ランナーとセルフホステッド ランナーの両方に適用されます。 - ワークフロー実行キュー - リポジトリあたり 10 秒間隔で 500 を超えるワークフロー実行をキューに入れることはできません。 ワークフローの実行がこの制限に達すると、そのワークフローの実行は終了させられ、完了に失敗します。
セルフホストランナーのワークフローの継続性
GitHub Actionsサービスが一時的に利用できなくなっている場合、ワークフローの実行はトリガーされてから30分以内にキューイングされていなければ、破棄されます。 たとえば、ワークフローがトリガーされ、そしてGitHub Actionsサービスが31分以上利用できなければ、そのワークフローの実行は処理されません。
セルフホストランナーをサポートするアーキテクチャとオペレーティングシステム
セルフホストランナーアプリケーション用には、以下のオペレーティングシステムがサポートされています。
Linux
- Red Hat Enterprise Linux 7 以降
- CentOS 7 以降
- Oracle Linux 7 以降
- Fedora 29以降
- Debian 9以降
- Ubuntu 16.04 以降
- Linux Mint 18以降
- openSUSE 15以降
- SUSE Enterprise Linux (SLES) 12 SP2以降
Windows
- Windows 7 64-bit
- Windows 8.1 (64 ビット)
- Windows 10 (64 ビット)
- Windows 10 64-bit
- Windows Server 2016 64 ビット
- Windows Server 2019 64-bit
- Windows Server 2022 64 ビット
macOS
- macOS 10.13 (High Sierra)以降
アーキテクチャ
セルフホストランナーアプリケーションでは、次のプロセッサアーキテクチャがサポートされています。
x64
- Linux、macOS、Windows。ARM64
- Linux、macOS、Windows (現在ベータ版)。ARM32
- Linux。
セルフホストランナーとGitHubとの通信
セルフホスト ランナーでは、GitHub に接続して、ジョブの割り当てを受け取り、ランナー アプリケーションの新しいバージョンをダウンロードします。 セルフホスト ランナーでは、HTTPS の ロング ポーリング を使用します。これは GitHub に対して 50 秒間接続を開き、レスポンスがない場合はタイムアウトして新しいロング ポーリングを作成します。 アプリケーションは、GitHub Actionsジョブを受け付けて実行するためにマシン上で動作していなければなりません。
セルフホステッド ランナーが GitHub.com への接続を開くので、ユーザーはセルフホステッド ランナーへのインバウンド接続を行うことを GitHub に許可する必要はありません。
下記の GitHub のホストと通信するための適切なネットワーク アクセスがマシンにあることを確認する必要があります。 一部のホストは重要なランナー操作で必要となり、他のホストは特定の機能でのみ必要となります。
注: 下記のドメインの一部は、CNAME
レコードを使用して構成されます。 ファイアウォールによっては、すべての CNAME
レコードに対して規則を再帰的に追加する必要がある場合があります。 CNAME
レコードは今後変更される可能性があり、下記のドメインのみが一定のままであることに注意してください。
重要な操作に必要:
github.com
api.github.com
*.actions.githubusercontent.com
ダウンロード アクションに必要:
codeload.github.com
ジョブの概要とログのアップロードとダウンロードに必要
actions-results-receiver-production.githubapp.com
productionresultssa*.blob.core.windows.net
ランナー バージョンの更新に必要:
objects.githubusercontent.com
objects-origin.githubusercontent.com
github-releases.githubusercontent.com
github-registry-files.githubusercontent.com
キャッシュとワークフロー成果物のアップロード/ダウンロードに必要:
*.blob.core.windows.net
OIDC トークンを取得するために必要:
*.actions.githubusercontent.com
パッケージまたはコンテナーを GitHub パッケージにダウンロードまたは発行するために必要です。
*.pkg.github.com
ghcr.io
さらに、ワークフローで他のネットワーク リソースへのアクセスが必要になる場合があります。
GitHub OrganizationあるいはEnterpriseアカウントでIPアドレス許可リストを使うなら、セルフホストランナーのIPアドレスを許可リストに追加しなければなりません。 詳細については、GitHub Enterprise Cloud のドキュメントの「Organization に対する許可 IP アドレスを管理する」または「Enterprise でセキュリティ設定のポリシーを適用する」を参照してください。
セルフホストランナーは、プロキシサーバーと合わせて使うこともできます。 詳しくは、「セルフホストランナーとプロキシ サーバーを使う」を参照してください。
一般的なネットワーク接続の問題のトラブルシューティングの詳細については、「セルフホストランナーのモニタリングとトラブルシューティング」を参照してください。
セルフホスト ランナーのセキュリティ
セルフホストランナーは、プライベートリポジトリでのみ利用することをおすすめします。 これは、ワークフロー内でコードを実行する pull request を作成することで、パブリック リポジトリのフォークによって、セルフホステッド ランナー マシン上で危険なコードが実行される可能性があるからです。
それぞれのGitHubホストランナーは常にクリーンな隔離された仮想マシンになり、ジョブの実行が終わると破棄されるので、GitHubホストランナーではこれは問題にはなりません。
セルフホスト ランナー上で実行される信頼できないワークフローでは、マシンやネットワーク環境に大きなセキュリティ リスクがもたらされます。これは特に、マシンでジョブにまたがって環境が保持される場合に当てはまります。 リスクには以下のようなものがあります。
- マシン上での悪意あるプログラムの実行
- マシンのランナーのサンドボックスからの脱却
- マシンのネットワーク環境へのアクセスの露出
- 望まないもしくは危険なデータのマシン上への保存
セルフホスト ランナーのセキュリティ強化の詳細については、「GitHub Actions のセキュリティ強化」を参照してください。