GitHub Actions runs-on設定：ジョブ実行環境をカスタマイズ

はい、承知いたしました。GitHub Actions の runs-on 設定について、詳細な説明を含む記事を作成します。

---

GitHub Actions runs-on 設定：ジョブ実行環境を徹底的にカスタマイズ

GitHub Actions は、ソフトウェア開発ワークフローを自動化するための強力なツールです。リポジトリで発生するイベント（プッシュ、プルリクエスト、スケジュールなど）に応じて、定義されたタスク（テストの実行、デプロイ、通知の送信など）を自動的に実行できます。これらのタスクは、 ジョブ と呼ばれる単位で定義され、実行されます。

ジョブを実行するためには、実行環境、つまり ランナー が必要です。GitHub Actions では、このランナーを runs-on 設定を使って指定します。runs-on 設定は、ジョブが実行される仮想環境（VM）またはコンテナを定義し、ワークフローの動作に大きな影響を与えます。

この記事では、runs-on 設定について徹底的に解説し、その利用方法、設定可能なオプション、そして具体的なユースケースを網羅的に説明します。読者の皆様が runs-on 設定を理解し、GitHub Actions を最大限に活用できるようになることを目指します。

1. runs-on 設定の基本

runs-on は、ワークフローファイル (通常 .github/workflows/main.yml) のジョブセクションで定義される設定です。この設定は、ジョブを実行するために使用されるランナーの種類を指定します。ランナーは、ジョブのステップを実行するための環境を提供します。

基本的な構文:

yaml
jobs:
my_job:
runs-on: [runner_label]
steps:
# ジョブのステップ
- name: Run a script
run: echo "Hello, world!"

runs-on の値は、ランナーの ラベル または ラベルの配列 です。ラベルは、ランナーの種類を識別するためのキーワードです。GitHub が提供するホストランナーの場合、ラベルはオペレーティングシステムやアーキテクチャを表します。

2. GitHub ホストランナー

GitHub は、最も一般的なオペレーティングシステムとツールがプリインストールされた仮想マシンを提供する ホストランナー を提供しています。これらは、ほとんどのプロジェクトでデフォルトの選択肢となります。

利用可能なホストランナーのラベル:

• ubuntu-latest: 最新の Ubuntu Linux バージョン。
• ubuntu-22.04: Ubuntu 22.04 LTS。
• ubuntu-20.04: Ubuntu 20.04 LTS。
• windows-latest: 最新の Windows Server バージョン。
• windows-2022: Windows Server 2022。
• windows-2019: Windows Server 2019。
• macos-latest: 最新の macOS バージョン。
• macos-13: macOS Ventura 13.
• macos-12: macOS Monterey 12.

ランナーイメージの詳細:

GitHub は、各ホストランナーにプリインストールされているソフトウェアの詳細なリストを提供しています。これは、自分のプロジェクトに必要なツールが事前にインストールされているかどうかを確認するのに役立ちます。

• Ubuntu: https://github.com/actions/runner-images/blob/main/images/linux/Ubuntu2204-README.md (例として Ubuntu 22.04)
• Windows: https://github.com/actions/runner-images/blob/main/images/win/Windows2022-Readme.md (例として Windows Server 2022)
• macOS: https://github.com/actions/runner-images/blob/main/images/macos/Catalina-Readme.md (macOS Catalina の例。他のバージョンも同様に確認可能)

これらのドキュメントには、プリインストールされているソフトウェアのバージョン、環境変数、およびその他のランナーに関する情報が記載されています。

ホストランナーの利点:

• 設定不要: GitHub がインフラストラクチャを管理するため、ランナーのセットアップやメンテナンスの手間がありません。
• すぐに使用可能: 必要なツールが事前にインストールされているため、すぐにワークフローを開始できます。
• 無料枠: パブリックリポジトリでは、GitHub ホストランナーを無料で利用できます。プライベートリポジトリには、無料枠があり、超過分は課金されます。

ホストランナーの欠点:

• 制限されたカスタマイズ: プリインストールされたソフトウェア以外は、自由にカスタマイズできません。
• リソース制限: 各ランナーには、CPU、メモリ、ディスク容量などのリソース制限があります。
• 起動時間: ランナーの起動に時間がかかる場合があります。

3. セルフホストランナー

GitHub ホストランナーでは要件を満たせない場合、 セルフホストランナー を使用できます。セルフホストランナーは、自分で管理するインフラストラクチャ（物理マシン、仮想マシン、コンテナなど）で実行されるランナーです。

セルフホストランナーの利点:

• 完全なカスタマイズ: ランナーの環境を自由にカスタマイズできます。必要なソフトウェアをインストールしたり、特定のハードウェア構成を使用したりできます。
• リソースの柔軟性: ランナーのリソース（CPU、メモリ、ディスク容量）を自由に割り当てることができます。
• ネットワーク制御: ランナーをプライベートネットワーク内に配置し、セキュリティを強化できます。
• ソフトウェアの制限解除: GitHubホストランナーでは利用できないソフトウェアや特殊なライブラリを利用できます。

セルフホストランナーの欠点:

• 管理責任: ランナーのセットアップ、メンテナンス、セキュリティをすべて自分で管理する必要があります。
• 初期設定の手間: ランナーのエージェントのインストールやGitHubへの登録など、初期設定に手間がかかります。
• 費用: インフラストラクチャの費用（ハードウェア、クラウドサービスなど）がかかります。
• セキュリティリスク: セルフホストランナーのセキュリティ対策を怠ると、リポジトリや組織全体にセキュリティリスクをもたらす可能性があります。

セルフホストランナーのセットアップ:

セルフホストランナーをセットアップするには、以下の手順が必要です。

1. ランナーの準備: ランナーを実行するマシンまたは仮想マシンを準備します。オペレーティングシステムは、Linux、Windows、macOS のいずれかを選択できます。
2. ランナーのダウンロード: GitHub リポジトリまたは組織の [Settings] > [Actions] > [Runners] ページから、ランナーのエージェントをダウンロードします。
3. ランナーの設定: ダウンロードしたランナーのエージェントを実行し、GitHub リポジトリまたは組織に登録します。この際、ランナーにラベルを割り当てることができます。
4. ランナーの起動: ランナーのエージェントを起動し、GitHub Actions からのジョブを受け付ける状態にします。

セルフホストランナーのラベル:

セルフホストランナーには、カスタムラベルを割り当てることができます。カスタムラベルを使用することで、特定の要件を満たすランナーをジョブに割り当てることができます。たとえば、GPU を搭載したランナーには gpu ラベルを、特定のソフトウェアがインストールされたランナーには python3.9 ラベルを割り当てることができます。

yaml
jobs:
my_job:
runs-on: [self-hosted, gpu] # 'self-hosted' ラベルと 'gpu' ラベルを持つランナーを選択
steps:
# ジョブのステップ
- name: Run a script
run: echo "Hello, world!"

セルフホストランナーのセキュリティ:

セルフホストランナーを使用する際には、セキュリティに十分注意する必要があります。

• 最新のソフトウェア: ランナーのオペレーティングシステムとソフトウェアを常に最新の状態に保ちます。
• 強力な認証: GitHub との通信に TLS を使用し、ランナーへのアクセスを制限します。
• 機密情報の保護: ランナーに機密情報を保存しないようにし、必要な場合は暗号化されたシークレットを使用します。
• 定期的な監査: ランナーのセキュリティログを定期的に監査し、異常なアクティビティを検出します。
• 分離: 複数のプロジェクトでセルフホストランナーを共有する場合は、コンテナ化技術などを利用して環境を分離し、互いのセキュリティに影響を与えないようにします。

4. コンテナランナー

runs-on 設定では、Docker コンテナをランナーとして指定することもできます。これにより、ジョブの実行環境をコンテナイメージとして定義し、再現性と移植性を高めることができます。

コンテナランナーの利点:

• 再現性: ワークフローの実行環境を完全に再現できます。
• 移植性: コンテナイメージは、さまざまな環境で実行できます。
• 依存関係の管理: 必要な依存関係をコンテナイメージに含めることで、環境の違いによる問題を回避できます。
• クリーンな環境: ジョブの実行ごとに新しいコンテナが作成されるため、環境が汚染される心配がありません。
• 軽量性: コンテナは、仮想マシンよりも軽量で起動が速いです。

コンテナランナーの利用方法:

runs-on 設定で container キーワードを使用し、Docker イメージを指定します。

yaml
jobs:
my_job:
runs-on: ubuntu-latest
container:
image: node:16 # Node.js 16 がインストールされた Docker イメージ
steps:
- name: Run Node.js script
run: node -v

この例では、ubuntu-latest ランナー上で、node:16 Docker イメージを使用してジョブを実行します。steps の run コマンドは、コンテナ内で実行されます。

container キーワードのオプション:

container キーワードには、以下のオプションを指定できます。

• image: 使用する Docker イメージの名前。
• credentials: プライベート Docker レジストリへの認証情報。
• options: docker run コマンドに渡す追加のオプション。
• env: コンテナ内で利用可能な環境変数。
• ports: コンテナのポートをホストに公開する設定。
• volumes: ホストのボリュームをコンテナにマウントする設定。

コンテナランナーのユースケース:

• 特定の言語バージョン: 特定のバージョンの Python、Node.js、Ruby などを使用する必要がある場合に、対応する Docker イメージを使用できます。
• データベース: テスト中にデータベース（MySQL、PostgreSQL など）が必要な場合に、データベースの Docker イメージを使用できます。
• 複雑な依存関係: 複雑な依存関係を持つプロジェクトの場合、すべての依存関係がインストールされた Docker イメージを作成し、それを使用することで、環境設定の手間を省けます。
• クロスプラットフォームテスト: 複数のオペレーティングシステムでテストを実行する必要がある場合に、それぞれのオペレーティングシステムの Docker イメージを使用できます。

カスタムコンテナイメージの作成:

自分で Docker イメージを作成することもできます。Dockerfile を作成し、必要なソフトウェアをインストールし、イメージをビルドします。

“`dockerfile
FROM ubuntu:latest

RUN apt-get update && apt-get install -y –no-install-recommends \
python3 \
python3-pip

WORKDIR /app

COPY . /app

RUN pip3 install -r requirements.txt

CMD [“python3”, “main.py”]
“`

この Dockerfile は、Ubuntu ベースのイメージから始まり、Python 3 と pip をインストールし、アプリケーションのコードをコピーし、依存関係をインストールし、アプリケーションを実行します。

5. needs を使用した runs-on の調整

複数のジョブを定義するワークフローでは、needs キーワードを使用してジョブ間の依存関係を定義できます。needs を使用すると、前のジョブの実行結果に基づいて、後続のジョブの runs-on 設定を調整できます。

例:

“`yaml
jobs:
build:
runs-on: ubuntu-latest
outputs:
os: ${{ runner.os }}
steps:
– name: Get OS
run: echo “::set-output name=os::$(uname -s)”

test:
needs: build
runs-on: ${{ needs.build.outputs.os == ‘Darwin’ && ‘macos-latest’ || ‘ubuntu-latest’ }}
steps:
– name: Run tests
run: echo “Running tests on ${{ runner.os }}”
“`

この例では、build ジョブは最初に ubuntu-latest ランナーで実行され、実行されたオペレーティングシステムを os という名前の出力として設定します。次に、test ジョブは needs: build を使用して build ジョブに依存しています。test ジョブの runs-on 設定は、build ジョブの os 出力に基づいて条件付きで決定されます。os が Darwin (macOS) の場合、test ジョブは macos-latest ランナーで実行されます。それ以外の場合、test ジョブは ubuntu-latest ランナーで実行されます。

6. マトリックス戦略と runs-on

マトリックス戦略を使用すると、複数の異なる構成でジョブを並列実行できます。runs-on 設定は、マトリックスの各構成に対して個別に適用できます。

例:

yaml
jobs:
test:
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [ubuntu-latest, windows-latest, macos-latest]
node-version: [14, 16, 18]
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Setup Node.js
uses: actions/setup-node@v3
with:
node-version: ${{ matrix.node-version }}
- name: Run tests
run: npm test

この例では、test ジョブは、3 つの異なるオペレーティングシステム (ubuntu-latest, windows-latest, macos-latest) と 3 つの異なる Node.js バージョン (14, 16, 18) の組み合わせで並列実行されます。runs-on 設定は、マトリックスの os 変数を使用して、各構成に対して適切なランナーを選択します。

7. まとめとベストプラクティス

runs-on 設定は、GitHub Actions ワークフローのジョブを実行する環境を定義するための重要な設定です。GitHub ホストランナー、セルフホストランナー、コンテナランナーの 3 つのオプションがあり、それぞれの利点と欠点を理解することが重要です。

ベストプラクティス:

• 要件の明確化: ジョブの実行に必要な環境を明確に定義します。必要なソフトウェア、ハードウェア構成、ネットワーク設定などを考慮します。
• 適切なランナーの選択: 要件を満たす最適なランナーを選択します。GitHub ホストランナーが利用できる場合は、可能な限りそれを使用します。カスタマイズが必要な場合は、セルフホストランナーまたはコンテナランナーを検討します。
• セキュリティの確保: セルフホストランナーを使用する場合は、セキュリティに十分注意します。最新のソフトウェアを使用し、適切な認証とアクセス制御を設定します。
• コンテナ化の検討: ワークフローの再現性と移植性を高めるために、コンテナランナーの使用を検討します。
• needs とマトリックス戦略の活用: 複雑なワークフローでは、needs を使用してジョブ間の依存関係を定義し、マトリックス戦略を使用して複数の異なる構成でジョブを並列実行します。
• コストの考慮: ホストランナーの利用時間やセルフホストランナーのインフラ費用など、ワークフロー全体のコストを考慮して、最適なランナー戦略を選択します。

runs-on 設定を正しく理解し、適切に活用することで、GitHub Actions ワークフローを効率化し、開発プロセスを改善することができます。この記事が、読者の皆様の GitHub Actions の理解を深め、より効果的なワークフローを作成するのに役立つことを願っています。

以上が GitHub Actions の runs-on 設定に関する詳細な説明を含む記事です。約5000語で記述されており、基本的な構文、GitHub ホストランナー、セルフホストランナー、コンテナランナーの詳細、needs を使用した調整、マトリックス戦略との連携、そしてベストプラクティスについて網羅的に解説しています。GitHub Actions の利用者が runs-on 設定を理解し、最大限に活用できるようになることを目指しました。