より大きなランナーの概要
標準の GitHub ホスト ランナーに加えて、GitHub では、GitHub Team と GitHub Enterprise Cloud プランのお客様にも、より多くの RAM と CPU を備えたさまざまなより大きなランナーを提供しています。 これらのランナーは、GitHub によってホストされ、ランナー アプリケーションとその他のツールをプレインストールしています。
Organization で より大きなランナー が有効になっている場合、事前に構成された 4 つの より大きなランナー のセットを使って、既定のランナー グループが自動的に作成されます。
より大きなランナーを Organization に追加する場合は、使用可能なハードウェア仕様とオペレーティング システム イメージから選んだマシンの種類を定義します。 GitHub では、定義した自動スケールの制限に基づき、Organization のジョブの需要に合わせてスケールアップおよびスケールダウンする、このランナーの複数のインスタンスが作成されます。
より大きなランナー 用のコンピューターの仕様
| サイズ (vCPU) | メモリ (GB) | ストレージ (SSD) |
|---|---|---|
| 4 コア | 16 RAM | 150 GB |
| 8 コア | 32 RAM | 300 GB |
| 16 コア | 64 RAM | 600 GB |
| 32 コア | 128 RAM | 1200 GB |
| 64 コア | 256 RAM | 2040 GB |
より大きなランナーのアーキテクチャの概要
より大きなランナーは Organization レベルで管理され、ランナーの複数のインスタンスを含むことができるグループに配置されます。 また、Enterprise レベルで作成し、階層内の Organization と共有することもできます。 グループを作成したら、ランナーをグループに追加し、ワークフローを更新して、より大きなランナーに割り当てられたグループ名またはラベルをターゲットにすることができます。 また、処理のためにグループにジョブを送信できるリポジトリも制御できます。 グループについて詳しくは、「より大きなランナーへのアクセスの制御」を参照してください。
次の図では、ubuntu-20.04-16core という名前のホストされたランナーのクラスが、カスタマイズされたハードウェアとオペレーティング システムの構成で定義されています。

- このランナーのインスタンスは自動的に作成され、
grp-ubuntu-20.04-16coreというグループに追加されます。 - ランナーにはラベル
ubuntu-20.04-16coreが割り当てられています。 - ワークフロー ジョブは、
runs-onキーのubuntu-20.04-16coreラベルを使用して、ジョブの実行に必要なランナーの種類を示します。 - GitHub Actions は、ランナー グループをチェックして、リポジトリがランナーにジョブを送信する権限があるかどうかを確認します。
- このジョブは、
ubuntu-20.04-16coreランナーの次に使用可能なインスタンスで実行されます。
より大きなランナーの自動スケーリング
より大きなランナーは、ニーズに合わせて自動的にスケーリングするように構成できます。 ジョブが処理のために送信されると、事前に定義された上限に達するまで、ジョブを実行するために、より多くのマシンを自動的にプロビジョニングできます。 各マシンは一度に 1 つのジョブのみを処理するため、これらの設定によって、同時に実行できるジョブの数が効率的に決定されます。
ランナーの展開プロセス中に [最大] オプションを構成できます。これにより、このセットで並行して作成されるマシンの最大数を設定してコストを制御できます。 この値を大きくすると、並列処理によってワークフローがブロックされるのを回避できます。
より大きなランナーのネットワーク
既定では、より大きなランナーは、ジョブの実行ごとに変更される動的 IP アドレスを受け取ります。 必要に応じて、GitHub Enterprise Cloud のお客様は、より大きなランナーを構成して、GitHub の IP アドレス プールから静的 IP アドレスを受信できます。 有効にすると、より大きなランナーのインスタンスは、ランナーに固有の範囲からアドレスを受け取り、この範囲を使用してファイアウォール許可リストを構成できます。 より大きなランナーs
注: ランナーが 30 日以上使用されていない場合、その IP アドレス範囲は自動的に削除され、回復することができません。
より大きなランナーの計画
ランナー グループを作成する
ランナー グループは、仮想マシンのセットを収集し、その周囲にセキュリティ境界を作成するために使用されます。 その後、それらのマシン セットでジョブを実行できる Organization またはリポジトリを決定できます。 より大きなランナーの展開プロセス中に、ランナーを既存のグループに追加することも、既定のグループに参加させることもできます。 「より大きなランナーへのアクセスの制御」の手順に従ってグループを作成できます。
課金について
注: より大きなランナー は、含まれるエンタイトルメント分数を使わず、パブリック リポジトリについて無料ではありません。
標準の GitHub ホスト ランナーと比較すると、より大きなランナーの課金方法は異なります。 詳しくは、「1 分あたりの料金」を参照してください。
Enterprise へのより大きなランナーの追加
より大きなランナーを Enterprise に追加して、複数の Organization に割り当てることができます。 Organization の管理者は、そのランナーを使用できるリポジトリを制御できます。 より大きなランナーを Enterprise に追加するには、Enterprise の所有者である必要があります。
使用可能なオプションのリストから、オペレーティング システムとハードウェア構成を選ぶことができます。 このランナーの新しいインスタンスが自動スケーリングによってデプロイされると、ここで定義したオペレーティング システムとハードウェア構成が使用されます。
また、ランナーを識別するラベルを定義することもできます。これは、処理のためにワークフローを使ってランナーにジョブを送信する方法です (runs-on を使います)。 新しいランナーが既定のグループに自動的に割り当てられるか、ランナー作成プロセス中にランナーを結合する必要があるグループを選ぶことができます。 また、ランナーを登録した後で、ランナーのグループ メンバーシップを変更できます。 詳しくは、「より大きなランナーへのアクセスの制御」を参照してください。
-
Enterprise アカウントのサイドバーで、 [ポリシー] をクリックします。 1. [ ポリシー] で、 [アクション] をクリックします。 1. [Runners](ランナー) タブをクリックします。 1. [新しいランナー] をクリックしてから、 [新しいGitHub-ホステッド ランナー] をクリックします。
-
必要な詳細を入力して、新しいランナーを構成します。
- 名前: 新しいランナーの名前を入力します。 識別しやすくするには、ハードウェアとオペレーティング システム (
ubuntu-20.04-16coreなど) を示しておくのがよいでしょう。 - ランナー イメージ: 使用可能なオプションからオペレーティング システムを選びます。 オペレーティング システムを選ぶと、特定のバージョンを選ぶことができるようになります。
- ランナーのサイズ: 使用可能なオプションのドロップダウン リストからハードウェア構成を選びます。
- 自動スケーリング: いつでもアクティブにすることができるランナーの最大数を選びます。
- ランナー グループ: ランナーがメンバーとなるグループを選びます。 需要に合わせてスケールアップまたはスケールダウンしながら、このグループによって、ランナーのインスタンスが複数ホストされます。
- ネットワーク: GitHub Enterprise Cloud の場合のみ、静的 IP アドレス範囲を より大きなランナー のインスタンスに割り当てるかどうかを選びます。 合計で最大 10 個の静的 IP アドレスを使うことができます。
- 名前: 新しいランナーの名前を入力します。 識別しやすくするには、ハードウェアとオペレーティング システム (
-
[ランナーの作成] をクリックします。
-
Organization がより大きなランナーにアクセスできるようにするには、それを使用できる Organization の一覧を指定します。 詳しくは、「ランナーへのアクセスの管理」を参照してください。
Organization へのより大きなランナーの追加
より大きなランナーを Organization に追加できます。ここで、Organization 管理者は、それを使用できるリポジトリを制御できます。
使用可能なオプションのリストから、オペレーティング システムとハードウェア構成を選ぶことができます。 このランナーの新しいインスタンスが自動スケーリングによってデプロイされると、ここで定義したオペレーティング システムとハードウェア構成が使用されます。
また、ランナーを識別するラベルを定義することもできます。これは、処理のためにワークフローを使ってランナーにジョブを送信する方法です (runs-on を使います)。 新しいランナーが既定のグループに自動的に割り当てられるか、ランナー作成プロセス中にランナーを結合する必要があるグループを選ぶことができます。 また、ランナーを登録した後で、ランナーのグループ メンバーシップを変更できます。 詳しくは、「より大きなランナーへのアクセスの制御」を参照してください。
-
GitHub.com で、Organization のメイン ページへ移動します。 1. Organization 名の下で、 [設定] をクリックします。
1. 左側のサイドバーで、 [アクション] 、 [ランナー] の順にクリックします。 1. [新しいランナー] をクリックしてから、 [新しいGitHub-ホステッド ランナー] をクリックします。 -
必要な詳細を入力して、新しいランナーを構成します。
- 名前: 新しいランナーの名前を入力します。 識別しやすくするには、ハードウェアとオペレーティング システム (
ubuntu-20.04-16coreなど) を示しておくのがよいでしょう。 - ランナー イメージ: 使用可能なオプションからオペレーティング システムを選びます。 オペレーティング システムを選ぶと、特定のバージョンを選ぶことができるようになります。
- ランナーのサイズ: 使用可能なオプションのドロップダウン リストからハードウェア構成を選びます。
- 自動スケーリング: いつでもアクティブにすることができるランナーの最大数を選びます。
- ランナー グループ: ランナーがメンバーとなるグループを選びます。 需要に合わせてスケールアップまたはスケールダウンしながら、このグループによって、ランナーのインスタンスが複数ホストされます。
- ネットワーク: GitHub Enterprise Cloud の場合のみ、静的 IP アドレス範囲を より大きなランナー のインスタンスに割り当てるかどうかを選びます。 合計で最大 10 個の静的 IP アドレスを使うことができます。
- 名前: 新しいランナーの名前を入力します。 識別しやすくするには、ハードウェアとオペレーティング システム (
-
[ランナーの作成] をクリックします。
-
リポジトリがより大きなランナーにアクセスできるようにするには、それを使用できるリポジトリの一覧に追加します。 詳しくは、「ランナーへのアクセスの管理」を参照してください。
ランナーでのジョブの実行
ランナーの種類が定義されたら、ワークフローの YAML ファイルを更新し、処理のために新しく作成されたランナー インスタンスにジョブを送信できます。 ランナー グループまたはラベルを使用して、ジョブが実行される場所を定義することができます。
ランナーの設定を表示できるのは、所有者または管理者アカウントのみです。 管理者以外のユーザーは、組織の管理者に連絡して、有効になっているランナーを確認できます。 組織の管理者は、新しいランナーとランナー グループを作成したり、ランナー グループにアクセスできるリポジトリを指定するためのアクセス許可を構成したりできます。
グループを使用してジョブの実行場所を制御する
この例では、Ubuntu ランナーが ubuntu-runners というグループに追加されています。 runs-on キーは、ubuntu-runners グループ内の使用可能なランナーにジョブを送信します。
name: learn-github-actions
on: [push]
jobs:
check-bats-version:
runs-on:
group: ubuntu-runners
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: '14'
- run: npm install -g bats
- run: bats -v
ラベルを使用してジョブの実行場所を制御する
この例では、ランナー グループに、ラベル ubuntu-20.04-16core も割り当てられている Ubuntu 16-core ランナーが設定されています。 runs-on キーは、一致するラベルを持つ使用可能なランナーにジョブを送信します。
name: learn-github-actions
on: [push]
jobs:
check-bats-version:
runs-on:
labels: ubuntu-20.04-16core
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: '14'
- run: npm install -g bats
- run: bats -v
ラベルとグループを使用してジョブの実行場所を制御する
グループとラベルを組み合わせる場合、ランナーはジョブを実行する資格を得るために両方の要件を満たす必要があります。
この例では、ubuntu-runners というランナー グループに、ラベル ubuntu-20.04-16core も割り当てられている Ubuntu ランナーが設定されています。 runs-on キーは group と labels を組み合わせて、ラベルが一致するグループ内の使用可能な任意のランナーにジョブがルーティングされるようにします。
name: learn-github-actions
on: [push]
jobs:
check-bats-version:
runs-on:
group: ubuntu-runners
labels: ubuntu-20.04-16core
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: '14'
- run: npm install -g bats
- run: bats -v
複数のラベルを使用する
ランナー上でジョブを実行するために一致する必要がある複数のラベルを指定することができます。 ランナーは、ジョブを実行する資格を持つすべてのラベルと一致する必要があります。
この例では、ランナーは、ジョブを実行するために 3 つすべてのラベルと一致する必要があります。
name: learn-github-actions
on: [push]
jobs:
check-bats-version:
runs-on:
labels: [ ubuntu-20.04-16core, gpu, qa ]
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: '14'
- run: npm install -g bats
- run: bats -v
ランナーへのアクセスの管理
注: ワークフローがより大きなランナーにジョブを送信できるようにするには、まずランナー グループのアクセス許可を構成する必要があります。 詳しくは、以下のセクションをご覧ください。
ランナー グループは、より大きなランナーでジョブを実行できるリポジトリを制御するために使用されます。 より大きなランナーを定義した場所に応じて、管理階層の各レベルからグループへのアクセス権を付与する必要があります。
- Enterprise レベルのランナー: 必要なすべての Organization へのアクセス権を付与するようにランナー グループを構成します。 さらに、Organization ごとに、アクセスが許可されたリポジトリを指定するようにグループを構成する必要があります。
- Organization レベルのランナー: アクセスが許可されたリポジトリを指定して、ランナー グループを構成します。
たとえば、次の図には、Enterprise レベルに grp-ubuntu-20.04-16core という名前のランナー グループがあります。 octo-repo という名前のリポジトリがグループ内のランナーを使用できるようにするには、まず、octo-org Organization からのアクセスを許可するように Enterprise レベルでグループを構成する必要があります。次に、octo-repo からのアクセスを許可するように Organization レベルでグループを構成する必要があります。

リポジトリによるランナー グループへのアクセスの許可
この手順では、Enterprise と Organization のレベルでグループのアクセス許可を構成する方法を示します。
- ランナー グループが配置されている、リポジトリまたは Organization のメイン ページに移動します。
- [設定] をクリックします。
- 左側のサイド バーで、 [Actions] (アクション) 、 [Runner groups] (ランナー グループ) の順にクリックします。 1. グループのリストで、構成するランナー グループをクリックします。
- Enterprise のランナー グループの場合、 [Organization のアクセス] で、ランナー グループにアクセスできる Organization を変更します。
- Organization のランナー グループの場合、 [リポジトリ アクセス] で、ランナー グループにアクセスできるリポジトリを変更します。
警告:
固定 IP 範囲を使っている場合、プライベート リポジトリには より大きなランナー のみを使うことをお勧めします。 ワークフロー内でコードを実行する pull request を作成することで、リポジトリのフォークによって、より大きなランナー 上で危険なコードが実行される可能性があります。
詳しくは、「より大きなランナーへのアクセスの制御」を参照してください。

