GitHub ホステッド ランナーの概要

GitHub ホステッド ランナーの概要

ランナーは、GitHub Actions ワークフローでジョブを実行するマシンです。 たとえば、ランナーはリポジトリをローカルにクローンし、テスト ソフトウェアをインストールしてから、コードを評価するコマンドを実行できます。

GitHub は、ジョブの実行に使用できるランナーを提供します。または、独自のランナーをホストすることもできます。 各 GitHub ホステッド ランナーは、ランナー アプリケーションとその他のツールがプレインストールされた GitHub によってホストされる新しい仮想マシン (VM) であり、Ubuntu Linux、Windows、または macOS オペレーティング システムで使用できます。 GitHubホストランナーを使用すると、マシンのメンテナンスとアップグレードが自動的に行われます。

標準の GitHub ホステッド ランナー オプションのいずれかを選択できます。あるいは、GitHub Team プランまたは GitHub Enterprise Cloud プランの場合は、より多くのコアを持つランナー、または GPU または ARM プロセッサを搭載したランナーをプロビジョニングできます。 これらのマシンは "より大きなランナー" と呼ばれます。 詳しくは、「より大きなランナーの概要」をご覧ください。

GitHub ホステッド ランナーを使用するには、アップロードおよびダウンロード速度が 70 kbps 以上のネットワーク アクセスが必要です。

GitHub ホステッド ランナーの使用

GitHub ホステッド ランナーを使用するには、ジョブを作成し、runs-on を使用してジョブを処理するランナーの種類を指定します (例: ubuntu-latest、windows-latest、または macos-latest)。 ランナーの種類の完全な一覧については、「GitHub ホステッド ランナーの概要repo: write」をご覧ください。リポジトリに対する アクセス権がある場合は、リポジトリ内のワークフローで使用できるランナーの一覧を表示できます。 詳しくは、「リポジトリで使用可能なランナーの表示」をご覧ください。

ジョブが開始されると、GitHub によって、そのジョブの新しい VM が自動的にプロビジョニングされます。 ジョブ中のすべてのステップは VM で実行されるため、ランナーのファイルシステムを使用して、そのジョブにおけるステップで情報を共有することができます。 ワークフローは、VM で直接実行することも、Docker コンテナーで実行することもできます。 ジョブが完了すると、VM は自動的に使用停止になります。

次のダイアグラムは、2 つの異なる GitHub ホステッド ランナーでワークフロー内の 2 つのジョブがどのように実行されるかを示しています。

次のワークフロー例には、Run-npm-on-Ubuntu および Run-PSScriptAnalyzer-on-Windows という名前のついた 2 つのジョブがあります。 このワークフローがトリガーされると、GitHub ではジョブごとに新しい仮想マシンをプロビジョニングします。

• Run-npm-on-Ubuntu という名前のジョブは Linux VM で実行されます。これは、ジョブの runs-on: で ubuntu-latest が指定されているためです。
• Run-PSScriptAnalyzer-on-Windows という名前のジョブは Windows VM で実行されます。これは、ジョブの runs-on: で windows-latest が指定されているためです。

name: Run commands on different operating systems
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  Run-npm-on-Ubuntu:
    name: Run npm on Ubuntu
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '14'
      - run: npm help

  Run-PSScriptAnalyzer-on-Windows:
    name: Run PSScriptAnalyzer on Windows
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install PSScriptAnalyzer module
        shell: pwsh
        run: |
          Set-PSRepository PSGallery -InstallationPolicy Trusted
          Install-Module PSScriptAnalyzer -ErrorAction Stop
      - name: Get list of rules
        shell: pwsh
        run: |
          Get-ScriptAnalyzerRule

name: Run commands on different operating systems
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  Run-npm-on-Ubuntu:
    name: Run npm on Ubuntu
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '14'
      - run: npm help

  Run-PSScriptAnalyzer-on-Windows:
    name: Run PSScriptAnalyzer on Windows
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install PSScriptAnalyzer module
        shell: pwsh
        run: |
          Set-PSRepository PSGallery -InstallationPolicy Trusted
          Install-Module PSScriptAnalyzer -ErrorAction Stop
      - name: Get list of rules
        shell: pwsh
        run: |
          Get-ScriptAnalyzerRule

ジョブの実行中、ログと出力は GitHub UI で表示できます。

GitHub Actionsランナーアプリケーションはオープンソースです。 ランナー リポジトリでイシューを投稿およびファイルできます。

リポジトリで使用可能なランナーの表示

リポジトリに repo: write アクセス許可を持つ場合は、リポジトリで使用できるランナーの一覧が表示されます。

1. GitHub で、リポジトリのメイン ページに移動します。

2. リポジトリ名の下にある [アクション] をクリックします。

   

3. 左サイドバーの [管理] セクションで、[ランナー] をクリックします。

4. リポジトリで使用可能な GitHub ホステッド ランナーの一覧を確認します。

5. 必要に応じて、ランナーのラベルをコピーしてワークフローで使用するには、ランナーの右側にある をクリックし、[ラベルのコピー] をクリックします。

サポートされているランナーとハードウェアリソース

GitHub ホスト ランナーは、パブリック リポジトリとプライベート リポジトリの両方で使用できます。

GitHub ホスト型 Linux ランナーは、Android SDK ツールのハードウェア アクセラレーションをサポートしています。これにより、Android テストの実行が大幅に高速化され、使用時間が短縮されます。 Android ハードウェア アクセラレーションの詳細については、Android Developers ドキュメントの「Android Emulator のハードウェア アクセラレーションを設定する」を参照してください。

パブリック リポジトリの標準の GitHub でホストされたランナー

パブリック リポジトリの場合、次の表に示すワークフロー ラベルを使用するジョブは、関連付けられた仕様を持つ仮想マシンで実行されます。 パブリック リポジトリでのこれらのランナーの使用は無料で無制限です。

内部および プライベート リポジトリの標準の GitHub でホストされたランナー

内部および プライベート リポジトリの場合、次の表に示すワークフロー ラベルを使用するジョブは、関連付けられた仕様を持つ仮想マシンで実行されます。 これらのランナーは、GitHub アカウントの無料の分の割り当てを使用し、分単位の料金で課金されます。 詳しくは、「GitHub Actions の課金について」を参照してください。

ワークフローログには、ジョブの実行に使用されたランナーが一覧表示されます。 詳しくは、「ワークフロー実行の履歴を表示する」をご覧ください。

arm64 macOS ランナーの制限事項

• GitHub によって提供されるすべてのアクションは、arm64 GitHub ホストランナーと互換性があります。 ただし、コミュニティ アクションは arm64 と互換性がない場合があり、実行時に手動でインストールする必要があります。
• Apple の仮想化フレームワークの制限により、入れ子になった仮想化と Metal Performance Shaders (MPS) はサポートされていません。
• 現在、macOS の大規模ランナーでは、Azure プライベート ネットワークや静的 IP の割り当てなどのネットワーク機能は使用できません。
• Apple ではこの機能がサポートされていないため、arm64 macOS ランナーには、静的 UUID/UDID が割り当てされていません。 ただし、Intel MacOS ランナーには、静的 UDID、特に 4203018E-580F-C1B5-9525-B745CECA79EB が割り当てられます。 ビルドをテストする予定の同じホストでビルドして署名する場合は、開発プロビジョニング プロファイルを使用して署名できます。 静的 UDID が必要な場合は、Intel ランナーを使用して、その UDID を Apple Developer アカウントに追加できます。
• macOS ランナーは、GHE.com のサブドメイン (octocorp.ghe.com など) では利用できません。

より大きなランナー

GitHub Team プランと GitHub Enterprise Cloud プランのお客様は、標準の GitHub ホステッド ランナーよりも多くのリソースを持つさまざまなマネージド仮想マシンから選択できます。 これらのマシンは "より大きなランナー" と呼ばれます。 これらには、次の高度な機能が用意されています。

• 追加の RAM、CPU、ディスク領域
• 静的 IP アドレス
• Azure プライベート ネットワーク
• ランナーをグループ化する機能
• 同時実行ワークフローをサポートするための自動スケール
• GPU 搭載ランナーと ARM 搭載ランナー

これらの より大きなランナー (larger runner) は、GitHub によってホストされ、ランナー アプリケーションとその他のツールをプレインストールしています。

詳しくは、「より大きなランナーの使用」をご覧ください。

サポートされているソフトウェア

GitHub ホストランナーに含まれているソフトウェアツールは毎週更新されます。 更新プロセスには数日かかり、main ブランチのプレインストール済みソフトウェアのリストは、デプロイ全体が終了した後で更新されます。

プレインストール済みソフトウェア

ワークフローログには、正確なランナーにプレインストールされているツールへのリンクが含まれています。 ワークフローのログでこの情報を見つけるには、Set up job セクションを展開します。 そのセクションの下で、Runner Image セクションを展開します。 Included Software の後のリンクで、ワークフローを実行したランナーにプレインストールされているツールが示されています。

詳しくは、「ワークフロー実行の履歴を表示する」をご覧ください。 各ランナー オペレーティング システムに含まれるツールの全体的なリストについては、ランナー イメージ リポジトリの使用可能なイメージドキュメントを参照してください。

GitHubホストランナーには、オペレーティングシステムのデフォルトの組み込みツールに加え、上のリファレンスのリスト内のパッケージにが含まれています。 たとえば、Ubuntu と macOS のランナーには、他の既定のツールと共に grep、find、which が含まれます。

Windows と Ubuntu のランナー イメージのビルドごとにソフトウェア部品表 (SBOM) を表示することもできます。 詳しくは、「GitHub Actions のセキュリティ強化」をご覧ください。

プレインストール済みソフトウェアを使用する

アクションを使用して、ランナーにインストールされているソフトウェアと対話することをお勧めします。 この方法には、いくつかの利点があります。

• アクションでは通常、バージョンの選択、引数を渡す機能、パラメータなどの機能が提供されています
• これにより、ソフトウェアの更新に関係なく、ワークフローで使用されるツールのバージョンが同じままになります

要求したいツールがある場合は、actions/virtual-environments で issue を開いてください。 このリポジトリには、ランナーに関するすべての主要なソフトウェア更新に関するお知らせも含まれています。

追加ソフトウェアをインストールする

GitHub ホステッド ランナーに追加のソフトウェアをインストールできます。 詳しくは、「GitHub ホステッド ランナーのカスタマイズ」をご覧ください。

GitHub ホステッド ランナーによって使用されるクラウド ホスト

GitHub は、Microsoft Azure の 仮想マシン上で GitHub Actions ランナー アプリケーションがインストールされた Linux および Windows ランナーをホストします。 GitHubホストランナーアプリケーションは、Azure Pipelines Agentのフォークです。 インバウンドのICMPパケットはすべてのAzure仮想マシンでブロックされるので、pingやtracerouteコマンドは動作しないでしょう。 GitHub は、Azure データ センターで macOS ランナーをホストします。

Linux および Windows ランナーの場合には、GitHub は仮想マシン Dadsv5-series 使用します。 詳細については、Microsoft Azure ドキュメントの「Dasv5 および Dadsv5 シリーズ」を参照してください。

GPU ランナーでは、 NCasT4_v3-series 仮想マシンを使用します。 詳しくは、Microsoft Azure ドキュメントの「NCasT4_v3シリーズ」をご覧ください。

ワークフローの継続性

GitHub Actionsサービスが一時的に利用できなくなっている場合、ワークフローの実行はトリガーされてから30分以内にキューイングされていなければ、破棄されます。 たとえば、ワークフローがトリガーされ、そしてGitHub Actionsサービスが31分以上利用できなければ、そのワークフローの実行は処理されません。

さらに、ワークフロー実行が正常にキューに入れられても、45 分以内に GitHub ホステッド ランナーによって処理されない場合、キューのワークフロー実行は破棄されます。

管理者特権

Linux と macOS のどちらの仮想マシンでも、パスワードレスの sudo が実行されます。 現在のユーザーより高い特権が必要なコマンドやインストール ツールを実行する必要がある場合は、パスワードを入力する必要なく、sudo を使うことができます。 詳しくは、Sudo のマニュアルをご覧ください。

Windowsの仮想マシンは、ユーザアカウント制御（UAC）が無効化されて管理者として動作するように設定されています。 詳しくは、Windows のドキュメント「ユーザー アカウント制御のしくみ」をご覧ください。

IP アドレス

GitHub Actions で GitHub ホステッド ランナーに使われる IP アドレス範囲のリストを取得するには、GitHub REST API を使用できます。 詳しくは、actions エンドポイントの応答で GET /meta キーをご覧ください。 詳しくは、「メタデータ用 REST API エンドポイント」をご覧ください。

Windows及びUbuntuのランナーはAzureでホストされており、そのためAzureのデータセンターと同じIPアドレスの範囲を持ちます。 macOSランナーはGitHub独自のmacOSクラウドでホストされます。

GitHub ホステッド ランナーには非常に多くの IP アドレス範囲があるため、内部リソースの許可リストとしてこれらを使うことはお勧めしません。 代わりに、静的 IP アドレス範囲またはセルフホステッド ランナーで より大きなランナーs の使用をお勧めします。 詳しくは、「より大きなランナーの使用」または「自己ホスト ランナーの概要」をご覧ください。

このAPIが返すGitHub ActionsのIPアドレスのリストは、週に1回更新されます。

GitHub ホステッド ランナーと GitHub Enterprise Cloud

の通信要件

GitHub でホステッド ランナーは、重要な通信操作を実行するために、GitHub 所有のエンドポイントへの接続を確立する必要があります。 さらに、ランナーは、アクション内で指定または利用する追加のネットワークへのアクセスを必要とする場合があります。

構成内のネットワーク間の GitHub ホステッド ランナーに対する適切な通信を確保するには、次の通信が許可されていることを確認します。

重要な操作に必要:

github.com
api.github.com
*.actions.githubusercontent.com

github.com
api.github.com
*.actions.githubusercontent.com

ダウンロード アクションに必要:

codeload.github.com
pkg.actions.githubusercontent.com

codeload.github.com
pkg.actions.githubusercontent.com

変更できないアクションの公開に必要:

ghcr.io

ghcr.io

ジョブサマリー、ログ、ワークフロー アーティファクトのアップロード/ダウンロードに必要:

results-receiver.actions.githubusercontent.com
*.blob.core.windows.net

results-receiver.actions.githubusercontent.com
*.blob.core.windows.net

ランナー バージョンの更新に必要:

objects.githubusercontent.com
objects-origin.githubusercontent.com
github-releases.githubusercontent.com
github-registry-files.githubusercontent.com

objects.githubusercontent.com
objects-origin.githubusercontent.com
github-releases.githubusercontent.com
github-registry-files.githubusercontent.com

OIDC トークンを取得するために必要:

*.actions.githubusercontent.com

*.actions.githubusercontent.com

パッケージまたはコンテナーを GitHub パッケージにダウンロードまたは発行するために必要です。

*.pkg.github.com
ghcr.io

*.pkg.github.com
ghcr.io

Git Large File Storage に必要

github-cloud.githubusercontent.com
github-cloud.s3.amazonaws.com

github-cloud.githubusercontent.com
github-cloud.s3.amazonaws.com

Dependabot updates のジョブに必要です

dependabot-actions.githubapp.com

dependabot-actions.githubapp.com

etc/hosts ファイル

GitHub ホストランナーは、さまざまな暗号化マイニング プールや悪意のあるサイトへのネットワーク アクセスをブロックする etc/hosts ファイルでプロビジョニングされます。 MiningMadness.com や cpu-pool.com などのホストは、重大なセキュリティ リスクが存在しないように localhost に再ルーティングされます。

ファイル システム

GitHubは、仮想マシン上の特定のディレクトリでアクションとシェルコマンドを実行します。 仮想マシン上のファイルパスは静的なものではありません。 home、workspace、workflow ディレクトリのファイル パスを作成するには、GitHub で提供される環境変数を使います。

ワークフローごとに GitHub によって作成される環境変数の一覧については、「変数に情報を格納する」をご覧ください。

Dockerコンテナのファイルシステム

Docker コンテナーで実行されるアクションには、/github パスの下に静的なディレクトリがあります。 ただし、Dockerコンテナ内のファイルパスを構築するには、デフォルトの環境変数を使用することを強くお勧めします。

GitHub では、/github パス プレフィックスが予約されており、アクション用に 3 つのディレクトリが作成されます。

• /github/home
• /github/workspace - メモ: GitHub Actions は既定の Docker ユーザー(root) で実行しなければなりません。 Dockerfile で USER 命令が設定されていないことを確認します。されている場合は、GITHUB_WORKSPACE にアクセスできません。
• /github/workflow

参考資料

• GitHub Actions の支払いを管理する
• マトリックス戦略を使用して、複数のイメージでジョブを実行できます。 詳しくは、「ワークフローでのジョブのバリエーションの実行」をご覧ください。