Skip to main content

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

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

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

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

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

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

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

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

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

注: エフェメラル ランナーを使用しており、自動更新を無効にしている場合は、your GitHub Enterprise Server instance をアップグレードする前に、まず、アップグレードしたインスタンスが実行されるランナー アプリケーションのバージョンにセルフホスト ランナーをアップグレードしておく必要があります。 エフェメラル ランナーをアップグレードする前に your GitHub Enterprise Server instance をアップグレードした場合、ランナーがオフラインになる可能性があります。 詳細については、「GitHub Enterprise Server のアップグレード」を参照してください。

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

セルフホスト ランナーのインストールと使用の詳細については、「セルフホスト ランナーの追加」および「Using self-hosted runners in a workflow (ワークフローでのセルフホスト ランナーの使用)」を参照してください。

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

GitHub ホステッド ランナーではワークフローを素早く簡単に実行する方法が提供されますが、セルフホステッド ランナーは独自のカスタム環境内でワークフローを実行するための構成の幅が広い方法です。

GitHub ホステッド ランナー:

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

セルフホスト ランナー:

  • セルフホステッド ランナー アプリケーションの自動更新のみを受け取ります。ただし、ランナーの自動更新を無効にすることもできます。 セルフホスト ランナーでのランナー ソフトウェア更新プログラムの制御の詳細については、「Autoscaling with self-hosted runners (セルフホスト ランナーの自動スケール)」を参照してください。オペレーティング システムおよび他のすべてのソフトウェアは、お客様の責任で更新する必要があります。
  • 既に料金を支払っているクラウド サービスまたはローカル マシンを使用することができます。
  • ハードウェア、オペレーティング システム、ソフトウェア、セキュリティの要件に合わせてカスタマイズできます。
  • ジョブを実行するたびにクリーンなインスタンスを用意する必要はありません。
  • GitHub Actions と共に無料で利用できますが、ランナー マシンのメンテナンス コストは、お客様の負担となります。
  • 特定のワークフロー、組織、リポジトリへのアクセスを制限するために、グループに編成できます。 詳細については、「グループを使用してセルフホスト ランナーへのアクセスを管理する」を参照してください。

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

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

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

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

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

Usage limits (使用状況の制限)

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

  • ワークフローの実行時間 - 各ワークフローの実行は 35 日までに制限されます。 ワークフローの実行がこの制限に達すると、そのワークフローの実行はキャンセルされます。 この期間には、実行時間と、待機と承認に費やされた時間が含まれます。
  • ジョブ キューの時間 - セルフホスト ランナーの各ジョブは、最大 24 時間キューに入れておくことができます。 この制限内にセルフホストランナーがジョブの実行を開始しなければ、ジョブは終了させられ、完了に失敗します。
  • API 要求 - 1 時間に実行できる GitHub API への要求は、1 つのリポジトリの全アクションで最大 1000 までです。 要求超過になると、それ以上の API 呼び出しは失敗し、それによってジョブが失敗する可能性があります。
  • ジョブ マトリックス - ジョブマトリックスは、ワークフローの実行ごとに最大で256のジョブを生成できます。 この制限は、GitHub Enterprise Server ホスト ランナーとセルフホステッド ランナーの両方に適用されます。 - ワークフロー実行キュー - リポジトリあたり 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 2019 64-bit

macOS

  • macOS 10.13 (High Sierra)以降

アーキテクチャ

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

  • x64 - Linux、macOS、Windows。
  • ARM64 - Linux。
  • ARM32 - Linux。

セルフホステッド ランナーでサポートされるアクション

GitHub Enterprise Server で GitHub.com のアクションを使用する場合、またはインターネット アクセスのないセルフホスト ランナーで actions/setup-LANGUAGE アクションを使用する場合は、いくつかの追加構成が必要になることがあります。 詳細については、「GitHub.com からのアクションへのアクセスを管理する」を参照し、GitHub Enterprise サイト管理者にお問い合わせください。

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

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

セルフホステッド ランナーと GitHub Enterprise Server の接続は、HTTP (ポート 80) または HTTPS (ポート 443) を経由します。 HTTPS 経由で確実に接続するには、your GitHub Enterprise Server instance に対して TLS を構成します。 詳細については、「TLS の構成」を参照してください。

ランナーから your GitHub Enterprise Server instance へのアウトバウンド接続のみが必要です。 your GitHub Enterprise Server instance からランナーへのインバウンド接続は必要ありません。 キャッシュを機能させるには、ランナーに、BLOB ストレージと通信して、そこからコンテンツを直接ダウンロードできる機能が必要です。

GitHub Enterprise Server は、your GitHub Enterprise Server instance のホスト名と API サブドメインで、ランナーからの HTTP(S) 経由のインバウンド接続を受け入れる必要があります。ランナーは、your GitHub Enterprise Server instance のホスト名と API サブドメインへの、HTTP(S) 経由のアウトバウンド接続を許可する必要があります。

セルフホスト ランナーは、外部のインターネット アクセスを必要とせずに機能します。 その結果、ネットワーク ルーティングを使って、セルフホステッド ランナーと your GitHub Enterprise Server instance の間の通信を制御できます。 たとえば、プライベート IP アドレスをセルフホステッド ランナーに割り当て、トラフィックを your GitHub Enterprise Server instance に送信するようにルーティングを構成できます。トラフィックが公衆ネットワークを通過する必要はありません。

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

一般的なネットワーク接続の問題のトラブルシューティングの詳細については、「Monitoring and troubleshooting self-hosted runners (セルフホスト ランナーの監視とトラブルシューティング)」を参照してください。

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

your GitHub Enterprise Server instance の GitHub.com アクションへの自動アクセスを有効にしている場合を除き、セルフホステッド ランナーが GitHub.com に接続する必要はありません。 詳細については、「エンタープライズでのアクションの使用について」を参照してください。

GitHub.com アクションへの自動アクセスを有効にした場合、セルフホスト ランナーでは GitHub.com に直接接続してアクションをダウンロードします。 下記の GitHub の URL と通信するための適切なネットワークアクセスがマシンにあることを確認する必要があります。

github.com
api.github.com
codeload.github.com

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

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

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

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

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

参考資料