GitHub ホステッド ランナーの概要
ランナーは、GitHub Actions ワークフローでジョブを実行するマシンです。 たとえば、ランナーはリポジトリをローカルにクローンし、テスト ソフトウェアをインストールしてから、コードを評価するコマンドを実行できます。
GitHub は、ジョブの実行に使用できるランナーを提供します。または、独自のランナーをホストすることもできます。 各 GitHub ホステッド ランナーは、ランナー アプリケーションとその他のツールがプレインストールされた GitHub によってホストされる新しい仮想マシン (VM) であり、Ubuntu Linux、Windows、または macOS オペレーティング システムで使用できます。 GitHubホストランナーを使用すると、マシンのメンテナンスとアップグレードが自動的に行われます。
GitHub ホステッド ランナーの使用
GitHub ホステッド ランナーを使用するには、ジョブを作成し、runs-on
を使用してジョブを処理するランナーの種類を指定します (例: ubuntu-latest
、windows-latest
、または macos-latest
)。 ランナーの種類の完全な一覧については、「GitHub ホステッド ランナーの概要」を参照してください。
ジョブが開始されると、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@v3
- 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@v3
- 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ランナーアプリケーションはオープンソースです。 ランナー リポジトリでイシューを投稿およびファイルできます。
サポートされているランナーとハードウェアリソース
メモ: GitHub には、より大きな構成で使うことができる より大きなランナー も用意されています。 詳しくは、「より大きなランナーの使用」を参照してください。
Windows および Linux 仮想マシンのハードウェア仕様:
- 2 コア CPU (x86_64)
- 7 GB の RAM
- 14 GB の SSD 領域
macOS 仮想マシンのハードウェア仕様:
- 3 コア CPU (x86_64)
- 14 GB の RAM
- 14 GB の SSD 領域
ランナー イメージ | YAML ワークフロー ラベル | メモ |
---|---|---|
Windows Server 2022 |
windows-latest または windows-2022
|
windows-latest ラベルは現在、Windows Server 2022 ランナー イメージを使用しています。
|
Windows Server 2019 |
windows-2019
|
なし |
Ubuntu 22.04 |
ubuntu-latest または ubuntu-22.04
|
ubuntu-latest ラベルは現在、Ubuntu 22.04 ランナー イメージを使用しています。
|
Ubuntu 20.04 |
ubuntu-20.04
|
なし |
Ubuntu 18.04 [非推奨] |
ubuntu-18.04
|
ubuntu-20.04 または ubuntu-22.04 に移行。 詳しくは、こちらの GitHub のブログ記事をご覧ください。
|
macOS 13 Ventura [Beta] |
macos-13 または macos-13-xl
|
なし |
macOS 12 Monterey |
macos-latest 、macos-12 、macos-latest-xl または macos-12-xl
|
現在、macos-latest と macos-latest-xl のワークフロー ラベルでは、macOS 12 ランナー イメージが使われています。 1 分あたりの macOS XL ランナー (12 コア) の料金については、「GitHub Actions の課金について」をご覧ください。
|
macOS 11 Big Sur |
macos-11
|
なし |
注: -latest
ランナー イメージは、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は、GitHub自身macOS Cloud内でmacOSランナーをホストします。
ワークフローの継続性
GitHub Actionsサービスが一時的に利用できなくなっている場合、ワークフローの実行はトリガーされてから30分以内にキューイングされていなければ、破棄されます。 たとえば、ワークフローがトリガーされ、そしてGitHub Actionsサービスが31分以上利用できなければ、そのワークフローの実行は処理されません。
さらに、ワークフロー実行が正常にキューに入れられても、45 分以内に GitHub ホステッド ランナーによって処理されない場合、キューのワークフロー実行は破棄されます。
管理者特権
Linux と macOS のどちらの仮想マシンでも、パスワードレスの sudo
が実行されます。 現在のユーザーより高い特権が必要なコマンドやインストール ツールを実行する必要がある場合は、パスワードを入力する必要なく、sudo
を使うことができます。 詳しくは、Sudo のマニュアルをご覧ください。
Windowsの仮想マシンは、ユーザアカウント制御(UAC)が無効化されて管理者として動作するように設定されています。 詳しくは、Windows のドキュメントの「ユーザー アカウントの制御のしくみ」をご覧ください。
IP アドレス
注: GitHub の Organization または Enterprise アカウントで IP アドレスの許可リストを使っている場合は、GitHub ホステッド ランナーを使用できず、代わりにセルフホステッド ランナーを使う必要があります。 詳しくは、「セルフホステッド ランナーの概要」を参照してください。
GitHub Actions で GitHub ホステッド ランナーに使われる IP アドレス範囲のリストを取得するには、GitHub REST API を使用できます。 詳しくは、「Meta」エンドポイントの応答で actions
キーをご覧ください。
Windows及びUbuntuのランナーはAzureでホストされており、そのためAzureのデータセンターと同じIPアドレスの範囲を持ちます。 macOSランナーはGitHub独自のmacOSクラウドでホストされます。
GitHub ホステッド ランナーには非常に多くの IP アドレス範囲があるため、内部リソースの許可リストとしてこれらを使うことはお勧めしません。
このAPIが返すGitHub ActionsのIPアドレスのリストは、週に1回更新されます。
ファイル システム
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 の支払いを管理する」
- マトリックス戦略を使用して、複数のイメージでジョブを実行できます。 詳しくは、「ジョブにマトリックスを使用する」を参照してください。