Cells: 管理エリア
このドキュメントは作業中であり、Cells 設計の非常に初期の状態を表しています。重要な側面は文書化されていませんが、将来追加する予定です。これは Cells のアーキテクチャの 1 つの可能性であり、実装するアプローチを決定する前に代替案と比較検討する予定です。このアプローチを実装しないと決定した場合でも、このアプローチを選択しなかった理由を文書化できるよう、このドキュメントは保持されます。
私たちの Cells アーキテクチャ提案では、GitLab のすべての管理関連テーブルを共有することを計画しています。 これにより、1 つのインターフェースですべての Cells を簡単に管理でき、異なる Cells で設定が乖離するリスクが軽減されます。 しかし、すべての Cells にまたがるデータを管理できる管理エリアページには課題が生じます。
1. 定義
管理エリアページに「インスタンス全体」にまたがるデータが含まれる場合、管理エリアページがいずれかの Cell または場合によっては単一の Cell のみによって提供される可能性があるため、課題が生じます。 管理エリアには、多数の Cells にまたがるデータを持つ部分がすでに多くあります。 例えば、すべてのグループ、プロジェクト、トピック、ジョブ、アナリティクス、アプリケーションなどのリストです。 また、「バックグラウンドジョブ」や「バックグラウンドマイグレーション」ページのような、多数の Cells にまたがる管理監視機能も管理エリアにあります。
2. データフロー
3. 提案
これらの例外を処理するための方法を、いくつかの可能なオプションとともに決定する必要があります:
- これらのページをすべて専用の Cell ごとの管理セクションに移動させます。URL は
/cells/<cell_id>/adminのように単一の Cell にルーティング可能にする必要があり、Cell ごとにデータを表示できます。これらのページは、すべての Cells で共有される設定を制御する他の管理エリアページとは区別されます。また、これがセルフマネージド顧客に与える影響や、GitLab のシングル Cell インスタンスに対して表示すべきかどうかを検討する必要があります。 - このデータの集計インターフェースを構築し、すべての Cells からフェッチして単一の UI で表示できるようにします。これは、どの Cell にデータがあるか分からない場合でも、すべてのデータを一目で確認してフィルタリングする必要がある管理者に有益かもしれません。ただし、このような集計を構築することは、すべての Cells が完全に独立して設計されている場合には非常に難しく、Cells 間の互換性に厳しい要件が課されます。
以下の概要は、現在の管理エリアに含まれる各機能がどのレベルで管理されるかを示しています:
| 機能 | クラスター | Cell | Organization |
|---|---|---|---|
| 不正使用報告 | |||
| アナリティクス | |||
| アプリケーション | |||
| デプロイキー | |||
| ラベル | |||
| メッセージ | ✓ | ||
| 監視 | ✓ | ||
| サブスクリプション | |||
| システムフック | |||
| 概要 | |||
| 設定 - 全般 | ✓ | ||
| 設定 - インテグレーション | ✓ | ||
| 設定 - リポジトリ | ✓ | ||
| 設定 - CI/CD (1) | ✓ | ✓ | |
| 設定 - レポーティング | ✓ | ||
| 設定 - メトリクス | ✓ | ||
| 設定 - サービス使用データ | ✓ | ||
| 設定 - ネットワーク | ✓ | ||
| 設定 - 外観 | ✓ | ||
| 設定 - 設定 | ✓ |
(1) 特定の設定によっては、クラスターレベルで管理されるものと Cell レベルで管理されるものがあります。
