Skip to content
Latchkey

runner サイドカーとは? - job のそばで動くヘルパープロセス

runner サイドカーとは、runner の上または近くでメイン job と並んで動く二次的なプロセスで、job 自体を変更することなく、キャッシュ、モニタリング、失敗検知などの補助サービスを提供します。

コンテナから借りてきた「サイドカー」パターンは、主要なワークロードのそばでヘルパーを実行します。runner 上では、サイドカーが機能(キャッシュプロキシ、メトリクスコレクター、自己修復エージェント)を、job に対して透過的に追加できます。

サイドカーパターン

サイドカーとは、メイン job が担わなくて済むように横断的な関心事を処理するコンパニオンプロセスです。runner のライフサイクルとネットワークを共有しますが、あなたの build ロジックとは分離されたままです。

サイドカーが runner 上で行うこと

  • キャッシュプロキシ: 依存関係やレイヤーのキャッシュをローカルで提供・保存する。
  • 可観測性: job ごとのログ、メトリクス、リソース使用状況を収集する。
  • 自己修復: 一時的な失敗を監視し、リトライをトリガーする。
  • セキュリティ: ネットワークアクセスを仲介し、ポリシーを強制する。

なぜ透過的なのか

サイドカーは job の内部ではなくそばで動くため、あなたの workflow の YAML は通常変更する必要がありません。プラットフォームがサイドカーを組み込み、job は作者が存在に気づかないまま恩恵を受けます。

マネージド runner 上のサイドカー

マネージドプラットフォームは、workflow の変更を求めることなく、キャッシュや自己修復のような機能を提供するためにサイドカーを使います。ヘルパーが job のそばで重い作業を、見えない形で行います。

サイドカー vs サービスコンテナ

GitHub Actions の「サービスコンテナ」は、job が通信するために workflow の中で宣言するもの、たとえばデータベースなどです。プラットフォームのサイドカーは、横断的な関心事のために runner インフラによって組み込まれます。どちらも job のそばで動きますが、一方はあなたが設定するもので、もう一方はプラットフォームのものです。

重要なポイント

  • runner サイドカーは、job のそばで動くヘルパープロセスである。
  • キャッシュ、モニタリング、自己修復、セキュリティを提供する。
  • 透過的であり、workflow は通常変更を必要としない。
  • マネージドプラットフォームはサイドカーを使って機能を見えない形で追加する。

関連ガイド