より大きなランナーの概要
標準の GitHub ホスト ランナーに加えて、GitHub では、GitHub Team と GitHub Enterprise Cloud プランのお客様にも、より多くの RAM と CPU を備えたさまざまなより大きなランナーを提供しています。 これらのランナーは、GitHub によってホストされ、ランナー アプリケーションとその他のツールをプレインストールしています。
Organization で より大きなランナー が有効になっている場合、事前に構成された 4 つの より大きなランナー のセットを使って、既定のランナー グループが自動的に作成されます。
より大きなランナーを Organization に追加する場合は、使用可能なハードウェア仕様とオペレーティング システム イメージから選んだマシンの種類を定義します。 GitHub では、定義した自動スケールの制限に基づき、Organization のジョブの需要に合わせてスケールアップおよびスケールダウンする、このランナーの複数のインスタンスが作成されます。
より大きなランナー 用のコンピューターの仕様
サイズ (vCPU) | メモリ (RAM) | ストレージ (SSD) |
---|---|---|
4 コア | 16 GB | 150 GB |
8 コア | 32 GB | 300 GB |
16 コア | 64 GB | 600 GB |
32 コア | 128 GB | 1200 GB |
64 コア | 256 GB | 2040 GB |
より大きなランナーのその他の機能
GitHub にホストされている標準のものと比較すると、より大きなランナーには、次の機能が追加であります。
- Ubuntu ランナーでは、Android SDK ツールでのハードウェア アクセラレーションが有効になっています。 これは、Android のテストをはるかに速くし、実行分数も短くします。 Android ハードウェア アクセラレーションについて詳しくは、Android 開発者向けのドキュメントをご覧ください。
各ランナー オペレーティング システムに含まれるツールの完全な一覧については、GitHub Actions ランナー イメージ リポジトリをご覧ください。
より大きなランナーのアーキテクチャの概要
より大きなランナーは 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 アドレスを受信できます。 有効にすると、より大きなランナーのインスタンスは、ランナーに固有の範囲からアドレスを受け取り、この範囲を使用してファイアウォール許可リストを構成できます。 全体で合計で最大 10 個の静的 IP アドレス範囲を使用できます。エンタープライズ レベルで作成された より大きなランナーには、最大 10 個の静的 IP アドレス範囲を使用できます。 さらに、Enterprise 内の Organization ごとに、Organization レベルで作成された より大きなランナー に対して最大 10 個の静的 IP アドレス範囲を使用できます。
注: ランナーが 30 日以上使用されていない場合、その IP アドレス範囲は自動的に削除され、回復することができません。
より大きなランナーの計画
ランナー グループを作成する
ランナー グループは、仮想マシンのセットを収集し、その周囲にセキュリティ境界を作成するために使用されます。 その後、それらのマシン セットでジョブを実行できる Organization またはリポジトリを決定できます。 より大きなランナーの展開プロセス中に、ランナーを既存のグループに追加することも、既定のグループに参加させることもできます。 グループは、「より大きなランナーへのアクセスの制御」の手順に従って作ることができます。
課金について
注: より大きなランナー は、含まれるエンタイトルメント分数を使わず、パブリック リポジトリについて無料ではありません。
標準の GitHub ホスト ランナーと比較すると、より大きなランナーの課金方法は異なります。 詳しくは、「GitHub Actions の課金について」をご覧ください。
Enterprise へのより大きなランナーの追加
より大きなランナーを Enterprise に追加して、複数の Organization に割り当てることができます。 Organization の管理者は、そのランナーを使用できるリポジトリを制御できます。 より大きなランナーを Enterprise に追加するには、Enterprise の所有者である必要があります。
使用可能なオプションのリストから、オペレーティング システムとハードウェア構成を選ぶことができます。 このランナーの新しいインスタンスが自動スケーリングによってデプロイされると、ここで定義したオペレーティング システムとハードウェア構成が使用されます。
新しいランナーが既定のグループに自動的に割り当てられるか、ランナー作成プロセス中にランナーを結合する必要があるグループを選ぶことができます。 また、ランナーを登録した後で、ランナーのグループ メンバーシップを変更できます。 詳しくは、「より大きなランナーへのアクセスの制御」を参照してください。
-
GitHub.com の右上の自分のプロファイル写真をクリックし、 [自分の Enterprise] をクリックします。
-
Enterpriseのリストで、表示したいEnterpriseをクリックしてください。
-
Enterprise アカウントのサイドバーで、 [ポリシー] をクリックします。 1. [ ポリシー] で、 [アクション] をクリックします。 1. [Runners](ランナー) タブをクリックします。 1. [新しいランナー] をクリックしてから、 [新しいGitHub-ホステッド ランナー] をクリックします。
-
必要な詳細を入力して、新しいランナーを構成します。
- 名前: 新しいランナーの名前を入力します。 識別しやすくするには、ハードウェアとオペレーティング システム (
ubuntu-20.04-16core
など) を示しておくのがよいでしょう。 - ランナー イメージ: 使用可能なオプションからオペレーティング システムを選びます。 オペレーティング システムを選ぶと、特定のバージョンを選ぶことができるようになります。
- ランナーのサイズ: 使用可能なオプションのドロップダウン リストからハードウェア構成を選びます。
- 自動スケーリング: いつでもアクティブにすることができるランナーの最大数を選びます。
- ランナー グループ: ランナーがメンバーとなるグループを選びます。 需要に合わせてスケールアップまたはスケールダウンしながら、このグループによって、ランナーのインスタンスが複数ホストされます。
- ネットワーク: GitHub Enterprise Cloud の場合のみ、静的 IP アドレス範囲を より大きなランナー のインスタンスに割り当てるかどうかを選びます。 合計で最大 10 個の静的 IP アドレスを使うことができます。
- 名前: 新しいランナーの名前を入力します。 識別しやすくするには、ハードウェアとオペレーティング システム (
-
[ランナーの作成] をクリックします。
-
Organization がより大きなランナーにアクセスできるようにするには、それを使用できる Organization の一覧を指定します。 詳しくは、「ランナーへのアクセスの管理」を参照してください。
Organization へのより大きなランナーの追加
より大きなランナーを Organization に追加できます。ここで、Organization 管理者は、それを使用できるリポジトリを制御できます。
使用可能なオプションのリストから、オペレーティング システムとハードウェア構成を選ぶことができます。 このランナーの新しいインスタンスが自動スケーリングによってデプロイされると、ここで定義したオペレーティング システムとハードウェア構成が使用されます。
新しいランナーが既定のグループに自動的に割り当てられるか、ランナー作成プロセス中にランナーを結合する必要があるグループを選ぶことができます。 また、ランナーを登録した後で、ランナーのグループ メンバーシップを変更できます。 詳しくは、「より大きなランナーへのアクセスの制御」を参照してください。
-
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
ランナー グループに一意の名前を使用する
GitHub Actions では、ランナー グループ名が Organization レベルで一意である必要があります。 つまり、Organization は、Enterprise 内のランナー グループと同じ名前を持つものを作成できなくなります。 さらに、ユーザーには、Enterprise 内のグループと同じ名前を共有するすべてのランナー グループに、Organization グループの名前を変更することを提案する警告バナーが表示されます。
あいまいさを回避するために、Organization と Enterprise に重複するランナー グループがある場合、ワークフローは失敗します。 これに対処するには、Organization 内または Enterprise のいずれかのランナー グループの名前を変更するか、ワークフロー ファイルを更新してランナー グループ名にプレフィックスを追加します。
org/
またはorganization/
ent/
またはenterprise/
例: プレフィックスを使用してランナー グループを区別する
たとえば、Organization 内に my-group
という名前のランナー グループがあり、Enterprise 内に my-group
という名前のランナー グループがある場合は、ワークフロー ファイルを更新して、org/my-group
または ent/my-group
を使用して 2 つを区別できます。
org/
の使用
runs-on:
group: org/my-group
labels: [ self-hosted, label-1 ]
ent/
の使用
runs-on:
group: ent/my-group
labels: [ self-hosted, label-1 ]
ランナーへのアクセスの管理
注: ワークフローがより大きなランナーにジョブを送信できるようにするには、まずランナー グループのアクセス許可を構成する必要があります。 詳しくは、以下のセクションをご覧ください。
ランナー グループは、より大きなランナーでジョブを実行できるリポジトリを制御するために使用されます。 より大きなランナーを定義した場所に応じて、管理階層の各レベルからグループへのアクセス権を付与する必要があります。
- Enterprise レベルのランナー: 必要なすべての Organization へのアクセス権を付与するようにランナー グループを構成します。 さらに、Organization ごとに、アクセスが許可されたリポジトリを指定するようにグループを構成する必要があります。
- Organization レベルのランナー: アクセスが許可されたリポジトリを指定して、ランナー グループを構成します。
たとえば、次の図には、Enterprise レベルに grp-ubuntu-20.04-16core
という名前のランナー グループがあります。 octo-repo
という名前のリポジトリがグループ内のランナーを使用できるようにするには、まず、octo-org
Organization からのアクセスを許可するように Enterprise レベルでグループを構成する必要があります。 次に、octo-repo
からのアクセスを許可するように Organization レベルでグループを構成する必要があります。
リポジトリによるランナー グループへのアクセスの許可
この手順では、Enterprise と Organization のレベルでグループのアクセス許可を構成する方法を示します。
-
ランナー グループが配置されている場所に移動します。
-
Organization 内: メイン ページに移動して、 [設定] をクリックします。
-
Enterprise レベルのグループを使用している場合:
-
GitHub.com の右上の自分のプロファイル写真をクリックし、 [自分の Enterprise] をクリックします。
-
Enterpriseのリストで、表示したいEnterpriseをクリックしてください。
-
-
-
[ランナー グループ] 設定に移動します:
-
Organization 内:
- 左側のサイド バーで、 [アクション] 、 [ランナー グループ] の順にクリックします。
-
Enterprise レベルのグループを使用している場合:
- Enterprise アカウントのサイドバーで、 [ポリシー] をクリックします。 1. [ ポリシー] で、 [アクション] をクリックします。 1. [ランナー グループ] タブをクリックします。 1. グループのリストで、構成するランナー グループをクリックします。
-
- Enterprise のランナー グループの場合、 [Organization のアクセス] で、ランナー グループにアクセスできる Organization を変更します。
- Organization のランナー グループの場合、 [リポジトリ アクセス] で、ランナー グループにアクセスできるリポジトリを変更します。
警告:
固定 IP 範囲を使っている場合、プライベート リポジトリには より大きなランナー のみを使うことをお勧めします。 ワークフロー内でコードを実行する pull request を作成することで、リポジトリのフォークによって、より大きなランナー 上で危険なコードが実行される可能性があります。
詳しくは、「より大きなランナーへのアクセスの制御」を参照してください。