GitHub ホステッド ランナーの概要
ランナーは、GitHub Actions ワークフローでジョブを実行するマシンです。 たとえば、ランナーはリポジトリをローカルにクローンし、テスト ソフトウェアをインストールしてから、コードを評価するコマンドを実行できます。
GitHub は、ジョブの実行に使用できるランナーを提供します。または、独自のランナーをホストすることもできます。 各 GitHub ホステッド ランナーは、ランナー アプリケーションとその他のツールがプレインストールされた GitHub によってホストされる新しい仮想マシン (VM) であり、Ubuntu Linux、Windows、または macOS オペレーティング システムで使用できます。 GitHubホストランナーを使用すると、マシンのメンテナンスとアップグレードが自動的に行われます。
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@v3 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@v3
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
アクセス許可を持つ場合は、リポジトリで使用できるランナーの一覧が表示されます。
-
GitHub.com で、リポジトリのメイン ページへ移動します。
-
リポジトリ名の下にある [アクション] をクリックします。
-
左サイドバーの [管理] セクションで、[ランナー] をクリックします。
-
リポジトリで使用可能な GitHub でホストされたランナーの一覧を確認します。
-
必要に応じて、ランナーのラベルをコピーしてワークフローで使用するには、ランナーの右側にある をクリックし、[ラベルのコピー] をクリックします。
注: ランナーを作成する権限を持つエンタープライズおよび組織のオーナーには、このページから新しいランナーを作成するオプションがあります。 企業または組織のオーナーである場合は、ランナー一覧の右上にある [新しいランナー] をクリックして、リポジトリにランナーを追加します。 詳細は、「より大きなランナーを管理する」または「自己ホストランナーの追加」を参照してください。
サポートされているランナーとハードウェアリソース
メモ: GitHub には、Linux、Windows、そして macOS 仮想マシンにおいて、より大きな構成で使うことができる より大きなランナー も用意されています。 自動スケールは既定で有効になっており、Linux と Windows ではオプションの専用 IP アドレスを使用できます。 詳しくは、「より大きなランナーの概要」を参照してください。
仮想マシン | プロセッサ (CPU) | メモリ(RAM) | ストレージ (SSD) | OS (YAML ワークフロー ラベル) | メモ |
---|---|---|---|---|---|
Linux | 2 | 7 GB | 14 GB |
ubuntu-latest 、ubuntu-22.04 、ubuntu-20.04
|
ubuntu-latest ラベルは現在、Ubuntu 22.04 ランナー イメージを使用しています。
|
Windows | 2 | 7 GB | 14 GB |
windows-latest 、windows-2022 、windows-2019
|
現在、windows-latest ラベルでは、Windows 2022 ランナー イメージが使われています。
|
macOS | 3 | 14 GB | 14 GB |
macos-latest 、macos-12 、macos-11
|
現在、macos-latest ワークフロー ラベルでは、macOS 12 ランナー イメージが使われています。
|
macOS | 4 | 14 GB | 14 GB |
macos-13 [Beta]
|
該当なし |
注: -latest
ランナー イメージは、GitHub が提供する最新の安定したイメージであり、オペレーティング システム ベンダーから入手できるオペレーティング システムの最新バージョンではない可能性があります。
警告: ベータ版および非推奨のイメージは、"現状のまま"、"保証なし"、"利用可能な状態" で提供され、サービス レベル アグリーメントと保証から除外されます。 ベータ版のイメージは、カスタマー サポートでカバーされない場合があります。
ワークフローログには、ジョブの実行に使用されたランナーが一覧表示されます。 詳しくは、「ワークフロー実行の履歴を表示する」を参照してください。
より大きなランナー
標準の GitHub ホステッド ランナーに加えて、GitHub では、GitHub Team と GitHub Enterprise Cloud プランのお客様には、より多くの RAM、CPU、ディスク領域を備えたさまざまなマネージド仮想マシンが用意されています。 これらのランナーは、GitHub によってホストされ、ランナー アプリケーションとその他のツールをプレインストールしています。
詳しくは、「より大きなランナーの概要」を参照してください。
サポートされているソフトウェア
GitHub ホストランナーに含まれているソフトウェアツールは毎週更新されます。 更新プロセスには数日かかり、main
ブランチのプレインストール済みソフトウェアのリストは、デプロイ全体が終了した後で更新されます。
プレインストール済みソフトウェア
ワークフローログには、正確なランナーにプレインストールされているツールへのリンクが含まれています。 ワークフローのログでこの情報を見つけるには、Set up job
セクションを展開します。 そのセクションの下で、Runner Image
セクションを展開します。 Included Software
の後のリンクで、ワークフローを実行したランナーにプレインストールされているツールが示されています。
詳しくは、「ワークフロー実行の履歴を表示する」を参照してください。
各ランナーのオペレーティング システム用に含まれるすべてのツールの一覧については、以下のリンクをご覧ください。
- Ubuntu 22.04 LTS
- Ubuntu 20.04 LTS
- Windows Server 2022
- Windows Server 2019
- macOS 13
- macOS 12
- macOS 11
GitHubホストランナーには、オペレーティングシステムのデフォルトの組み込みツールに加え、上のリファレンスのリスト内のパッケージにが含まれています。 たとえば、Ubuntu と macOS のランナーには、他の既定のツールと共に grep
、find
、which
が含まれます。
Windows と Ubuntu のランナー イメージのビルドごとにソフトウェア部品表 (SBOM) を表示することもできます。 詳しくは、「GitHub Actions のセキュリティ強化」を参照してください。
プレインストール済みソフトウェアを使用する
アクションを使用して、ランナーにインストールされているソフトウェアと対話することをお勧めします。 この方法には、いくつかの利点があります。
- アクションでは通常、バージョンの選択、引数を渡す機能、パラメータなどの機能が提供されています
- これにより、ソフトウェアの更新に関係なく、ワークフローで使用されるツールのバージョンが同じままになります
要求したいツールがある場合は、actions/virtual-environments で issue を開いてください。 このリポジトリには、ランナーに関するすべての主要なソフトウェア更新に関するお知らせも含まれています。
追加ソフトウェアをインストールする
GitHub ホステッド ランナーに追加のソフトウェアをインストールできます。 詳細については、「GitHub ホステッド ランナーのカスタマイズ」を参照してください。
GitHub ホステッド ランナーによって使用されるクラウド ホスト
GitHub は、Microsoft Azure の Standard_DS2_v2
仮想マシン上で GitHub Actions ランナー アプリケーションがインストールされた Linux および Windows ランナーをホストします。 GitHubホストランナーアプリケーションは、Azure Pipelines Agentのフォークです。 インバウンドのICMPパケットはすべてのAzure仮想マシンでブロックされるので、pingやtracerouteコマンドは動作しないでしょう。 Standard_DS2_v2
リソースについて詳しくは、Microsoft Azure ドキュメントの「Dv2 および DSv2 シリーズ」をご覧ください。 GitHub は、Azure データ センターで macOS ランナーをホストします。
ワークフローの継続性
GitHub Actionsサービスが一時的に利用できなくなっている場合、ワークフローの実行はトリガーされてから30分以内にキューイングされていなければ、破棄されます。 たとえば、ワークフローがトリガーされ、そしてGitHub Actionsサービスが31分以上利用できなければ、そのワークフローの実行は処理されません。
さらに、ワークフロー実行が正常にキューに入れられても、45 分以内に GitHub ホステッド ランナーによって処理されない場合、キューのワークフロー実行は破棄されます。
管理者特権
Linux と macOS のどちらの仮想マシンでも、パスワードレスの sudo
が実行されます。 現在のユーザーより高い特権が必要なコマンドやインストール ツールを実行する必要がある場合は、パスワードを入力する必要なく、sudo
を使うことができます。 詳しくは、Sudo のマニュアルをご覧ください。
Windowsの仮想マシンは、ユーザアカウント制御(UAC)が無効化されて管理者として動作するように設定されています。 詳しくは、Windows のドキュメントの「ユーザー アカウントの制御のしくみ」をご覧ください。
IP アドレス
GitHub Actions で GitHub ホステッド ランナーに使われる IP アドレス範囲のリストを取得するには、GitHub REST API を使用できます。 詳しくは、「Meta」エンドポイントの応答で actions
キーをご覧ください。
Windows及びUbuntuのランナーはAzureでホストされており、そのためAzureのデータセンターと同じIPアドレスの範囲を持ちます。 macOSランナーはGitHub独自のmacOSクラウドでホストされます。
GitHub ホステッド ランナーには非常に多くの IP アドレス範囲があるため、内部リソースの許可リストとしてこれらを使うことはお勧めしません。 代わりに、静的 IP アドレス範囲またはセルフホステッド ランナーで より大きなランナーs の使用をお勧めします。 詳細については、「より大きなランナーの概要」または「セルフホステッド ランナーの概要」を参照してください。
このAPIが返すGitHub ActionsのIPアドレスのリストは、週に1回更新されます。
etc/hosts
ファイル
GitHub ホストランナーは、さまざまな暗号化マイニング プールや悪意のあるサイトへのネットワーク アクセスをブロックする etc/hosts
ファイルでプロビジョニングされます。 MiningMadness.com や cpu-pool.com などのホストは、重大なセキュリティ リスクが存在しないように localhost に再ルーティングされます。
ファイル システム
GitHubは、仮想マシン上の特定のディレクトリでアクションとシェルコマンドを実行します。 仮想マシン上のファイルパスは静的なものではありません。 home
、workspace
、workflow
ディレクトリのファイル パスを作成するには、GitHub で提供される環境変数を使います。
ディレクトリ | 環境変数 | 説明 |
---|---|---|
home | HOME | ユーザ関連のデータが含まれます。 たとえば、このディレクトリにはログイン試行からの認証情報を含めることができます。 |
workspace | GITHUB_WORKSPACE | アクションとシェルコマンドはこのディレクトリで実行されます。 このディレクトリの内容は、アクションによって変更することができ、後続のアクションでアクセスできます。 |
workflow/event.json | GITHUB_EVENT_PATH | ワークフローをトリガーした Webhook イベントの POST ペイロード。 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 の支払いを管理する
- マトリックス戦略を使用して、複数のイメージでジョブを実行できます。 詳しくは、「ジョブにマトリックスを使用する」を参照してください。