CI Runnerとは? Managed対Self-Hostedを解説

著者 Daniel Zoghalchali·Latchkey

runnerとは、単にCIのjobを実行するコンピュータのことです。選ぶ種類によって、パイプラインの速度、信頼性、コストが決まります。

継続的インテグレーションには、実際に作業を実行する場所 - checkout、build、テスト、deploy - が必要です。そのマシンが「runner」です。runnerはキューに入ったjobを取り上げ、各ステップを実行し、ステータスを報告し、(通常は)その後破棄されます。

hosted runner

CIプロバイダがオンデマンドでエフェメラルなVMを提供します。簡単でメンテナンスが不要ですが、分単位で課金され、マシンサイズは固定で、毎回cold startから始まります。重いbuildや特殊なbuildは遅かったり高価だったりします。

self-hosted runner

自分のマシン上でrunnerエージェントを動かします。サイズ、ツール、cacheをコントロールでき、スケール時には安くなることもあります - しかしパッチ適用、スケーリング、クリーンアップ、そして長期稼働のインフラに伴う信頼性の問題(ディスクが一杯になる、runnerが古くなる)は自分の責任になります。

managed runner

managed runnerプラットフォームは、フリートを自分で運用することなく、self-hostedスタイルのコントロールと経済性をもたらします。プロバイダがプロビジョニング、スケーリング、cache、クリーンアップを処理します。最良のものはその上に信頼性機能を追加します - 例えば、一時的な失敗やリソース失敗から自動的に回復し、不安定なjobがbuildを失敗させないようにします。

コストがどこから生じるか

jobが実行されている間(一部の構成ではキュー中も)課金される分。
すべてのjobを膨らませるcold startと遅い依存関係のインストール。
一時的な失敗によって引き起こされるre-run - 同じjobに二度支払う。
「念のため」使われる過大なrunner。

重要なポイント

runnerはCIのjobを実行するマシンです。
hosted = 簡単だが分単位課金でサイズ固定、self-hosted = コントロールできるが自分で運用する。
managed runnerは運用の負担なしにコントロールと経済性を両立させます。
一時的な失敗によるre-runは、隠れた回避可能なコストです。

よくある質問

What is What is a CI Runner? managed vs Self-Hosted explained?

Continuous integration needs somewhere to actually execute the work - checkout, build, test, deploy. That machine is the "runner". It picks up a queued job, runs each step, reports status back, and (usually) is torn down afterward.

Hosted runners?

Your CI provider supplies ephemeral VMs on demand. They are easy and require zero maintenance, but you pay per minute, have fixed machine sizes, and start cold each time. Heavy or specialized builds can be slow or expensive.

Self-hosted runners?

You run the runner agent on your own machines. You control the size, tools, and caching, and can be cheaper at scale - but you own patching, scaling, cleanup, and the reliability problems (disk fills up, runners go stale) that come with long-lived infrastructure.

Managed runners?

A managed runner platform gives you self-hosted-style control and economics without operating the fleet yourself. The provider handles provisioning, scaling, caching, and cleanup. The best ones add reliability features on top - for example, automatically recovering from transient and resource failures so flaky jobs do not fail your build.