より大きなランナーの使用

より大きなランナーの概要

標準の 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 と Organization が所有する 2 つのリポジトリの間のロックを示す図。

リポジトリによるランナーグループへのアクセスの許可

この手順では、Enterprise と Organization のレベルでグループのアクセス許可を構成する方法を示します。

ランナーグループが配置されている場所に移動します。
- Organization 内: メインページに移動して、 [設定] をクリックします。
- Enterprise レベルのグループを使用している場合:
  1. GitHub.com の右上の自分のプロファイル写真をクリックし、 [自分の Enterprise] をクリックします。
  2. Enterpriseのリストで、表示したいEnterpriseをクリックしてください。
[ランナーグループ] 設定に移動します:
- Organization 内:
  1. 左側のサイドバーで、 [アクション] 、 [ランナーグループ] の順にクリックします。
- Enterprise レベルのグループを使用している場合:
  1. Enterprise アカウントのサイドバーで、 [ポリシー] をクリックします。 1. [ ポリシー] で、 [アクション] をクリックします。 1. [ランナーグループ] タブをクリックします。 1. グループのリストで、構成するランナーグループをクリックします。

Enterprise のランナーグループの場合、 [Organization のアクセス] で、ランナーグループにアクセスできる Organization を変更します。
Organization のランナーグループの場合、 [リポジトリアクセス] で、ランナーグループにアクセスできるリポジトリを変更します。

警告:

固定 IP 範囲を使っている場合、プライベートリポジトリにはより大きなランナーのみを使うことをお勧めします。ワークフロー内でコードを実行する pull request を作成することで、リポジトリのフォークによって、より大きなランナー上で危険なコードが実行される可能性があります。

詳しくは、「より大きなランナーへのアクセスの制御」を参照してください。