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

ロードバランサ設定は、入力 URL をさまざまな CloudHub アプリケーションへのコールに変換する方法が記述された一連のマッピングルールで定義されます。 マッピングルールは、ロードバランサの SSL エンドポイントの属性です。 マッピングルールを作成する場合、証明書 CN を指定する必要があります。​[certificateName]​ パラメータを省略すると、マッピングがデフォルトエンドポイントに追加されます。

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

プロキシルールを使用して、CloudHub で実行されている Mule アプリケーションのいずれかにドメインまたはサブドメインをマップできます。

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

現在、アプリケーション URI のパターンはサポートされていません。

パターンは、入力テキストを照合するためのテンプレートを定義する文字列です。中括弧 (​{ }​) に挿入されたものはすべて変数として処理されます。 変数名では、小文字の英文字 (a-z) のみを使用できます。変数値には、​a-z0-1.&?-_​ の文字を含めることができますが、スラッシュを含めることはできません。

DNS CNAME レコードを ​example.com​ から lb-name​.lb.anypointdns.net にセットアップしたとします。これにより、app.example.com をさまざまなデプロイ済み CloudHub Mule アプリケーション名にマップできます。

たとえば、2 つのホスト名をバインドしてリダイレクトできます。

‘app.example.com’ ->  application: `app` URI: `/example’

この場合、​https://app.example.com​ への外部要求は ​http://app.cloudhub.io/example​ にリダイレクトされます。

または、入力値を保持するパターンを定義することもできます。

‘example.com/{mypattern}’ -> application: `app-{mypattern}` URI: /data

上の例では、​example.com/bookings​ と ​example.com/sales​ の両方がそれぞれ ​app-bookings/data​ と ​app-sales/data​ に一致します。これは、​mypattern​ にこれらの値が保持されるためです。 ​input=”bookings.example.com”​ の場合、mypattern​=”bookings” を割り当てることでパターンを解決でき、input=​`sales.example.com`​` の場合は mypattern​=”sales” を割り当てることでパターンを解決できます。

設計に応じて、パターンまたはリテラルマッピングを使用して、エンドポイントへの内部リダイレクトを活用できます。

マッピングルールの作成

マッピングルールは、入力 URL を定義する一連の項目と、出力 URL を記述する一連の項目です。

入力 URL は、ユーザが指定できる URI パラメータを使用して記述されます。​URI​ は、入力 URI を記述する文字列またはパターンです。

入力 URL は、メインロードバランサのドメインに従い、同じロードバランサでは、この値は同じになります。

出力 URL は 2 つの項目で指定します。

  • appName

    要求が転送されるアプリケーション名を出力します。

  • appURI

    解決済みのアプリケーションに渡される URI 文字列を指定します。

入力 URL と出力 URL のどちらも、パターンまたはリテラル文字列を使用して定義できます。

マッピングルールは、証明書名で識別されるロードバランサの SSL エンドポイントの属性です。 マッピングルールを作成する場合、証明書 CN を指定する必要があります。​[certificateName]​ パラメータを省略すると、マッピングがデフォルトエンドポイントに追加されます。

SSL エンドポイントで ワイルドカード証明書​が設定されていて、マッピングルールのサブドメイン部分を使用する場合は、定義済みの ​{subdomain}​ 変数を使用できます。

最初に定義されたルールには、それ以降に定義された他のルールよりも高い優先度が与えられます。つまり、最初に一致したルールが適用されます。 ​mappings add​、​mappings describe​、​mappings remove​ コマンドをそれぞれ使用して、ルールの作成、表示、既存ルールの削除を実行できます。

マッピングルールの例

外部ロードバランサドメイン名は、割り当てた一意の名前によって異なります。次のマッピングルールの例では、ロードバランサ名は ​lb-demo​ です。

デフォルトでは、ロードバランサは HTTPS で外部要求をリスンし、HTTP でワーカーと内部的に通信します。HTTPS でリスンするように VPC 内の Mule アプリケーションを設定している場合、​load-balancer mappings add​ コマンドを使用してマッピングリストを作成するときに ​upstreamProtocol​ が ​HTTPS​ に設定されていることを確認してください。

URL マッピング

入力 URI としてアプリケーション名を渡し、CloudHub のアプリケーション名に直接マップできます。

ルール番号 入力 URL 出力 URL

URI

appName

appURI

0

/​{app}​/

​{app}​

/

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

ホストマッピング

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

ルール番号 入力 URL 出力 URL

URI

appName

appURI

0

/

​{subdomain}​

/

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

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

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

SSL エンドポイントの​https://en.wikipedia.org/wiki/Subject_Alternative_Name[サブジェクト代替名]​ (SAN) についても同様です。

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

例について説明します。

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

    • dev-app

    • qa-app

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

    • dev.example.com

    • qa.example.com

  • マッピングルール:

    ルール番号 入力 URL 出力 URL

    URI

    appName

    appURI

    0

    /

    ​{subdomain}​-app

    /

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

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

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

1:1 マッピング

アプリケーションが 1 つのみの場合、リテラルのアプリケーション名をマップできます。

ルール番号 入力 URL 出力 URL

URI

appName

appURI

0

/

myApp

/

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

ルールの優先度のインデックス化

マッピングルールを作成したら、インデックスを割り当てて、ルールの優先順序を定義します。

インデックス ​0​で最初に定義されているルールはがその後に定義されている他のルールよりも優先されます。割り当てられているインデックスが大きいほど、マッピングルールの優先度は低くなります。

各ルールで優先度を定義します。ルールを作成する場合は、複数のルールが互いに上書きしてしまわないように、各ルールの順序に注意してください。

ルールの順序と優先度の設定

Anypoint Platform CLI で ​cloudhub load-balancer mappings add​ コマンドを使用してマッピングルールを作成するときに、インデックス値を指定してその順序を設定できます。

API を使用してルールを作成する場合は優先度を指定できませんが、後でロードバランサエンドポイント ​anypoint.mulesoft.com/cloudhub/api/organizations/{orgid}/loadbalancers/{loadbalancerId}​ に ​PATCH​ 要求を送信して、上記の順序ロジックに基づくニーズに合わせた順序インデックスを使用してルール式を更新できます。

ロードバランサ ID は、ロードバランサの作成時に提供されます。また、エンドポイント ​/organizations/{orgid}}/loadbalancers​ に対して ​GET​ 要求を実行し、ID を取得することもできます。

Was this article helpful?

💙 Thanks for your feedback!