| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| proposed | - |
このドキュメントは作業中のものであり、セルズの設計のごく初期の状態を表しています。重要な点は文書化されていませんが、将来的には追加される予定です。これはCellsの可能性のあるアーキテクチャの一つであり、どのアプローチを実装するか決める前に、代替案と比較検討するつもりです。この文書化は、このアプローチを選ばなかった理由を文書化できるよう、これを実装しないと決めた場合でも残しておきます。
セルズ管理エリア
私たちのCellsアーキテクチャの提案では、GitLabの全ての管理関連のテーブルを共有する予定です。これにより、すべてのCellを一つのインターフェイスでシンプルに管理することができ、異なるCellで設定が分岐するリスクを減らすことができます。そのため、すべてのCellにまたがるデータを管理するためのAdmin Areaページに課題が生じます。
1.定義
管理エリアのページはどのセルからも提供されるかもしれませんし、1つのセルからも提供されるかもしれないので、「インスタンス全体」にまたがるデータを含む管理エリアのページには影響があります。多くのセルにまたがるデータを持つ管理エリアの多くの部分がすでにあります。例えば、全てのグループ、プロジェクト、トピック、ジョブ、アナリティクス、アプリケーションなどのリストです。また、”Background Jobs “や “Background Migrations “ページのような多くのセルにまたがる管理モニタリング機能もあります。
2.データフロー
3.提案
これらの例外をどのように扱うか、いくつかの選択肢の中から決める必要があります：
- これらのページをすべて、セルごとに専用の管理セクションに移動させます。おそらくURLは
/cells/<cell_id>/adminのように1つのセルにルーティングできるようにする必要があるでしょう。そうすればセルごとにこれらのデータを表示することができます。これらのページは全てのセルで共有される設定をコントロールする他の管理エリアページとは区別されます。また、これがセルフマネージドカスタマーにどのような影響を与えるのか、そして GitLab のシングルセルインスタンスにこれを表示すべきかどうかも検討する必要があります。 - すべてのセルからデータを取得し、単一の UI で表示できるようにするために、このデータの集約インターフェースをいくつか構築しましょう。これは、すべてのデータを一目で見たりフィルタリングしたりする必要のある管理者にとって有益でしょう。しかし、全てのセルが完全に独立して設計されている場合、このような集計を構築するのは非常に厄介であり、セル間の互換性に関してもより厳しい要件が課されることになります。
以下の概要では、現在の管理エリアに含まれる各機能がどのレベルで管理されるかを説明します：
| 機能 | クラスター | セル | 組織 |
|---|---|---|---|
| 不正利用レポート | |||
| 分析 | |||
| アプリケーション | |||
| デプロイキー | |||
| ラベル | |||
| メッセージ | ✓ | ||
| モニタリング | ✓ | ||
| サブスクリプション | |||
| システムフック | |||
| 概要 | |||
| 設定 - 全般 | ✓ | ||
| 設定 - インテグレーション | ✓ | ||
| 設定 - リポジトリ | ✓ | ||
| 設定 - CI/CD (1) | ✓ | ✓ | |
| 設定 - レポーター | ✓ | ||
| 設定 -メトリクス | ✓ | ||
| 設定 - サービス利用データ | ✓ | ||
| 設定 - ネットワーク | ✓ | ||
| 設定 - 外観 | ✓ | ||
| 設定 - 環境設定 | ✓ |
(1) 具体的な設定によって、クラスター・レベルで管理されるものもあれば、セル・レベルで管理されるものもあります。