Cells: Runner
| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| @rehab, @ | @josephburnett, @tmaczukin, @amknight, @skarbek | ~devops::verify | 2024-07-10 |
このブループリントは、セル型アーキテクチャにおける Runner サービスのアーキテクチャとロードマップについて説明します。
はじめに
GitLab Runner は、他の GitLab.com サービスと比較して比較的プロビジョニングと更新が容易なサービスです。
現在、SaaS Runners と Dedicated Runners の 2 つの典型的なセットアップがあります。後者は GRIT の実装によって強化された優れたセットアップです。
Cell のフィロソフィーに従って、Runner サービスは Cell ローカルサービスを実装するための最適な候補であり、そのコードベースへの変更はほとんど必要ありません（TBC）。
Cells 1.0 では、新しい顧客が最初の Cell に登録することが期待されており、このイテレーションでは、Runner のプロビジョニングに Dedicated ベータリリースの一環として行われた既存の作業を活用します。
アーキテクチャ
- Cell と Runner の間には 1:n の関係があります。つまり、1 つの Cell は多くの Runner を持てますが、Runner は 1 つの Cell にのみ登録されます。
- Legacy Cell（GitLab.com）は config-mgmt と chef-repo で管理された Runner を使用していますが、Cells は GRIT を組み込んだ Transistor に似たセットアップを使用しています。
注記: 現在 Runner のリファレンスアーキテクチャはありませんが、参考にできるリンクをいくつか示します:
- GitLab-runner/docs/fleet_scaling
- Create a test framework for testing runner fleet autoscaling configurations
- Document jump start configurations for an autoscaled runner fleet on Google Compute
- Runner Fleet Scaling and Configuration Best Practices Center
プロビジョニング
Cells は Dedicated に似たプロビジョニング設計とツールを採用することが期待されています。この場合、Runner は Transistor に似たツールを利用します。Transistor は簡潔に言えば、Terraform モジュールとバッシュスクリプトのコレクションです。
Transistor の開発ガイドラインに詳細な情報がありますが、Runner のプロビジョニングステップの簡略版は以下のようになります:
- Runner モデルを生成する。
- 次のいずれかのステップで Runner をプロビジョニングする:
- ./bin/prepare、./bin/onboard/、./bin/provision を実行する。
- または、Switchboard の MR を作成し、上記のスクリプトを順番に実行する。
Runner のデプロイメントパイプラインは、Instrumentor が GitLab インスタンスをデプロイした後の下流パイプラインとしてトリガーできます。これには、下流パイプラインがトリガーされる前に Instrumentor（または Switchboard 内のより上位のジョブなど）が Runner モデルを生成することが必要です。
Cells と Dedicated の違い
Dedicated チームは Runner が登録されている GitLab インスタンスへのアクセスが制限されていますが、Cells ではそうではありません。
SRE チームは Cell を完全に所有・管理するため、登録トークンの管理に外部との調整は必要なく、プロビジョニングスクリプトを使用して自動化できるステップとなります。
デプロイメント
理想的には、Cells: Runner は Cell 内の他のサービスと同様に管理されるべきです。
現時点では、GitLab.com SaaS Runners は GitLab.com グランドデプロイヤーと混同しないよう注意が必要な、Runner グループが実行・維持する個別のアドホックデプロイヤーツールを持っています。
Cells では、Runner サービスは Dedicated に似たツールを利用します。これは他のサービスと同様であり、可視性、可観測性、保守性を確保します。Dedicated の Runner は GRIT に強く依存しており、最終的に Dedicated と Cells の両方が利用するブルーグリーンメカニズムを導入することが約束されています。
可観測性
Dedicated における Runner の可観測性は現在進行中の作業です。Runner は他のサービスと同様に扱われ、現在 GitLab.com で使用されている記録ルールとダッシュボードを使用するべきです。
ロードマップ
ツールの集中化 を維持するために、2 つの未解決の質問があります:
- 最終的に Transistor を Instrumentor に統合し直すことについてどう思うか？
Transistor と Instrumentor を組み合わせると、「Runner への変更が全 Instrumentor デプロイメントプロセスを経由する必要があり、非常にコストが高く遅くなる可能性がある」（@amknight、2024）。さらに、両プロジェクトをモジュラー式に保つことで、QA テストプロセスが分離されているためより効率的で安全なリリースプロセスが可能になります（@skarbek、2024）。
- Runner のデプロイメントを Cell 内の他の GitLab サービスのデプロイメントに組み込むことについてどう思うか？
プロビジョニングで述べているように、これを実現するために下流パイプラインを使用できる可能性があります。
イテレーション [WIP]
Cells 1.0
small タイプの Linux Runner が利用可能になります。
Cells 1.5
Cells 2.0
FAQ [WIP]
Q1
A1
Q2
A2
参考
- @amknight (2024): !146768 (comment 1823581090)
- @skarbek (2024):!146768 (comment 1819418987)
