Cells ADR 011: Cell 固有の設定
コンテキスト
Cell は Instrumentor によって使用されるテナントモデルを使用してプロビジョニングされます。 Instrumentor とテナントモデルはどちらも GitLab.com と GitLab Dedicated の共有コンポーネントであり、 たとえば以下のような Cell にのみ有効になる設定に対して、テナントのプロビジョニング/設定のコードパスを分離する方法が必要です。
決定事項
テナントモデル内に cells という単一フィールドを追加します。
cells はオブジェクトで、Cell 設定に固有のキーを持ちます。
たとえば以下のようになります。
{
"tenant_id" : "c01j2gdw0zfdafxr6"
...
"cells": {
"cell_id": 1
}
}
cells.cell_id は必須フィールドで、このテナントが Cell であることを示します。
デフォルトでは cell はオプションのため、既存のテナントモデルは引き続き機能し、
新しい GitLab Dedicated テナントはこのフィールドを省略できます。
cell.cell_id が指定された場合は設定より規約を優先し、
テナントを Cell として実行するために必要な追加設定をすべてトリガーします。
たとえば以下のようなものです。
_gitlab_sessionプレフィックス- ホスト設定
- Cell 向けの GitLab Dedicated カスタム ApplicationSettings の無効化
- オンボーディング時の PAM のエンタイトルメント（Cell テナントかどうかを確認し、正しいグループを追加します）
cells.cell_id の値は Topology Service から取得されるため、両者が一致している必要があります。
これにより、Topology Service がその Cell を認識してトラフィックをルーティングできるようになります。
結果
- 単一の設定フィールドがすべての Cells 設定を有効にする設定より規約に従うため、テナントモデルに複数の設定フィールドを追加せずに済みます。
- Cell を完全にプロビジョニングする前に、Topology Service が使用する
cells.cell_idを把握しておく必要があります。 cell_idで規約を作成できない場合にのみ、cellsオブジェクトに新しいフィールドを追加します。
代替案
cells: trueという新しいフィールドを作成して同じことを実現する方法がありますが、cell_idとtenant_idを結合すべきでないため、別の設定フィールドがcell_idに対してもやはり必要になります。両者を結合すると以下のような問題が生じます。tenant_idをセッション/PAT プレフィックスとして使うには長すぎます。- ユーザーに
tenant_idが公開されてしまうことは望ましくありません。 - アプリケーションロジックが、異なる制約と意味を持つ
tenant_idと結合されてしまいます。
- 各設定フィールドごとにフィールドを作成する方法は、テナントモデルの設定が膨大になり、テナントを Cell として機能させるためにどのフィールドが必要かを把握することが困難になります。
- Cell 向けの新しいリファレンスアーキテクチャを作成する方法は、リファレンスアーキテクチャは主に GitLab テナントの大小を定義するものであり、その意味を過負荷にすることになります。また、
cell_idのような特定の値はどこかで設定可能にする必要があります。 - リファレンスアーキテクチャオーバーレイを使用する方法も、前述のリファレンスアーキテクチャの問題と同様に、GitLab テナントの大小に関するものであるという問題があります。
