旧バージョンのドキュメントを参照しています。 最新のドキュメントはこちらをご参照ください。
ワークスペースの例
ワークスペースは、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において許可されているその他の操作を自由に行うことができます。