セルフホストランナーとは?自前サーバーで動かすCI

セルフホストランナーって何のこと?

GitHub Actionsのような自動化サービスを使うと、コードをpushしたときにテストを走らせたりビルドしたりできます。このとき「実際に処理を実行するマシン」のことをランナーと呼びます。

ランナーには大きく2種類あって、サービス提供側が用意したマシンを借りる方式と、自分で用意したマシンを登録して使う方式があります。後者がセルフホストランナー(self-hosted runner)です。直訳すると「自分でホストする実行役」ですね。

例えるなら、コインランドリーと自宅の洗濯機の違いに近いです。コインランドリーは行けば必ず空いている機械があって、壊れても自分は気にしなくていい。ただし毎回お金がかかるし、機種は選べません。自宅の洗濯機は初期投資とメンテナンスが必要な代わりに、好きな機種を選べるし、乾燥機やアイロン台も横に置いておける。セルフホストランナーは後者です。

なぜわざわざ自分で用意するのか

クラウド側のランナーは便利なのですが、毎回まっさらな状態から始まるので、重い依存関係を毎回インストールし直すことになります。数GBのDockerイメージや機械学習用のライブラリを毎回落としていると、それだけで何分もかかる。自分のマシンなら前回のキャッシュがそのまま残っているので、2回目以降がぐっと速くなります。

それから、社内ネットワークの中にしかないデータベースやAPIに接続してテストしたい、というケース。外部のクラウドからは到達できない場所にあるリソースでも、社内に置いたランナーからなら普通に繋がります。

あとは単純にコストの話もあります。ジョブの実行時間が長かったり本数が多かったりすると、従量課金は積み上がっていきます。常時稼働させるサーバーを1台持ったほうが安くつく規模というのは実際に存在します。

どうやって動いているのか

仕組み自体はシンプルです。自分のマシンにランナー用のプログラムを入れて起動しておくと、そのプログラムがサービス側に「仕事ありませんか」と問い合わせ続けます。新しいジョブが発生すると受け取って、手元で実行し、ログと結果を返す。それだけです。

ポイントは、こちらから外向きに接続しにいく形になっていることです。外部からマシンに入ってくる通信を許可する必要がないので、ファイアウォールの内側に置いたマシンでも動かせます。社内ネットワークで使いやすいのはこのためです。

気をつけたいところ

一番大きいのはセキュリティです。ジョブとして流れてくるのは「誰かが書いたスクリプト」なので、それが自分のマシン上でそのまま実行されます。信頼できるメンバーだけのプライベートなリポジトリならまだしも、誰でもプルリクエストを送れる公開リポジトリでセルフホストランナーを使うのは危険です。悪意あるコードを送りつけられたら、そのマシンの中身が読まれたりネットワークの奥に入られたりしかねません。

もうひとつは「汚れが残る」こと。クラウドのランナーは毎回まっさらですが、自前のマシンは前のジョブが作ったファイルや書き換えた設定がそのまま残ります。これが速さの源でもあるのですが、「ローカルでは通るのにCIで落ちる」の逆パターン、つまり「CIでだけ通ってしまう」という厄介な状況を生むこともあります。ジョブごとにコンテナの中で実行する、といった工夫でこれを避けるのが定石です。

どんなときに検討すればいいか

最初から用意する必要はまずありません。クラウドのランナーで困っていないなら、管理コストを背負う理由がないからです。ビルドが遅くて待ち時間が辛いとか、社内リソースに繋がらなくて詰まったとか、請求額が気になってきたとか、そういう具体的な不満が出てきたタイミングで初めて検討するもの、くらいの感覚で十分です。