Tips - ランナーの管理

Posted at 2025-12-23

Tips - ランナーの管理

GitHub Actionsでワークフローを実行する際、その実行環境である「ランナー」の選択と設定は、CI/CDパイプラインの性能とセキュリティを大きく左右します。本記事では、GitHubが提供する公式ドキュメントをもとに、セルフホストランナーとラージャーランナーの機能を体系的に解説します。

ランナーの種類と選択基準
セルフホストランナーの導入と管理
ラベルとグループによるルーティング制御
ジョブ前後のスクリプト実行
コンテナのカスタマイズ
ラージャーランナーの活用
カスタムイメージの作成と運用
ネットワーク設定とプロキシ対応
監視とトラブルシューティング

1. ランナーの種類と選択基準

GitHub Actionsでは、大きく分けて2種類のランナーを利用できます。

1.1 GitHubホストランナー

GitHubが管理する仮想マシンで、設定不要ですぐに使えます。

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - run: npm install

1.2 セルフホストランナー

自分で管理するマシン上で実行するランナーです。以下のような場合に有効です：

特殊なハードウェア（GPU等）が必要
プライベートネットワーク内のリソースへアクセスが必要
コスト最適化を図りたい
コンプライアンス要件がある

重要な注意点：セルフホストランナーはプライベートリポジトリでのみ使用することを強く推奨します。パブリックリポジトリのフォークから悪意のあるコードが実行される可能性があるためです。

2. セルフホストランナーの導入と管理

2.1 追加手順

セルフホストランナーの追加は、リポジトリ、組織、エンタープライズの各レベルで可能です。

2.1.1 リポジトリレベルでの追加例

リポジトリの Settings > Actions > Runners に移動
"New self-hosted runner" をクリック
OS（Linux、Windows、macOS）とアーキテクチャを選択
表示される手順に従って実行：

# ダウンロードと展開
mkdir actions-runner && cd actions-runner
curl -o actions-runner-linux-x64-2.XXX.X.tar.gz -L https://github.com/actions/runner/releases/download/vX.XXX.X/actions-runner-linux-x64-2.XXX.X.tar.gz
tar xzf ./actions-runner-linux-x64-2.XXX.X.tar.gz

# 設定
./config.sh --url https://github.com/your-org/your-repo --token YOUR_TOKEN

# 起動
./run.sh

接続が成功すると、ターミナルに以下のメッセージが表示されます：

√ Connected to GitHub
2024-12-23 10:00:00Z: Listening for Jobs

2.2 サービスとしての設定

ランナーをシステムサービスとして登録することで、マシン起動時に自動的に開始できます。

2.2.1 Linuxでのサービス化

# サービスのインストール
sudo ./svc.sh install

# サービスの開始
sudo ./svc.sh start

# ステータス確認
sudo ./svc.sh status

# サービスの停止
sudo ./svc.sh stop

# アンインストール
sudo ./svc.sh uninstall

特定のユーザーでサービスを実行する場合：

sudo ./svc.sh install yamada

2.2.2 Debian系システムでの注意点

needrestartが有効な場合、ワークフロー実行中にランナーサービスが再起動されるのを防ぐ設定：

echo '$nrconf{override_rc}{qr(^actions\.runner\..+\.service$)} = 0;' | sudo tee /etc/needrestart/conf.d/actions_runner_services.conf

3. ラベルとグループによるルーティング制御

3.1 デフォルトラベル

セルフホストランナーは追加時に自動的にラベルが付与されます：

self-hosted：すべてのセルフホストランナー
OS：linux、windows、macos
アーキテクチャ：x64、ARM、ARM64

3.2 カスタムラベルの作成

特定のハードウェアや用途に応じてカスタムラベルを追加できます。

3.2.1 リポジトリランナーへのラベル追加

Settings > Actions > Runners
設定するランナー名をクリック
"Labels" セクションで ⚙ をクリック
"Find or create a label" でラベル名を入力し "Create new label"

3.2.2 登録時にラベルを指定

./config.sh --url https://github.com/your-org/your-repo --token YOUR_TOKEN --labels gpu,ubuntu-20.04-16core

3.3 ワークフローでのラベル指定

jobs:
  gpu_job:
    runs-on: [self-hosted, linux, x64, gpu]
    steps:
      - name: "GPU処理の実行"
        run: python train_model.py

このジョブは、self-hosted、linux、x64、gpuのすべてのラベルを持つランナーで実行されます。

3.4 ランナーグループの活用

ランナーグループを使うと、リポジトリ単位でアクセス制御が可能になります。

3.4.1 グループの作成

組織の Settings > Actions > Runner groups
"New runner group" をクリック
グループ名を入力
リポジトリアクセスポリシーを設定

3.4.2 ワークフローでの指定

jobs:
  build:
    runs-on: 
      group: ubuntu-runners
    steps:
      - uses: actions/checkout@v5

3.4.3 グループとラベルの組み合わせ

jobs:
  build:
    runs-on:
      group: ubuntu-runners
      labels: ubuntu-20.04-16core
    steps:
      - uses: actions/checkout@v5
      - run: make build

4. ジョブ前後のスクリプト実行

セルフホストランナーでは、ジョブの開始前と終了後に自動的にスクリプトを実行できます。環境のセットアップやクリーンアップ、テレメトリ収集などに活用できます。

4.1 対応スクリプト言語

Bash：bashを使用、フォールバックでsh
PowerShell：pwshを使用、フォールバックでpowershell

4.2 環境変数での設定

以下の環境変数にスクリプトの絶対パスを設定します：

ACTIONS_RUNNER_HOOK_JOB_STARTED：ジョブ開始前に実行
ACTIONS_RUNNER_HOOK_JOB_COMPLETED：ジョブ終了後に実行

4.3 設定方法

4.3.1 .envファイルでの設定例

ランナーアプリケーションディレクトリ内の.envファイルに記述：

ACTIONS_RUNNER_HOOK_JOB_STARTED=/opt/runner/cleanup_script.sh
ACTIONS_RUNNER_HOOK_JOB_COMPLETED=/opt/runner/telemetry_script.sh

設定後、ランナーを再起動してください。

4.4 スクリプトの機能

スクリプト内では以下が利用可能です：

環境変数：デフォルトの環境変数にアクセス可能
Webhookペイロード：GITHUB_EVENT_PATHから取得
ワークフローコマンド：echo "::set-output name=result::success"など

4.5 終了コードの扱い

開始前スクリプト：終了コード0以外の場合、ジョブは失敗としてマークされ実行されません
終了後スクリプト：終了コードに関わらず、ジョブは完了します

4.6 実行例

#!/bin/bash
# cleanup_script.sh

echo "ジョブ開始前のクリーンアップを実行中..."

# 一時ファイルの削除
rm -rf /tmp/build-*

# Dockerコンテナのクリーンアップ
docker system prune -f

echo "クリーンアップ完了"
exit 0

実行権限の付与を忘れずに：

chmod +x /opt/runner/cleanup_script.sh

4.7 トラブルシューティング

4.7.1 パーミッションエラー

chmod +x /path/to/script.sh

4.7.2 タイムアウト設定

現在、タイムアウト設定は提供されていません。スクリプト内でタイムアウト処理を実装することを推奨します。

4.7.3 ログの確認

ワークフロー実行ログの"Set up runner"または"Complete runner"セクションでスクリプトの出力を確認できます。

5. コンテナのカスタマイズ

セルフホストランナーでコンテナベースのジョブを実行する際、コンテナの作成方法をカスタマイズできます。KubernetesやPodmanとの統合、docker runコマンドのカスタマイズが可能です。

5.1 カスタマイズコマンド

以下の4つのコマンドをJSON形式で定義します：

prepare_job：ジョブ開始時に呼び出される
cleanup_job：ジョブ終了時に呼び出される
run_container_step：各コンテナアクションで呼び出される
run_script_step：コンテナアクション以外のステップで呼び出される

5.2 実装の流れ

5.3 サンプル実装

GitHubの公式リポジトリに参考実装があります：

git clone https://github.com/actions/runner-container-hooks
cd runner-container-hooks

# パッケージのビルド
npm install && npm run bootstrap && npm run build-all

生成されたindex.jsを環境変数で指定：

# .envファイルに追加
ACTIONS_RUNNER_CONTAINER_HOOKS=/Users/tanaka/runner/index.js

5.4 prepare_jobの例

{
  "command": "prepare_job",
  "responseFile": "/users/tanaka/runner/_work/{guid}.json",
  "state": {},
  "args": {
    "jobContainer": {
      "image": "node:18",
      "workingDirectory": "/__w/test-repo/test-repo",
      "createOptions": "--cpus 1",
      "environmentVariables": {
        "NODE_ENV": "development"
      }
    }
  }
}

5.5 run_container_stepの例

{
  "command": "run_container_step",
  "state": {
    "network": "example_network_53269bd575972817b43f7733536b200c",
    "jobContainer": "82e8219701fe..."
  },
  "args": {
    "image": "node:18",
    "entryPoint": "tail",
    "entryPointArgs": ["-f", "/dev/null"]
  }
}

5.6 必須設定

コンテナでジョブを実行することを必須にする場合：

# .envファイルに追加
ACTIONS_RUNNER_REQUIRE_JOB_CONTAINER=true

この設定により、コンテナを指定しないジョブは失敗します。

6. ラージャーランナーの活用

ラージャーランナーは、GitHubがホストする高性能なランナーで、Team/Enterprise Cloudプランで利用可能です。

6.1 特徴

より高いCPU・メモリ構成
静的IPアドレスの設定が可能
カスタムイメージの利用
自動スケーリング
GPU対応

6.2 追加手順

6.3 組織レベルでの追加

組織の Settings > Actions > Runners
"New runner" > "New GitHub-hosted runner"
必須項目を入力：

名前: ubuntu-20.04-16core
プラットフォーム: Linux x64
イメージ: Ubuntu 20.04
サイズ: 16-core, 64GB RAM
最大同時実行数: 10
ランナーグループ: default

6.4 リポジトリアクセスの許可

デフォルトでは、組織のすべてのリポジトリがアクセス可能です。制限する場合：

Runner groups > 対象グループを選択
"Repository access" で "Selected repositories" を選択
アクセスを許可するリポジトリを選択

6.5 ワークフローでの使用

6.5.1 ラベルでの指定

jobs:
  build:
    runs-on: ubuntu-20.04-16core
    steps:
      - uses: actions/checkout@v5
      - run: make build

6.5.2 グループとラベルの組み合わせ

jobs:
  build:
    runs-on:
      group: ubuntu-runners
      labels: ubuntu-20.04-16core
    steps:
      - uses: actions/checkout@v5

6.6 自動スケーリングの設定

同時実行数の上限を変更することで、並列実行を制御できます：

Runners > 対象ランナーを選択
"Auto-scaling" セクションで "Maximum Job Concurrency" を変更
"Save" をクリック

6.7 静的IPアドレスの設定

前提条件：Enterprise Cloudプランが必要

設定手順：

Runners > 対象ランナーを選択
"Networking" セクションで "Assign unique & static public IP address ranges for this runner" にチェック
"Save" をクリック

デフォルトで10個のランナーまで静的IPを設定可能です。それ以上必要な場合はサポートに連絡してください。

6.8 設定の変更

6.8.1 名前の変更

Runners > 対象ランナーを選択
"Name" フィールドで名前を変更
"Save" をクリック

注意：コードスキャニングのデフォルトセットアップで使用する場合、ランナー名はcode-scanningである必要があります。

6.8.2 サイズの変更

Runners > 対象ランナーを選択
"Size" で新しいサイズを選択
"Save" をクリック

6.8.3 イメージの変更

Runners > 対象ランナーを選択
"Image" で新しいイメージを選択（GitHub所有イメージのみ）
"Save" をクリック

7. カスタムイメージの作成と運用

カスタムイメージを使用することで、事前に依存関係をインストールした状態でワークフローを実行でき、大幅な時間短縮が可能です。

7.1 カスタムイメージのメリット

パッケージのダウンロード時間を削減
環境の一貫性を保証
ワークフロー実行時間の短縮
"プレウォーム"された環境

7.2 前提条件

カスタムイメージが組織/エンタープライズで有効化されている
組織/エンタープライズのオーナー、またはCI/CD Admin権限、または以下の権限を持つロール：
- View organization hosted runner custom images
- Manage organization hosted runner custom images
- Manage organization runners and runner groups

7.3 作成の流れ

7.4 ステップ1：イメージ生成用ランナーの作成

組織の Settings > Actions > Runners
"New runner" > "New GitHub-hosted runner"
設定項目：
- Platform：Linux x64、Linux ARM64、Windows x64のいずれか
- Image：ベースとなるイメージを選択
- Enable this runner to generate custom images：チェック
ランナーグループを選択（同じグループ内のランナーのみが新バージョンを生成可能）

7.5 ステップ2：イメージ生成ワークフローの作成

7.5.1 文字列構文

jobs: 
  build:
    runs-on: my-image-generation-runner
    snapshot: my-custom-image
    steps:
      - name: "依存関係のインストール"
        run: |
          sudo apt-get update
          sudo apt-get install -y build-essential python3 nodejs

7.5.2 マッピング構文（バージョン指定）

jobs: 
  build:
    runs-on: my-image-generation-runner
    snapshot: 
      image-name: my-custom-image
      version: 2.*
    steps:
      - name: "開発ツールのインストール"
        run: |
          sudo apt-get update
          sudo apt-get install -y docker.io kubectl helm

7.6 バージョニングの仕組み

7.6.1 デフォルト動作

初回：1.0.0
2回目以降：マイナーバージョンがインクリメント（1.1.0、1.2.0...）

7.6.2 バージョン指定時

version: 2.*

メジャーバージョン2が存在しない場合：2.0.0を作成
メジャーバージョン2が存在する場合：2.1.0、2.2.0...とインクリメント

7.6.3 latestタグ

最新のワークフロー実行が常にlatestとしてタグ付けされます。

注意：パッチバージョン（x.x.1など）はサポートされていません。

7.7 ステップ3：カスタムイメージの確認

組織の Settings > Actions > Custom images
作成されたイメージの一覧を確認
イメージ名をクリックして詳細を表示

7.8 ステップ4：カスタムイメージの使用

7.8.1 新しいランナーの作成

"New runner" > "New GitHub-hosted runner"
Platform：イメージと同じプラットフォームを選択
Image："Custom"タブを選択し、作成したイメージを選択
Image version：
- Latest：自動的に最新バージョンを使用
- 特定バージョン：固定バージョンを使用
Size：イメージと同等以上のサイズを選択
ランナーグループを選択

7.8.2 ワークフローでの指定

jobs: 
  build:
    runs-on: my-custom-runner
    steps:
      - uses: actions/checkout@v5
      - name: "ビルドの実行"
        run: make build

ジョブログの"Set up job"セクションでイメージ名とバージョンを確認できます。

7.9 カスタムイメージの管理

7.9.1 イメージの削除

Custom images > 対象イメージを選択
削除アイコンをクリック
確認ダイアログで"Remove"

7.9.2 特定バージョンの削除

イメージ詳細ページで対象バージョンを選択
削除アイコンをクリック

8. ネットワーク設定とプロキシ対応

セルフホストランナーやラージャーランナーを隔離されたネットワーク環境で使用する場合、プロキシサーバーの設定が必要です。

8.1 プロキシ環境変数

変数名	説明	例
`https_proxy`	HTTPS通信用プロキシURL	`http://proxy.local:8080`
`http_proxy`	HTTP通信用プロキシURL	`http://proxy.local:8080`
`no_proxy`	プロキシをバイパスするホスト	`example.com,localhost,127.0.0.1`

基本認証も指定可能：

http://username:password@proxy.local:8080

8.2 環境変数の設定

8.2.1 Linux/macOS

export https_proxy=http://proxy.local:8080
export http_proxy=http://proxy.local:8080
export no_proxy=example.com,localhost,127.0.0.1

永続化する場合は/etc/environmentに記述：

echo 'http_proxy=http://proxy.local:8080' >> /etc/environment
echo 'https_proxy=http://proxy.local:8080' >> /etc/environment
echo 'no_proxy=example.com,localhost' >> /etc/environment

8.2.2 Windows（環境変数）

[Environment]::SetEnvironmentVariable("http_proxy", "http://proxy.local:8080", "Machine")
[Environment]::SetEnvironmentVariable("https_proxy", "http://proxy.local:8080", "Machine")

8.2.3 Windows（netsh）

プライベートネットワークを使用する場合、netshの設定も必要です：

netsh winhttp set advproxy setting-scope=machine settings="{\"Proxy\":\"proxy.local:8080\",\"ProxyBypass\":\"168.63.129.16;169.254.169.254\",\"AutoconfigUrl\":\"\",\"AutoDetect\":false}"

カスタムイメージ生成時はsetting-scope=machineを使用して、設定が永続化されるようにしてください。

8.3 Azure環境での特別な設定

Azureでランナーをホストする場合、Azureメタデータサービスへのアクセスを許可する必要があります。

no_proxyに以下のIPを追加：

no_proxy=168.63.129.16,169.254.169.254

168.63.129.16：Azure Wireserver（構成情報の取得）
169.254.169.254：Azure Instance Metadata Service（インスタンス情報の取得）

8.4 .envファイルでの設定

セルフホストランナーの場合、ランナーアプリケーションディレクトリ内の.envファイルで設定できます：

https_proxy=http://proxy.local:8080
http_proxy=http://proxy.local:8080
no_proxy=example.com,localhost,127.0.0.1

変更後、ランナーを再起動してください。

8.5 Dockerコンテナ用のプロキシ設定

ワークフローでDockerコンテナを使用する場合、Docker自体のプロキシ設定も必要です。

/etc/systemd/system/docker.service.d/http-proxy.confを作成：

[Service]
Environment="HTTP_PROXY=http://proxy.local:8080"
Environment="HTTPS_PROXY=http://proxy.local:8080"
Environment="NO_PROXY=localhost,127.0.0.1"

設定の反映：

sudo systemctl daemon-reload
sudo systemctl restart docker

8.6 TLS証明書検証の無効化

警告：本番環境では推奨されません。テスト目的のみで使用してください。

export GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY=1
./config.sh --url https://github.com/your-org/your-repo --token YOUR_TOKEN
./run.sh

8.7 プライベートネットワークへの接続

8.7.1 WireGuardを使用したオーバーレイネットワーク

WireGuardを使ってランナーとプライベートネットワークを接続できます。

name: WireGuard example

on:
  workflow_dispatch:

jobs:
  wireguard_example:
    runs-on: ubuntu-latest
    steps:
      - run: sudo apt install wireguard

      - run: echo "${{ secrets.WIREGUARD_PRIVATE_KEY }}" > privatekey

      - run: sudo ip link add dev wg0 type wireguard

      - run: sudo ip address add dev wg0 192.168.1.2 peer 192.168.1.1

      - run: sudo wg set wg0 listen-port 48123 private-key privatekey peer examplepubkey1234... allowed-ips 0.0.0.0/0 endpoint 1.2.3.4:56789

      - run: sudo ip link set up dev wg0

      - run: curl -vvv http://192.168.1.1

8.7.2 Tailscaleを使用したオーバーレイネットワーク

Tailscaleは商用製品ですが、NATトラバーサルが組み込まれており、設定が容易です。

name: Tailscale example

on:
  workflow_dispatch:

jobs:
  tailscale_example:
    runs-on: ubuntu-latest
    steps:
      - uses: tailscale/github-action@v2
        with:
          authkey: ${{ secrets.TAILSCALE_AUTHKEY }}

      - run: curl -vvv http://internal-service.tailnet-name.ts.net

9. 監視とトラブルシューティング

セルフホストランナーの稼働状況を監視し、問題が発生した際に迅速に対応するための方法を解説します。

9.1 ランナーの状態確認

9.1.1 ステータスの種類

Settings > Actions > Runners でランナー一覧を確認

ステータス表示：

Idle：接続済みでジョブ待機中
Active：ジョブ実行中
Offline：接続されていない（マシンがオフライン、アプリが停止、通信不可）

9.2 ネットワーク接続の確認

9.2.1 接続テストスクリプト

ランナーアプリケーションのconfig.shで接続チェックが可能です：

./config.sh --check --url https://github.com/your-org/your-repo --pat ghp_xxxxxxxxxxxx

各サービスへの接続状況がPASSまたはFAILで表示されます。

失敗した場合、_diagディレクトリのログファイルで詳細を確認できます。

9.3 ログファイルの確認

9.3.1 ランナーアプリケーションのログ

_diagディレクトリに保存されます。ファイル名はRunner_で始まり、起動時のUTCタイムスタンプが続きます。

cd _diag
ls -lt Runner_*
tail -f Runner_20241223-100000-utc.log

重要：エフェメラルランナーの場合、ログは外部に転送・保存する必要があります。

9.3.2 ジョブ実行の詳細ログ

各ジョブの詳細ログはWorker_で始まるファイル名で保存されます：

tail -f _diag/Worker_20241223-103000-utc.log

9.4 systemdサービスの監視

9.4.1 ジャーナルログの確認

# サービス名の確認
cat ~/actions-runner/.service

# リアルタイムログの監視
sudo journalctl -u actions.runner.your-org-your-repo.runner01.service -f

出力例：

Dec 23 14:57:07 runner01 runsvc.sh[962]: Starting Runner listener with startup type: service
Dec 23 14:57:07 runner01 runsvc.sh[962]: Started listener process
Dec 23 14:57:16 runner01 runsvc.sh[962]: √ Connected to GitHub
Dec 23 14:57:17 runner01 runsvc.sh[962]: 2024-12-23 14:57:17Z: Listening for Jobs
Dec 23 16:06:54 runner01 runsvc.sh[962]: 2024-12-23 16:06:54Z: Running job: testAction
Dec 23 16:07:10 runner01 runsvc.sh[962]: 2024-12-23 16:07:10Z: Job testAction completed with result: Succeeded

9.4.2 systemd設定の確認

systemctl cat actions.runner.your-org-your-repo.runner01.service

9.5 自動更新の監視

ランナーアプリケーションは自動的に更新されますが、バージョンが古すぎるとジョブを受け付けなくなります。

更新ログはRunner_ログファイルで確認：

[Dec 23 12:37:07 INFO SelfUpdater] An update is available.

詳細はSelfUpdateログファイルを参照してください。

9.6 コンテナ関連のトラブルシューティング

9.6.1 Dockerのインストール確認

sudo systemctl is-active docker.service

activeが表示されればDockerは稼働中です。

インストールされていない場合のエラー：

[2024-12-23 16:56:10Z INFO DockerCommandManager] Which: 'docker'
[2024-12-23 16:56:10Z INFO DockerCommandManager] Not found.
[2024-12-23 16:56:10Z ERR  StepsRunner] Caught exception from step: System.IO.FileNotFoundException: File not found: 'docker'

9.6.2 Docker権限の確認

以下のエラーが発生する場合、ランナーのサービスアカウントにDocker使用権限がありません：

dial unix /var/run/docker.sock: connect: permission denied

サービスアカウントの確認：

sudo systemctl show -p User actions.runner.your-org-your-repo.runner01.service

アカウントをdockerグループに追加：

sudo usermod -aG docker runner-user

9.6.3 Dockerエンジンの種類確認

snap経由でDockerをインストールした場合、環境変数にダッシュを含む名前が正しく渡らない問題があります。

確認方法：

which docker

/snap/bin/dockerと表示される場合、別の方法でDockerをインストールしてください。

9.7 ラージャーランナーのトラブルシューティング

9.7.1 ジョブが実行されない場合

確認項目：

同時実行数の制限
- Settings > Actions > Runners > 対象ランナー
- "Auto-scaling"の"Maximum Job Concurrency"を確認
リポジトリ権限
- エンタープライズレベルのランナーは、デフォルトでリポジトリレベルでは利用不可
- 組織管理者が明示的に有効化する必要あり
請求情報
- 有効なクレジットカードが登録されている必要あり
- 登録後、利用可能になるまで最大10分かかる場合あり
支出制限
- GitHub Actionsの支出制限が0より大きく設定されている必要あり
フェアユースポリシー
- ジョブ実行数に基づくスロットリングが発生している可能性

9.7.2 ジョブキュー時間が長い場合

原因：

ウォーム状態のVMが不足している
新しいVMのプロビジョニングが必要

改善策：

ジョブ実行頻度を上げることで、ウォームプールが維持される
24時間以内に実行されたランナーは5分以内に再利用可能

9.8 ワークフロー実行ログの確認

9.8.1 GitHub UIでの確認

リポジトリの Actions タブ
対象のワークフロー実行をクリック
ジョブをクリック
"Set up runner"や"Complete runner"セクションでスクリプト出力を確認

9.8.2 APIでのログ取得

gh api repos/your-org/your-repo/actions/runs/RUN_ID/logs > logs.zip

10. まとめ

GitHub Actionsのランナー機能は、セルフホストとGitHubホストの両方で柔軟な実行環境を提供します。本記事で解説した内容を要約します。

10.1 セルフホストランナーの活用ポイント

プライベートリポジトリでのみ使用
サービス化による自動起動
ジョブ前後のスクリプトによる環境管理
ラベルとグループによる柔軟なルーティング
コンテナカスタマイズによる高度な制御

10.2 ラージャーランナーの活用ポイント

高性能な実行環境
自動スケーリング
静的IPアドレス設定
カスタムイメージによる高速化
GPU対応

10.3 運用のベストプラクティス

セキュリティ：

プライベートリポジトリで使用
アクセス制御を適切に設定
定期的なアップデート

パフォーマンス：

カスタムイメージで依存関係を事前準備
適切な同時実行数の設定
ラベルによる適切なルーティング

監視：

ログの定期的な確認
ステータスの監視
自動更新の確認

ネットワーク：

プロキシ設定の適切な構成
プライベートネットワーク接続の検討
Azure環境での特別な設定

GitHub Actionsのランナー機能を適切に活用することで、効率的で安全なCI/CDパイプラインを構築できます。組織の要件に応じて、セルフホストとGitHubホストを組み合わせ、最適な実行環境を実現してください。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

Tips - ランナーの管理

Tips - ランナーの管理

目次

1. ランナーの種類と選択基準

1.1 GitHubホストランナー

1.2 セルフホストランナー

2. セルフホストランナーの導入と管理

2.1 追加手順

2.1.1 リポジトリレベルでの追加例

2.2 サービスとしての設定

2.2.1 Linuxでのサービス化

2.2.2 Debian系システムでの注意点

3. ラベルとグループによるルーティング制御

3.1 デフォルトラベル

3.2 カスタムラベルの作成

3.2.1 リポジトリランナーへのラベル追加

3.2.2 登録時にラベルを指定

3.3 ワークフローでのラベル指定

3.4 ランナーグループの活用

3.4.1 グループの作成

3.4.2 ワークフローでの指定

3.4.3 グループとラベルの組み合わせ

4. ジョブ前後のスクリプト実行

4.1 対応スクリプト言語

4.2 環境変数での設定

4.3 設定方法

4.3.1 .envファイルでの設定例

4.4 スクリプトの機能

4.5 終了コードの扱い

4.6 実行例

4.7 トラブルシューティング

4.7.1 パーミッションエラー

4.7.2 タイムアウト設定

4.7.3 ログの確認

5. コンテナのカスタマイズ

5.1 カスタマイズコマンド

5.2 実装の流れ

5.3 サンプル実装

5.4 prepare_jobの例

5.5 run_container_stepの例

5.6 必須設定

6. ラージャーランナーの活用

6.1 特徴

6.2 追加手順

6.3 組織レベルでの追加

6.4 リポジトリアクセスの許可

6.5 ワークフローでの使用

6.5.1 ラベルでの指定

6.5.2 グループとラベルの組み合わせ

6.6 自動スケーリングの設定

6.7 静的IPアドレスの設定

6.8 設定の変更

6.8.1 名前の変更

6.8.2 サイズの変更

6.8.3 イメージの変更

7. カスタムイメージの作成と運用

7.1 カスタムイメージのメリット

7.2 前提条件

7.3 作成の流れ

7.4 ステップ1：イメージ生成用ランナーの作成

7.5 ステップ2：イメージ生成ワークフローの作成

7.5.1 文字列構文

7.5.2 マッピング構文（バージョン指定）

7.6 バージョニングの仕組み

7.6.1 デフォルト動作

7.6.2 バージョン指定時

7.6.3 latestタグ

7.7 ステップ3：カスタムイメージの確認

7.8 ステップ4：カスタムイメージの使用

7.8.1 新しいランナーの作成

7.8.2 ワークフローでの指定

7.9 カスタムイメージの管理

7.9.1 イメージの削除

7.9.2 特定バージョンの削除

8. ネットワーク設定とプロキシ対応

8.1 プロキシ環境変数

8.2 環境変数の設定

8.2.1 Linux/macOS

8.2.2 Windows（環境変数）

8.2.3 Windows（netsh）