MuleアプリケーションをDLBを接続する際のはまりどころ

はじめに

　今回は、Muleアプリケーション開発者が専用ロードバランサーからMuleアプリケーションに接続する際に、ちょっとしたはまりどころの紹介です。
　みんな原因を説明すると「そんな問題あるのかよー」と言ってしまうはまりどころですが、知っていると問題なく回避できます。

はまりどころ

　CloudHubにはMuleアプリケーションをCloudHubロードバランサーに接続するために8081ポートに変更してデプロイする機能があります。デプロイ時に${http.port}は8081に書き換えられます。

公式ヘルプ：CloudHubネットワークガイド

　しかし、専用ロードバランサー（DLB）では、Muleプリケーションのポートが違います。公式ヘルプでは下記のように紹介されています。
　”CloudHub 専用ロードバランサでは、ポート 8091 でリスンする Mule アプリケーションへの HTTP 要求とポート 8092 でリスンする Mule アプリケーションへの HTTPS 要求を転送する。”（公式ヘルプ引用）

公式ヘルプ：専用ロードバランサアーキテクチャ

　ここがはまりどころです！！。
　HTTPリスナーコンポーネントを、デフォルト又は、変数${http.port}を指定してCloudHubにデプロイすると、ポート8081に上書きされてデプロイされます。
　Muleアプリケーションん開発者は、上書きすることを知らないで専用ロードバランサーから接続しようとすると、「502 Bad Gateway」エラーが発生し、8091でハードコーディングする方法やプロパティファイルに設定する方法、Runtime Managerに設定する方法など色々試しても、上書きされるため、かなりの労力を消費します。

　解決方法は、Backend With Proxyで利用されている${proxy.port}変数に変更することで、Cloudhubにデプロイした際にCloudHubの上書きの除外されます。

    <http:listener-config name="http-listener-config">
        <http:listener-connection host="0.0.0.0" port="${proxy.port}" protocol="HTTP"/>
    </http:listener-config>

まとめ

専用ロードバランサーからMuleアプリケーションに接続する際に一番わかりずらいのは、DLBからMuleアプリケーション間の通信だと考えています。
　マッピングルールが正しい場合、次に確認すべきはポイントはポートです。
　「設定しているのに何で接続できないの！！」と思ってしまうところなので、変数名が正しいか確認してみてください、では！