旧バージョンのドキュメントを参照しています。最新のドキュメントはこちらをご参照ください。

ワークスペースの例

ワークスペースは、Kongエンティティをセグメント化する方法を提供します。ワークスペース内のエンティティは、他のワークスペース内のエンティティから分離されます。これは、HTTPメソッド、URI、またはホストのような、サービスまたはルートにアタッチされた情報の断片であり、与えられたプロキシサイドリクエストを対応するアップストリームサービスにルーティングすることを可能にします。

ワークスペースでサービス（またはルート）を構成する管理者は、自分のサービスまたはルートに流入するトラフィックが他のワークスペースのサービスまたはルートに飲み込まれることを望みません。Kongは特定の措置が講じられることを条件に、こうした望ましくない動作を防止できます。以下では、競合の有無を判断するためにKongが採用する競合検出アルゴリズムについて概説しています。

Kongはサービスまたはルートの 作成または変更 時に内部ルーターを実行します。
- 一致するルーティングルールを持つサービスまたはルートが見つからない場合は、作成または変更が行われます
- ルーティングルールが一致するサービスまたはルートが 同じワークスペース内に 見つかった場合、続行します。
- サービスまたはルートが 別のワークスペースで 見つかった場合：
  - 一致するサービスまたはルートに host 値が 関連付けられていない 場合 —409 Conflict
  - 一致するサービスまたはルートのhostがワイルドカードの場合
    - 同じ場合は次のとおり競合が報告されます—409 Conflict
    - 等しくない場合は、続行
  - 一致するサービスまたはルートのhostが絶対値で、紛争が報告されている場合—409 Conflict

エンティティの中には、どのワークスペースにも属さない グローバル エンティティもあります。特に、CA 証明書（ca_certificates エンティティ）はグローバルであり、mTLS ハンドシェイクの際のクライアント証明書の検証に使用されます。ワークスペースが不明な場合、SSL ハンドシェイクは HTTP リクエストを受信する前に行われます。

一部のエンティティはワークスペースに存在しますが、競合を避けるには、ワークスペースをまたがって一意である必要があります。

snis エンティティの name フィールドは、ワークスペースが決定される前の SSL ハンドシェイクフェーズで使用されるため、ワークスペース全体で一意である必要があります。
vaultsエンティティの prefix フィールドは、vault参照URIのホスト部分であり、ワークスペース情報が利用できないコンテキスト、例えばKongの起動時に kong.conf をロードする際に使用される可能性があります。

デフォルトのワークスペース

Kong は、default という名前のデフォルトのワークスペースで起動します。このワークスペースは、Kong に存在するすべてのエンティティをグループ化します。

以前のバージョンでの操作中に作成されたエンティティと、古い Kong バージョンから移行する場合。
移行時に Kong が作成するエンティティ（たとえば、利便性のために移行時にプロビジョニングされる RBAC 認証情報）

また、特定のワークスペースに明示的に割り当てられることなく作成されたエンティティを保持します。

とはいえ、デフォルトのワークスペースは他のワークスペースと同様にワークスペースであり、唯一の違いは移行時にKongによって作成されることに留意してください。

ワークスペースでの API の使用

ワークスペースを指定しないリクエストは、defaultワークスペースを対象とします。

別のワークスペースをターゲットにするには、エンドポイントの前にワークスペース名または ID を付けます。

http://localhost:8001/<WORKSPACE_NAME|ID>/<endpoint id="sl-md0000000">

たとえば、ワークスペースを指定しない場合は、このリクエストは、default ワークスペースからサービスのリストを取得します。

curl -i -X GET http://localhost:8001/services

このリクエストはワークスペースSREからすべてのサービスを取得します。

curl -i -X GET http://localhost:8001/SRE/services

ワークスペースとそのエンティティを一覧化

新規Kong Gatewayインストールでは、次のリクエストを送信します。

curl -i -X GET http://localhost:8001/workspaces

応答：

{
  "total": 1,
  "data": [
    {
      "created_at": 1529627841000,
      "id": "a43fc3f9-98e4-43b0-b703-c3b1004980d5",
      "name": "default"
    }
  ]
}

ワークスペースの作成

もっと興味深い例は、エンティティをチームでセグメント化することです。たとえば、チームAとチームBがあるとしましょう。

これらの各チームには独自のエンティティ（例えば、アップストリームサービスやルート）があり、その構成とトラフィックを分離したいと考えています。ワークスペースを使用することで、それを実現できます。

チームAを作成します。

curl -i -X POST http://localhost:8001/workspaces \
  --data name=teamA

応答：

{
    "created_at": 1528843468000,
    "id": "735af96e-206f-43f7-88f0-b930d5fd4b7e",
    "name": "teamA"
}

チーム B を作成します。

curl -i -X POST http://localhost:8001/workspaces \
  --data name=teamB

応答：

{
  "name": "teamB",
  "created_at": 1529628574000,
  "id": "a25728ac-6036-497c-82ee-524d4c22fcae"
}

この時点で、ワークスペースを一覧表示すると、合計3つが表示されます。デフォルトのワークスペースと2つのチームワークスペースです。

{
  "data": [
    {
      "created_at": 1529627841000,
      "id": "a43fc3f9-98e4-43b0-b703-c3b1004980d5",
      "name": "default"
    },
    {
      "created_at": 1529628818000,
      "id": "5ed1c043-78cc-4fe2-924e-40b17ecd97bc",
      "name": "teamA"
    },
    {
      "created_at": 1529628574000,
      "id": "a25728ac-6036-497c-82ee-524d4c22fcae",
      "name": "teamB"
    }
  ]
  "total": 3,
}

異なるワークスペース内のエンティティには同じ名前を指定できます。

異なるワークスペースに属するさまざまなチームは、それぞれのエンティティに任意の名前を付けることができます。その例を挙げると、チームAと Bはguestという名前の特定のコンシューマを望んでいるとします。これは、同じユーザー名を共有する各チームの別のコンシューマです。

以下で、teamAにguestという名前のコンシューマを作成します。

curl -i -X POST http://localhost:8001/teamA/consumers \
  --data username=guest

応答：

{
    "created_at": 1529703386000,
    "id": "2e230275-2a4a-41fd-b06b-bae37008aed2",
    "type": 0,
    "username": "guest"
}

以下で、teamBにguestという名前のコンシューマを作成します。

curl -i -X POST http://localhost:8001/teamB/consumers \
  --data username=guest

応答：

{
    "created_at": 1529703390000,
    "id": "8533e404-8d56-4481-a919-0ee35b8a768c",
    "type": 0,
    "username": "guest"
}

これにより、チームAとチームBは、それぞれ独立してguestコンシューマを操作できるようになり、認証プラグインの選択や、ワークスペースではないKongにおいて許可されているその他の操作を自由に行うことができます。