セルフホステッド ランナーの概要
セルフホステッド ランナーとは、GitHub AE の GitHub Actions からジョブを実行するためにデプロイおよび管理するシステムです。 GitHub Actions について詳しくは、「GitHub Actions を理解する」と「エンタープライズの GitHub Actions について」を参照してください。
セルフホステッド ランナーを使用すると、大規模なジョブを実行するための処理能力やメモリのニーズを満たすカスタム ハードウェア構成の作成、ローカル ネットワークで利用可能なソフトウェアのインストール、オペレーティング システムの選択が行えます。 セルフホステッド ランナーは、物理または仮想にでき、コンテナー内、オンプレミス、またはクラウドに配置できます。
管理階層のさまざまなレベルでセルフホストランナーを追加できます。
- リポジトリレベルのランナーは、単一のリポジトリ専用です。
- Organization レベルのランナーは、Organization 内の複数のリポジトリのジョブを処理できます。
- Enterprise レベルのランナーは、Enterprise アカウントの複数の Organization に割り当てることができます。
ランナーマシンは、GitHub Actionsのセルフホストランナーアプリケーションを使ってGitHub AEに接続します。 GitHub Actionsランナーアプリケーションはオープンソースです。 ランナー リポジトリでイシューを投稿およびファイルできます。 新しいバージョンがリリースされると、ランナー アプリケーションでは、ランナーにジョブが割り当てられたとき、またはジョブが割り当てられなかった場合はリリースから一週間以内に、それ自体を自動的に更新します。
セルフホストランナーは、GitHub Actions に 30 日以上接続されないと、GitHub AE から自動的に削除されます。
セルフホスト ランナーのインストールと使用の詳細については、「自己ホストランナーの追加」および「ワークフローでのセルフホストランナーの利用」を参照してください。
セルフホスト ランナーの特性
セルフホステッド ランナーは独自のカスタム環境内でワークフローを実行するための構成の幅が広い方法です。 セルフホスト ランナー:
- セルフホステッド ランナー アプリケーションの自動更新のみを受け取ります。ただし、ランナーの自動更新を無効にすることもできます。 セルフホスト ランナーでのランナー ソフトウェア更新プログラムを制御する方法について詳しくは、「セルフホステッド ランナーによる自動スケーリング」を参照してください。オペレーティング システムおよび他のすべてのソフトウェアは、お客様の責任で更新する必要があります。
- 既に料金を支払っているクラウド サービスまたはローカル マシンを使用することができます。
- ハードウェア、オペレーティング システム、ソフトウェア、セキュリティの要件に合わせてカスタマイズできます。
- ジョブを実行するたびにクリーンなインスタンスを用意する必要はありません。
- GitHub Actions と共に無料で利用できますが、ランナー マシンのメンテナンス コストは、お客様の負担となります。
- 特定のワークフロー、組織、リポジトリへのアクセスを制限するために、グループに編成できます。 詳細については、「グループを使用してセルフホストランナーへのアクセスを管理する」を参照してください。
セルフホストランナーマシンに対する要求
以下の要求を満たしていれば、いかなるマシンもセルフホストランナーとして利用できます。
- マシン上にセルフホストランナーアプリケーションをあなたがインストールして実行できること。 詳細については、「セルフホスト ランナーをサポートするアーキテクチャとオペレーティング システム」を参照してください。
- そのマシンがGitHub Actionsと通信できる。 詳細については、「セルフホスト ランナーと GitHub AE との通信」を参照してください。
- そのマシンが、実行しようとしている種類のワークフローに対して十分なハードウェアリソースを持っていること。 セルフホストランナーアプリケーションそのものは、最小限のリソースしか必要としません。
- Dockerコンテナアクションあるいはサービスコンテナを使うワークフローを実行したいなら、Linuxのマシンを使い、Dockerがインストールされていなければなりません。
セルフホスト ランナーの自動スケーリング
受信した Webhook イベントに応じて、環境内のセルフホスト ランナーの数を自動的に増減できます。 詳しくは、「セルフホステッド ランナーによる自動スケーリング」を参照してください。
Usage limits (使用状況の制限)
セルフホストランナーを使用する場合、GitHub Actions の使用にはいくつかの制限があります。 これらの制限は変更されることがあります。
- ワークフローの実行時間 - 各ワークフローの実行は 35 日までに制限されます。 ワークフローの実行がこの制限に達すると、そのワークフローの実行はキャンセルされます。 この期間には、実行時間と、待機と承認に費やされた時間が含まれます。
- ジョブ キューの時間 - セルフホスト ランナーの各ジョブは、最大 24 時間キューに入れておくことができます。 この制限内にセルフホストランナーがジョブの実行を開始しなければ、ジョブは終了させられ、完了に失敗します。
- API 要求 - 1 時間に実行できる GitHub API への要求は、1 つのリポジトリの全アクションで最大 1000 までです。 要求超過になると、それ以上の API 呼び出しは失敗し、それによってジョブが失敗する可能性があります。
- ジョブ マトリックス - ジョブマトリックスは、ワークフローの実行ごとに最大で256のジョブを生成できます。 この制限は、GitHub AE ホスト ランナーとセルフホステッド ランナーの両方に適用されます。 - ワークフロー実行キュー - リポジトリあたり 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。ARM32
- Linux。
セルフホストランナーとGitHub AEとの通信
セルフホスト ランナーでは、GitHub AE に接続して、ジョブの割り当てを受け取り、ランナー アプリケーションの新しいバージョンをダウンロードします。 セルフホスト ランナーでは、HTTPS の ロング ポーリング を使用します。これは GitHub AE に対して 50 秒間接続を開き、レスポンスがない場合はタイムアウトして新しいロング ポーリングを作成します。 アプリケーションは、GitHub Actionsジョブを受け付けて実行するためにマシン上で動作していなければなりません。
セルフホステッド ランナーと GitHub AE の接続は、HTTPS (ポート 443) を経由します。
ランナーから ご自分のエンタープライズ へのアウトバウンド接続のみが必要です。 ご自分のエンタープライズ からランナーへのインバウンド接続は必要ありません。
GitHub AE の URL とそのサブドメインと通信するための適切なネットワーク アクセスがセルフホスト ランナーにあることを確認する必要があります。 たとえば、GitHub AE のサブドメインが octoghae
の場合は、セルフホスト ランナーが octoghae.githubenterprise.com
、api.octoghae.githubenterprise.com
、codeload.octoghae.githubenterprise.com
にアクセスできるようにする必要があります。
IP アドレス許可リストを使用する場合は、セルフホスト ランナーの IP アドレスを許可リストに追加する必要があります。 詳しくは、「Organization に対する許可 IP アドレスを管理する」を参照してください。
GitHub の Organization または Enterprise アカウントで IP アドレス許可リストを使用する場合は、セルフホストランナーの IP アドレスを許可リストに追加する必要があります。 詳しくは、「Organization に対する許可 IP アドレスを管理する」を参照してください。
セルフホストランナーは、プロキシサーバーと合わせて使うこともできます。 詳しくは、「セルフホストランナーとプロキシ サーバーを使う」を参照してください。
一般的なネットワーク接続の問題のトラブルシューティングの詳細については、「セルフホストランナーのモニタリングとトラブルシューティング」を参照してください。
セルフホスト ランナーと GitHub.com の間の通信
ご自分のエンタープライズ の GitHub.com アクションへの自動アクセスを有効にしている場合を除き、セルフホステッド ランナーが GitHub.com に接続する必要はありません。 詳しくは、「Enterprise でのアクションの使用について」を参照してください。
GitHub.com アクションへの自動アクセスを有効にした場合、セルフホスト ランナーでは GitHub.com に直接接続してアクションをダウンロードします。 下記の GitHub の URL と通信するための適切なネットワークアクセスがマシンにあることを確認する必要があります。
github.com
api.github.com
codeload.github.com
注: 上記のドメインの一部は、CNAME
レコードを使用して構成されます。 ファイアウォールによっては、すべての CNAME
レコードに対して規則を再帰的に追加する必要がある場合があります。 CNAME
レコードは今後変更される可能性があり、上記のドメインのみが一定のままであることに注意してください。
セルフホスト ランナーのセキュリティ
セルフホスト ランナー上で実行される信頼できないワークフローでは、マシンやネットワーク環境に大きなセキュリティ リスクがもたらされます。これは特に、マシンでジョブにまたがって環境が保持される場合に当てはまります。 リスクには以下のようなものがあります。
- マシン上での悪意あるプログラムの実行
- マシンのランナーのサンドボックスからの脱却
- マシンのネットワーク環境へのアクセスの露出
- 望まないもしくは危険なデータのマシン上への保存
セルフホスト ランナーのセキュリティ強化の詳細については、「GitHub Actions のセキュリティ強化」を参照してください。