Salesforce Docs Portal

専用ロードバランサーのマッピングルール

CloudHub 専用ロードバランサー (DLB) は、クライアントからの要求を VPC 内でデプロイされている Mule アプリケーションに転送します。 マッピングルール​により、DLB が受信する要求を (HTTP ホストヘッダーによって一致ルールを特定して) 異なる Mule アプリケーション名とドメインに転送できます。

マッピングルールは、DLB の作成時に定義するか、または Runtime Manager、コマンドラインインターフェース (CLI)、CloudHub API を使用して既存の DLB に追加できます。

シンプルな一致ルールを作成する場合、1 つの入力アドレスが定義済みの出力 (アプリケーションのエンドポイント) に一致します。 リテラル一致の代わりにパターンを使用して、変数のような入力テキストをエンドポイントに対して照合することができます。

ルールの優先度は順序によって決まります。 リスト中で最初に一致したルールが適用されます。

マッピングルールを定義していない場合、DLB はデフォルトのマッピングルールを作成して使用します。 デフォルトのマッピングルールは後で変更できます。

マッピングルールの作成

マッピングルールは、証明書の共通名 (CN) で識別されるロードバランサーの SSL エンドポイントの属性です。

マッピングルールを作成すると証明書が関連付けられます。

  • Runtime Manager

    マッピングルールは証明書の定義内で定義します。

  • CLI または CloudHub API

    証明書の CN を指定する必要があります。

    証明書名を省略すると、マッピングはデフォルトのエンドポイントに追加されます。

Runtime Manager でのマッピングルールの作成

Runtime Manager を使用して DLB の SSL エンドポイントでマッピングルールを作成する手順は次のとおりです。

  1. Anypoint Platform の ​[Runtime Manager]​ を選択します。

  2. 左側のメニューで ​[Load Balancers (ロードバランサー)]​ を選択します。

  3. ロードバランサー名をクリックして、証明書名をクリックします。

  4. [URL Mapping Rules (URL マッピングルール)]​ セクションで ​[Add New Rule (新規ルールを追加)]​ をクリックします。

    *[Add New Rule (新規ルールを追加)]* アイコンとマッピングルールの作成に必要な項目
    Figure 1. このスクリーンショットは、(​1​) ​[Add New Rule (新規ルールを追加)]​ アイコンと (​2​) マッピングルールの作成に必要な項目を示しています。

  5. 次の項目に入力します。

    • Input Path (入力パス)​ (​inputUri​)

      クライアントが要求する URI (例: /{app}/​)

      入力 URI は、ロードバランサーのホストヘッダーに付加されます。

    • Target App (対象アプリケーション)​ (​appName​)

      要求を処理する CloudHub アプリケーションの名前 (例: {app}-example​)

    • Output Path (出力パス)​ (​appURI​)

      アプリケーションに渡す URI 文字列 (例: /​)

      出力パスではパターンを指定することはできません。

    • Protocol (プロトコル)​ (​upstreamProtocol​)

      アプリケーションがリスンするプロトコル:

      • http​ (ポート 8091)

      • https​ (ポート 8092)

      • ws​ WebSockets (ポート 8091)

      • wss​ SSL/TLS 経由の WebSockets (8092)

      デフォルトでは、ロードバランサーは HTTPS で外部要求をリスンし、HTTP でワーカーと内部的に通信します。VPC で HTTPS をリスンするように Mule アプリケーションを設定してある場合は、マッピングルールリストを作成するときに ​[Protocol (プロトコル)]​ を ​https​ に設定します。

この DLB では、項目の値とクライアントの要求を使用して対象アプリケーションに送信されるパスを生成します。

たとえば、クライアントの要求が ​<domain.com>/hello/world/​ でマッピングルール項目が次のように設定されているとします。

  • Input Path (入力パス)​: /hello/

  • Target App (対象アプリケーション)​: myApp1

  • Output Path (出力パス)​: /test/

この DLB では出力パスの値 (​/test/​) を使用し、クライアントの要求から入力パスに一致するセクション (​/hello/​) を削除して、残り (​/world/​) をクライアントの要求に追加します。 次に、生成されたパス (​/test/world/​) を対象アプリケーション (​myApp1​) に送信します。

入力パスを定義するときは、パターンまたはリテラル文字列を仕様できます。 出力パスの場合は、リテラル文字列のみを使用できます。

CLI を使用したマッピングルールの作成

CLI を使用して DLB でマッピングルールを作成する手順は次のとおりです。

cloudhub load-balancer mappings add [options] <name> <index> <inputUri> <appName> <appUri> [certificateName]

「cloudhub load-balancer mappings add」​を参照してください。

CloudHub API を使用したマッピングルールの作成

CloudHub CLI を使用して DLB でマッピングルールを作成する手順は次のとおりです。

anypoint.mulesoft.com/cloudhub/api/organizations/{orgid}/loadbalancers/{loadbalancerId}

「CloudHub API」​を参照してください。

マッピングルールでのパターンの使用

パターン​は、入力テキストを照合するためのテンプレートを定義する文字列です。 中括弧 (​{ }​) の値は変数として処理されます。

  • 変数の​名前​では、小文字の英文字 (​a-z​) のみを使用できます。

  • 変数の​値​には、​a-z0-1.&?-_​ の文字を含めることができますが、スラッシュ (​/​) を含めることはできません。

DLB では、​[Output Path (出力パス)]​ (​appURI​) ではパターンをサポートしていません。

URL マッピング

Input Path (入力パス)​ としてアプリケーション名を渡し、CloudHub のアプリケーション名に直接マップできます。

ルール番号 Input Path (入力パス) Target App (対象アプリケーション) Output Path (出力パス) Protocol (プロトコル)

1

/{app}/

{app}

/

http

このルールは ​lb-demo.lb.anypointdns.net/{app}​ への要求をマップして ​{app}.cloudhub.io​ にリダイレクトします。 {app}​ のパターンは、インバウンド要求で渡すアプリケーション名と一致します。

ホストマッピング

SSL エンドポイントで ​*.example.com​ のような ワイルドカード証明書​を設定してある場合、​subdomain​ 変数を使用して任意のサブドメインをマップできます。

ルール番号 Input Path (入力パス) Target App (対象アプリケーション) Output Path (出力パス) Protocol (プロトコル)

1

/

{subdomain}

/

https

このルールは、​example.com​ のサブドメインに渡される要求を対応する ​appName​ に自動的にマップします。

  • api.example.com​ を渡すと、​api.cloudhub.io​ にリダイレクトされる。

  • application.example.com​ を渡すと、​application.cloudhub.io​ にマップされる。

subdomain​ 変数では、SSL エンドポイントの サブジェクト代替名​ (SAN) を使用することもできます。

DLB を介して任意のサブドメインのアプリケーション名を渡すことができるワイルドカード証明書を使用する代わりに、許可されるサブドメイン名を指定できます。 これを行うには、証明書の共通名に対して SAN を設定する必要があります。 subdomain​ 変数を使用してドメイン名のサブドメイン部分をアプリケーションにマップできます。

この例には以下が含まれます。

  • 2 つのデプロイ済みアプリケーション:

    • dev-app

    • qa-app

  • 以下の SAN が設定された SSL エンドポイント:

    • dev.example.com

    • qa.example.com

  • マッピングルール:

    ルール番号 Input Path (入力パス) Target App (対象アプリケーション) Output Path (出力パス) Protocol (プロトコル)

    1

    /

    {subdomain}-app

    /

    https

このルールは、ドメイン名のサブドメイン部分をアプリケーション名にマップします。

  • dev.example.com​ は ​dev-app.cloudhub.io​ にリダイレクトされます。

  • qa.example.com​ は ​qa-app.cloudhub.io​ にリダイレクトされます。

リテラル 1:1 マッピングの使用

パターンを使用する代わりに、リテラルアプリケーション名をマップできます。 この場合、ルールはアプリケーションと正確に一致する必要があります。

このルールは、デフォルトのロードバランサー ​lb-demo.lb.anypointdns.net​ を CloudHub のアプリケーション ​myApp.cloudhub.io​ に直接マップします。

ルール番号 Input Path (入力パス) Target App (対象アプリケーション) Output Path (出力パス) Protocol (プロトコル)

1

/

myApp

/

http

このルールは、入力 URI が ​/misc/myhellotest/v1/ping​ の場合は ​dev-misc-myhellotest-v1-myapp​ アプリケーションと一致しますが、​/misc/myhellootest/v1/ping​ の場合は一致しません。

ルール番号 Input Path (入力パス) Target App (対象アプリケーション) Output Path (出力パス) Protocol (プロトコル)

1

/{layera}/{domaina}/v{versiona}/

dev-{layera}-{domaina}-{versiona}-myapp

/api/

http

[Input Path (入力パス)]​ を、定義したパターンではなく静的な文字列に変更することで、リテラル 1:1 マッピングを複数のアプリケーションに対して使用することもできます。

ルール番号 Input Path (入力パス) Target App (対象アプリケーション) Output Path (出力パス) Protocol (プロトコル)

1

/v1/applicationX

application-x

/api/

http

2

/v1/applicationY

application-y

/api/

http

3

/v2/applicationx

application-x-v2

/api/

http

マッピングルールの優先度

各ルールで優先度を定義します。 リスト内では、先にあるルールの方が後のルールより優先されます。

DLB は、さらに一致精度の高いルールがリストの後の方にある場合でも、常に最初に一致したルールを使用します。 ルールを作成する場合は、複数のルールが互いに上書きしてしまわないように、各ルールの順序に注意してください。

次の例では、​/api/v1/secondapp​ という URL を ​default-app​ アプリケーションにマップしています。

Priority (優先度) Input Path (入力パス) Target App (対象アプリケーション) Output Path (出力パス) プロトコル

1

/api/v1/

default-app

/api/v1/

http

2

/api/v1/secondapp/

second-app

/api/v1

http

ルールが ​second-app​ のみと一致するようにするには、ルールの優先度を次のように定義する必要があります。

Priority (優先度) Input Path (入力パス) Target App (対象アプリケーション) Output Path (出力パス) プロトコル

1

/api/v1/secondapp/

second-app

/api/v1

http

2

/api/v1/

default-app

/api/v1/

http

Runtime Manager でのマッピングルールの優先度の変更

Runtime Manager でマッピングルールの優先度を変更するための手順は次のとおりです。

  1. Anypoint Platform の ​[Runtime Manager]​ を選択します。

  2. 左側のメニューで ​[Load Balancers (ロードバランサー)]​ を選択します。

  3. ロードバランサー名をクリックして、証明書名をクリックします。

  4. [URL Mapping Rules (URL マッピングルール)]​ セクションで、ルールにマウスポインターを置いてハンドルを表示します。

    マッピングルールの順序を変更するために使用するハンドル
    Figure 2. 矢印は、マッピングルールの順序を変更するために使用するハンドルを示しています。

  5. ハンドルをクリックしてドラッグすることで、リスト内でルールを上下に移動します。

  6. [Done Editing (編集完了)]​ をクリックします。

CLI を使用したマッピングルールの優先度の変更

CLI でマッピングルールを作成するときにマッピングルールの優先度を指定するには、​index​ 値を使用します。 インデックス ​0​ のルールが最高の優先度となります。割り当てられたインデックスが大きいほど、優先度は低くなります。

「cloudhub load-balancer mappings add」​を参照してください。

CloudHub CLI を使用したマッピングルールの優先度の変更

API を使用してマッピングルールを作成する場合は、優先度を指定することはできません。 新たに作成されたルールは、リストの末尾に付加されます。 後でロードバランサーエンドポイントに ​PATCH​ 要求を送信することで、ルールの順序を変更できます。

anypoint.mulesoft.com/cloudhub/api/organizations/{orgid}/loadbalancers/{loadbalancerId}

ロードバランサー ID を調べるには、エンドポイントに対して GET 要求を実行します。

/organizations/{orgid}/loadbalancers

関連情報