マルチ組織

ひとつのセルフマネージドデプロイメント上の複数の組織。フレームワークではオープンソースで、ObjectOS Enterprise ではライセンスとサポートが付きます。体制、Enterprise イメージに必要なライセンス、起動時の拒否、そして ObjectOS Cloud のほうが適する場合を説明します。

対応エディション

セルフマネージドの ObjectOS デプロイメントは、それ以上を求めない限りひとつの組織にサービスを提供します。ひとつのデプロイメント、ひとつのデータベースで複数の組織を実行するランタイムは、バージョン 17.4 から ObjectStack フレームワークでオープンソースになっています。ObjectOS でそれを提供するイメージは ObjectOS Enterprise です。すべての Enterprise ライセンスがマルチ組織を許可し、私たちのサポートが付きます。ライセンスがない場合、Enterprise イメージは壁のある体制での起動を拒否します。

どのエディションが適するか

求めるもの使うもの
自社のインフラストラクチャ上でひとつの組織ObjectOS Community、または任意の Enterprise ライセンス。これがデフォルトです。
自社のインフラストラクチャ上で、ひとつのデータベースに複数の組織ObjectOS Enterprise。ライセンスとサポートが付きます。ランタイムはオープンソースなので、ライセンスなしで自分のランタイムに組み込むこともできます（後述）。
デプロイメントを運用せずに、少数の組織ObjectOS Cloud。各組織がそれぞれのプランでサインアップし、分離は私たちが運用します。プランと AI シートを参照してください。
データベースを共有してはならない組織組織ごとにひとつのデプロイメント。どのエディションでも構いません

体制

OS_TENANCY_POSTURE は、組織どうしが壁で隔てられているかどうかを示します。

体制意味
singleひとつの組織がデプロイメントを所有します。隔てるものはありません。
group複数の組織がひとつのデータセットを共有し、グループのメンバーは組織をまたいで読み取ります。
isolated強固な壁です。ある組織のメンバーは、別の組織が存在することを知ることができません。

group と isolated が壁のある体制です。設定そのものについて 2 つの点があります。

  • 未設定は、何も知らせずに single になります。 体制を一度も設定しないデプロイメントはひとつの組織を実行し、何の異常も報告しません。ランタイムから見れば何も問題がないからです。求める体制を書いてください。
  • 綴りを誤った値は起動を拒否します。 壁のない体制にフォールバックすることはありません。

ライセンス

Enterprise イメージでは、壁のある体制には multiOrg を許可するライセンスが必要です。契約で機能が明示的に列挙されていない限り、すべての Enterprise ライセンスがそれを許可します。旧 business エディションとして発行されたライセンスは許可しません。起動バナーの features の行に、あなたのライセンスが許可するものが表示されます（ライセンス）。

それがない場合、ランタイムは起動を拒否し、最初の行で理由を示します。

✖ FATAL: tenancy posture 'isolated' requires an Enterprise license.

    Multi-organization isolation is a LICENSED Enterprise capability (ADR-0022,
    cloud#766). This runtime is not licensed for it, so the organization wall
    cannot be activated — and a deployment that asked for isolation must never
    serve traffic pretending to have it. Refusing to boot.

これはライセンスの失敗であり、パッケージの欠落ではありません。メッセージもそう述べています。示される修正は 2 つです。マルチ組織を許可するライセンスか、OS_TENANCY_POSTURE=single です。OS_ALLOW_DEGRADED_TENANCY はこれには適用されません。この拒否はアーティファクト固定の形態を含むすべての実行形態で同じで、アーティファクト固定の形態ではコード MULTI_ORG_NOT_LICENSED が付きます。

ライセンスが終了したときも同じです。壁のあるデプロイメントは、単一組織のデプロイメントのように Community に戻ることはありません。次の起動時に、有効なライセンスがインストールされるまで起動を拒否し、データはそのまま残ります。.env が壁のある体制を求めている場合、デプロイバンドルの license-check.sh がその拒否を事前に報告します。永続ライセンスがあれば、壁のあるデプロイメントは、そのライセンスが対象とするイメージで動作し続けます。詳細はライセンスにあります。

Community イメージの場合

公開されている Community イメージは、ひとつの組織を実行します。マルチ組織のランタイムを含んでいないため、そこでは壁のある体制は起動を拒否し、@objectstack/organizations を読み込めなかったと示します。この拒否は回避策として OS_ALLOW_DEGRADED_TENANCY=1 を示します。それを使うと壁が無効のまま起動し、組織の境界は強制されません。複数の組織を実行するために使わないでください。

マルチ組織のランタイム自体は、ObjectStack フレームワークでオープンソースです（@objectstack/organizations、Apache-2.0、17.4 以降）。ObjectOS で、ひとつのセルフマネージドデプロイメント上で複数の組織を、ライセンスと私たちのサポート付きで実行するエディションは Enterprise です。

実行形態

形態複数の組織
設定で記述（イメージ自身のアプリ、Compose のデフォルト）サポートされます。壁のある体制と、それを許可するライセンスが必要です
合成（公開済みのアプリと、このイメージのエンタープライズプラグイン）サポートされ、そのために作られた形態です。エアギャップライセンスのみで、OS_CLOUD_URL=off が必要です。どちらも起動時に強制されます（エアギャップ）。
アーティファクト固定（OS_ARTIFACT_URL）ライセンスの方法は同じですが、イメージの設定は実行されません。AI ガバナンスも AI シートもなく、AI の構築エージェントを閉じることもできません。代わりに合成の形態を使ってください。

構築エージェントが重要な理由：メタデータのスコープは組織ではなくデプロイメントです。共有データベースでは、ある組織の AI Builder の 1 回の操作が、ほかのすべての組織が動作しているスキーマを書き換えます。合成の形態では、OS_AI_STUDIO_AGENTS=ask がそれを閉じます。

壁のあるデプロイメントが宣言しなければならない決定

壁のある体制では、さらに 3 つのことを決めるまでランタイムは起動を拒否します。利用可能な値であれば、どれを宣言しても受け入れられます。決めないことは受け入れられません。

変数決めること
OS_AUTH_MEMBERSHIP_POLICY新しくサインアップした人が何に参加するか。メンバーシップそのものがテナントの境界である場合、通常の答えは invite-only です。
OS_AI_STUDIO_AGENTSどの AI エージェントをマウントするか：ask、build、またはその両方。上の理由から、通常の答えは ask です。
OS_PLATFORM_OWNER_EMAILプラットフォーム管理者が誰か。壁のある体制では、これがその立場の唯一の情報源です。

それぞれの詳細は環境変数にあります。単一組織のデプロイメントには、これらのチェックはありません。

壁が隔てるもの

壁が隔てるのは、組織のデータとメンバーシップです。デプロイメントに属するメタデータは隔てません。壁より強い分離はデプロイメントの分離です。自分のデータベースを持たなければならない組織には、専用のデプロイメントを用意します。

壁のあるデプロイメントでは、2 つの Enterprise の保護が組織ごとに適用されます。

  • Enterprise イメージでは、SSO のドメイン検証がデフォルトで有効です。組織が登録した ID プロバイダーは、プラットフォーム管理者が DNS の TXT レコードでその組織がドメインを管理していることを証明するまで、誰もサインインさせません。これがないと、ある組織のプロバイダーが、主張する任意のメールアドレス（別の組織のドメインを含む）でアカウントを作成できてしまいます。OS_SSO_DOMAIN_VERIFICATION=false で無効にできます。このデフォルトは設定で記述する形態と合成の形態に適用され、アーティファクト固定の形態には適用されません。4.3.1 より新しい Enterprise のリリースに含まれます。
  • 顧客管理の鍵は設定で記述する形態と合成の形態で動作するため、壁のあるデプロイメントは自社の KMS キーでシークレットを封印できます（ライセンス）。

次へ