1. 導入：なぜARCが必要なのか？
CI/CDパイプラインを運用していると、「ビルド待ちが長すぎる」「ビルド環境のゴミが残って動作が不安定になる」といった課題に直面しませんか？GitHubが提供する標準のランナーでは、規模が大きくなるとコストや柔軟性に限界があります。そこで登場するのが「GitHub Actions Runner Controller (ARC)」です。ARCを使えば、Kubernetes（K8s）上にセルフホストランナーを動的に生成し、ジョブがある時だけPodを立ち上げ、終われば即座に破棄できます。これにより、常にクリーンな環境を保ちつつ、無駄なコストを徹底的にカットできます。
2. 基礎知識：ARCを支える仕組み
ARCを理解するために、まずは以下の用語を押さえましょう。
・セルフホストランナー: GitHubの管理下ではなく、自分たちのインフラ上で動作するビルド実行環境のことです。
・Ephemeral Runners（使い捨てランナー）: 1つのジョブを終えたら即座に消滅するランナーです。環境の汚染を防ぎ、セキュリティを高めるために必須の概念です。
・Auto-scaling: ジョブのキュー（待ち行列）の長さを監視し、Podの数を自動的に増減させる仕組みです。
3. 実装：ARCの導入手順
ARCの導入には「Helm」というKubernetesのパッケージ管理ツールを使用します。
1. GitHub Appの作成: GitHub上でARC専用のアプリを作成し、リポジトリへのアクセス権限を付与します。
2. 認証情報の登録: 作成したアプリのIDや秘密鍵をK8sのSecretとして保存します。
3. ARCのインストール: Helmチャートを使ってコントローラーをクラスタにデプロイします。
4. Runner Deploymentの定義: どのリポジトリを監視し、どれくらいの負荷でスケールするかを設定ファイルで定義します。
4. サンプルプログラム：RunnerDeploymentの定義
以下は、特定のGitHubリポジトリに対して動的にランナーを配置するための設定例です。
runner-deployment.yaml
apiVersion: actions.summerwind.dev/v1alpha1
kind: RunnerDeployment
metadata:
name: example-runner
spec:
template:
spec:
# 監視対象のリポジトリを指定
repository: your-org/your-repo
# 負荷に応じて自動スケールさせる設定
replicas: 1
minReplicas: 1
maxReplicas: 5 # ジョブが増えたら最大5つまでPodを増やす
—
apiVersion: actions.summerwind.dev/v1alpha1
kind: HorizontalRunnerAutoscaler
metadata:
name: example-autoscaler
spec:
scaleTargetRef:
name: example-runner
minReplicas: 1
maxReplicas: 5
metrics:
- type: TotalNumberOfQueuedAndInProgressWorkflowRuns # ジョブの数に応じてスケールさせる
repositoryNames:
- your-org/your-repo
5. 応用・注意点：現場で陥りやすい罠
ARCを運用する際に注意すべき点がいくつかあります。
・リソース制限: K8sのNamespaceに対してリソース制限（ResourceQuota）をかけすぎると、ビルド中にメモリ不足でPodが強制終了されることがあります。ビルドに必要なリソースを事前に計測し、余裕を持った設定を心がけましょう。
・セキュリティ: セルフホストランナーはクラスタ内から外部（GitHub等）へアクセスします。ネットワークポリシーの設定を忘れずに行い、不要な通信をブロックしてください。
・ゴミデータの蓄積: Ephemeral Runnerであっても、ビルドのたびにキャッシュを利用すると、永続ボリューム（PVC）を圧迫する可能性があります。キャッシュのクリーンアップ設定を適切に管理することが、安定運用の鍵となります。
ARCは少し学習コストがかかりますが、一度構築してしまえばCI/CDの体験が劇的に向上します。ぜひ今のパイプラインに導入を検討してみてください。