1. 導入：なぜSelf-hosted Runnerが必要なのか？
GitHub Actionsを利用していると、「社内のデータベースに直接アクセスしたい」「ビルドのたびに課金が発生するのを抑えたい」「GPUを使って学習を行いたい」といった課題に直面することがあります。GitHubが提供する標準のランナー（マネージドランナー）は非常に便利ですが、インターネットから隔離された環境や、特定のハードウェアスペックが必要な場合には対応できません。そこで登場するのが「Self-hosted Runners」です。これを導入することで、あなたの会社独自の環境でCI/CDジョブを実行できるようになり、インフラの自由度が劇的に向上します。
2. 基礎知識：Self-hosted Runnerの仕組み
Self-hosted Runnerとは、GitHub Actionsのジョブを処理するために、あなたが用意したサーバー上で動かす「専用エージェント」のことです。
仕組み：GitHubのリポジトリとあなたのサーバー間で通信を行い、GitHubから送られてくるジョブをサーバー側で受信して実行します。
メリット：
・社内ネットワークへのアクセス：ファイアウォール内にあるDBや社内APIに直接接続できます。
・コスト最適化：使い慣れたクラウドインスタンスやオンプレミスサーバーを活用することで、実行時間の課金を抑えられます。
・カスタマイズ性：OSの選定や、大容量メモリ、GPUなどの特殊なリソースを自由に追加できます。
3. 実装/解決策：構築の基本的な手順
Self-hosted Runnerの構築は、GitHubの管理画面からガイドに従うのが一番確実です。
1. GitHubのリポジトリ設定へ：「Settings」→「Actions」→「Runners」を開きます。
2. Runnerの追加：「New self-hosted runner」をクリックし、OSを選択します。
3. インストールコマンドの実行：表示されたシェルスクリプトを、対象のサーバー上で順に実行します。
4. 設定の完了：インストールが完了すると、サーバー上で「./run.sh」を実行することで、ジョブを受け付けられる待機状態（Idle）になります。
4. サンプルプログラム：ワークフローでの指定方法
作成したRunnerを実際に使うには、ワークフローファイル（.github/workflows/xxx.yml）内の「runs-on」セクションを書き換える必要があります。
name: Self-hosted Runner Test
on: [push]
jobs:
build:
# ここで「self-hosted」を指定します。
# もし特定のタグ（例：gpu-machine）を付けた場合、下記のように指定可能です。
runs-on: [self-hosted, linux, x64]
steps:
- name: チェックアウト
uses: actions/checkout@v4
- name: 社内DBへの接続確認
run: |
# サーバー内から社内ネットワーク上のDBへ接続するコマンド例
echo “社内ネットワーク内のDBに接続中…”
ping -c 3 192.168.1.100
- name: ビルド実行
run: |
# サーバーにインストール済みのツールを使ってビルド
echo “ビルドを開始します”
make build
5. 応用・注意点：現場で陥りやすい罠
Self-hosted Runnerを導入する際は、以下の点に注意してください。
・セキュリティリスク：ランナーが動いているサーバーは、リポジトリのコードを実行する権限を持ちます。信頼できないコードが実行されないよう、リポジトリへのアクセス権限を厳密に管理してください。
・クリーンアップの徹底：ジョブごとに環境を汚さないよう、Dockerコンテナ内で実行する設定にするか、スクリプトの最後で一時ファイルを削除する工夫が必要です。
・常時稼働の監視：サーバーがダウンするとCIが止まってしまいます。systemdなどを使用して、OS起動時に自動でランナーが立ち上がるように設定しておくのが「現場の鉄則」です。
適切に管理すれば、Self-hosted Runnerはインフラエンジニアにとって最強の武器になります。まずは小さなサーバーから構築を始めてみてください。
コメント