Cells: CI/CD カタログ
1. 定義
CI/CD カタログは、ユーザーがコンポーネントを通じてパイプライン設定を探して再利用できる機能です。コンポーネントはプロジェクトから公開し、他のプロジェクトで使用できる再利用可能なパイプラインスニペットです。
現在のアーキテクチャ: CI/CD カタログは インスタンス全体 に及んでおり、GitLab インスタンス全体のプロジェクトから公開されたコンポーネントをリストアップします。GitLab.com では、ユーザーは https://gitlab.com/explore/catalog ですべての公開コンポーネントを参照でき、コンポーネントはインスタンス FQDN を使用して参照されます（例: component: $CI_SERVER_FQDN/components/sast/[email protected]）。
2. 問題の説明
CI/CD カタログのインスタンス全体の性質は、Cells アーキテクチャにおいて 2 つの根本的な課題を生み出しています:
2.1. 課題 1: Cells 間でのコンポーネントの使用
Cells では、Organizations および Groups とプロジェクトは分離されています。ある Cell 内のプロジェクトが別の Cell 内のプロジェクトからコンポーネントをインクルードしようとすると、Rails モノリスはコンポーネントデータにアクセスできません。なぜなら:
- 各 Cell は独自のデータベースを持ち、他の Cell のデータをクエリできません
- すべての Cell は同じ FQDN（
gitlab.com）を共有しているため、URL だけではローカルと Cell 間コンポーネントを区別できません - 現在のコンポーネント解決ロジック（
Ci::Components::InstancePath）はすべてのコンポーネントが同じデータベースにあることを前提としています
影響: プロジェクトは異なる Cell で公開されたコンポーネントを使用できず、GitLab.com でのカタログの有用性が大幅に制限されます。
2.2. 課題 2: コンポーネントの公開と一覧表示
カタログ一覧ページ（https://gitlab.com/explore/catalog）は現在、Rails モノリスのデータベース（Ci::Catalog::Listing）からすべての公開コンポーネントをフェッチします。複数の Cell では:
- Cell 2 で公開されたコンポーネントは Cell 1 からカタログを閲覧した場合に表示されません
- すべての Cell からコンポーネントを集計して表示するメカニズムがありません
- コンポーネントのディスカバリーはユーザー自身の Cell に限定されます
影響: カタログの主な価値提案である、GitLab.com インスタンス全体で再利用可能なコンポーネントを発見することが失われます。
2.3. 課題 3: 使用データと内部メトリクス
上記の課題に部分的に関連していますが、公開カタログは使用数やアナリティクスも表示します。このトラッキングがどのように行われるかの出発点として Ci::Catalog::Resources::Components::LastUsage と AggregateLast30DayUsageService を参照してください。これらのアナリティクスはインスタンス全体のデータを引き続き表示する必要があります。
3. 提案されるソリューション
3.1. Cells 間でのコンポーネントの使用（Issue #456843）
アプローチ: Cell 間コンポーネントのインクルードをリモートインクルードとして扱う。
コンポーネントがインクルードされる場合:
- コンポーネントプロジェクトが現在のプロジェクトと同じ Organization にあるかを確認します。
- 存在する場合は、ローカルでコンポーネントをフェッチします（同じ Cell）
- 存在しないが FQDN が現在のインスタンスと一致する場合は、別の Cell にあると仮定します
- 他の Cell への HTTP リクエストを通じてコンポーネントをフェッチします
- HTTP Router サービス（Cells 向けに実装中）がリクエストを正しい Cell にルーティングします
利点:
- セルフマネージド/Dedicated インスタンスが GitLab.com コンポーネントを使用できるようにする可能性があります（エアギャップされていない場合）
- 既存のリモートインクルードインフラストラクチャを活用します
- 公開されたコンポーネントバージョンは不変のため、積極的なキャッシュが使用できます
- 懸念点: 非公開コンポーネントのパフォーマンスへの影響は評価が必要です - 未公開コンポーネントへのクロスインスタンスアクセスは許可すべきか、ブロックすべきか?
3.2. コンポーネントの公開と一覧表示（Issue #442195）
アプローチ: GitLab.com 向けに Rails モノリスの外部に別のサービスを作成する。
このサービスは:
- GitLab.com のみで動作する（セルフマネージド/Dedicated には同梱されない）
- すべての Cell からのコンポーネント公開のターゲットになる
https://gitlab.com/explore/catalogページを提供する- 発見のためにすべての Cell からコンポーネントを集計する
- インスタンス全体のコンポーネントアナリティクス/使用データを処理する
検討された代替アプローチ:
- Elasticsearch クロスクラスター検索: Cell 間の検索を可能にする可能性がありますが、調査が必要です
- Organization スコープのカタログ: カタログを Organization の境界に限定する（カタログの目的と相反する）
- リポジトリミラーリング: グローバルな一意性の問題とパスの不整合が生じます
課題:
- Pipeline Authoring グループにとって稼働時間要件のあるサービスを所有することは前例がありません
- SRE のサポートと現在のチームの範囲を超えた運用の専門知識が必要です
- メトリクスと使用状況のトラッキングは、サービスも解決する必要がある大きな課題です
- サービスのアーキテクチャとデプロイに関して多くの未知事項が残っています
4. タイムラインとスコープ
Cells 1.0（FY25-Q4）
Protocells の移行
現在の状況: この作業は Protocells Cohort B の移行（Epic &1758）の一部です
優先度: 優先度 1-2、健全性ステータスは「要注意」としてマークされています
5. 関連する作業
AI カタログ（Issue #549767）
AI カタログは Cells とセルフマネージド/Dedicated サポートに関して同様の課題に直面しています:
- データベースアーキテクチャはグローバルではなく Organization レベル（
gitlab_main_org）でデータを格納する必要があります - クロス Organization クエリとデータ同期が課題です
- 提案されたソリューション: Organizations が別の Organization のカタログから AI カタログデータをダウンロードできる API ベースのカタログ入力
- 「GitLab 公式」フィルタリングが信頼できるコンポーネントの識別に役立ちます
セルフマネージドと Dedicated インスタンス
セルフマネージドと Dedicated インスタンスは引き続きシングル Cell として動作するため、Cell 間の課題は発生しません。ただし:
- Cell 間コンポーネント使用ソリューション（#456843）は、手動ミラーリングなしで SM/Dedicated が GitLab.com コンポーネントを使用できるようにする可能性があります
- 現在の回避策では手動のリポジトリミラーリングが必要であり、煩雑です
6. 未解決の質問
- サービスの所有権: Pipeline Authoring グループはどのように新しいサービスの運用責任を負いますか?
- キャッシュ戦略: Cell 間 HTTP リクエストによるパフォーマンス低下を回避するためにどのようなキャッシュメカニズムが必要ですか?
- グローバル検索: これは Cells のグローバル検索に関する広範な戦略とどのように整合しますか（Issue #465563）?
- 探索ページ: 他の
/exploreページ（プロジェクト、グループなど）は Cell 間ディスカバリーをどのように処理しますか?
