--- schema_version: "1" id: a7ba0a3839807ec06b3d7639eb267ff7c8833b7729f96793f990970afce0213f title: Anypoint Runtime Fabric でのインバウンドトラフィックの有効化 (VM/ベアメタル) collection: mulesoft version: current locale: ja-jp portal_url: https://docs.salesforce.com/mulesoft/current/ja-jp/runtime-fabric/1.13/enable-inbound-traffic.md canonical_url: https://docs.mulesoft.com/jp/runtime-fabric/1.13/enable-inbound-traffic source_site: docs.mulesoft.com content_type: documentation content_hash: e9bb180655f924e47dd277e4f393a088d1cc9c445eb1568a3f0c593fb00b2833 description: MuleSoft Documentation Site release: "1.13" latest: false --- # Anypoint Runtime Fabric でのインバウンドトラフィックの有効化 (VM/ベアメタル) VM/ベアメタルの Runtime Fabric は、Mule アプリケーションや API プロキシへのインバウンドトラフィックを管理するための負荷分散を提供します。ネットワークトラフィックは、アプリケーションの複数のレプリカで分散されます。デフォルトでは、レプリカは異なるワーカー VM にデプロイされます。 複数の環境で Runtime Fabric インスタンスを共有できます。インストール後、各 Runtime Fabric インスタンスの 1 つ以上の環境を設定して、アプリケーションデプロイメントを有効にします。Mule アプリケーションや API ゲートウェイをデプロイするには、1 つ以上の環境を各 Runtime Fabric インスタンスに関連付けます。 本番環境にデプロイされるアプリケーションは、本番以外のアプリケーションとは異なる VM/ベアメタルの Runtime Fabric のインスタンスにデプロイされる必要があります。 デフォルトでは、不要なリソースをコンシュームしないようにインバウンドトラフィックが無効になっています。Mule アプリケーションや API ゲートウェイでインバウンド接続をリスンできるようにするには、インバウンドトラフィックを有効にする必要があります。 ## [](#インバウンドトラフィックを有効にする準備)インバウンドトラフィックを有効にする準備 VM/ベアメタルの Runtime Fabric のインバウンドトラフィックを有効にする前に、次のことに対応済みであることを確認してください。 - VM/ベアメタルの Runtime Fabric で実行されるアプリケーションへのトラフィックを管理するための外部 TCP ロードバランサーの設定など、​[「インフラストラクチャ要件」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/install-prereqs#infrastructure-requirements)​で挙げられている前提となるネットワーク関連タスクを完了します。 - 外部 TCP ロードバランサーが接続できるコントローラーノードまたは専用ノード (インストール時に設定した選択によって異なります) のすべての IP アドレスを集めます。これらの IP アドレスは、VM/ベアメタルの Runtime Fabric のインストールが完了するまでわからない場合もあります。 - 内部ロードバランサーの共有モードと専用モードのどちらを使用するかを決定します。デフォルトでは、インバウンドロードバランサーは VM/ベアメタルの Runtime Fabric で設定された各コントローラーノードで実行されます。 トラフィック負荷が小さい場合は、コントローラーノードをクラスター管理とインバウンドトラフィック TLS 終端の両方に使用できます。 トラフィック負荷が大きい場合は専用トラフィックを使用してください。詳細は、​[「内部ロードバランサー」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-resource-allocation#internal-load-balancer)​を参照してください。 インバウンドトラフィックのレプリカの数をコントローラーノードの数 (共有モードの場合) または専用の内部ロードバランサーノードの数 (専用モードの場合) に合わせて設定します。これらのノードのすべての IP アドレスを外部ロードバランサーまたは DNS 解決に含めます。そうしないと、トラフィックをロードバランサーから Runtime Fabric に転送できません。 - トラフィックをアプリケーションに転送するために使用する 1 つ以上のドメインの情報を集めます。 - TLS 証明書で署名されたドメインを外部ロードバランサーが提供する 1 つ以上の IP アドレスに関連付けるように DNS 設定を定義します。 ## [](#インバウンドトラフィックを有効にする)インバウンドトラフィックを有効にする VM/ベアメタルの Anypoint Runtime Fabric のインバウンドトラフィックを有効にするには、次のタスクを実行します。 1. Anypoint Runtime Manager を使用してインバウンドトラフィックを設定します。 2. HTTPS のトランスポートレイヤーセキュリティ (TLS) コンテキストを設定します。 3. 必要に応じて、セキュリティポリシーを選択します。 4. 必要に応じて、詳細オプションを選択します。 5. 必要に応じて、内部ロードバランサーのログを設定します。 6. インバウンドトラフィックが有効になっていることを確認します。 7. 外部ロードバランサーを設定します。 8. アプリケーションをデプロイします。 ### [](#anypoint-runtime-manager-を使用してインバウンドトラフィックを設定する)Anypoint Runtime Manager を使用してインバウンドトラフィックを設定する インバウンドトラフィックを設定する手順は次のとおりです。 1. \[Runtime Manager\] に移動し、​**\[Runtime Fabric\]**​ を選択します。 2. Runtime Fabric インスタンスの名前を選択して、管理ページを開きます。 3. **\[Associated Environments (関連付けられた環境)\]**​ タブで、Runtime Fabric インスタンスがアプリケーションをデプロイする環境に関連付けられていることを確認します。 4. **\[Inbound Traffic (インバウンドトラフィック)\]**​ を選択し、​**\[Enable inbound traffic (インバウンドトラフィックを有効化)\]**​ を選択します。 5. **\[Resource Allocation (リソース割り当て)\]**​ セクションで、​**\[Shared Mode (共有モード)\]**​ または ​**\[Dedicated Mode (専用モード)\]**​ を選択します。 6. 内部ロードバランサーの各コントローラーノードに割り当てるコアの最小数を指定します。 7. 内部ロードバランサーの各コントローラーノードに割り当てる最小メモリを指定します。 8. **\[Protocol (プロトコル)\]**​ セクションで次のいずれかのプロトコルオプションを選択します。 - **Accept HTTPS requests…​ (HTTPS 要求を受け入れる…​)** 次のオプションのいずれかを選択します。 - **HTTP から HTTPS にリダイレクトする** インバウンドトラフィックが有効になると、VM/ベアメタルの Runtime Fabric に送信される HTTP 要求は、301 応答を受信して、ポート 443 で HTTPS にリダイレクトします。 - **HTTP 要求も受け入れる** VM/ベアメタルの Runtime Fabric に送信された HTTP 要求はポート 80 で受信されます。 - **HTTP 要求を削除する** VM/ベアメタルの Runtime Fabric に送信された HTTP 要求は無視されます。 - **Accept HTTP requests only (HTTP 要求のみを受け入れる)** この場合は証明書を使用しないため、​**\[Add Domain (ドメインを追加)\]**​ をクリックして要求をアプリケーションに転送するためのドメインを手動で入力します。
[Accept HTTP requests only (HTTP 要求のみを受け入れる)]​ は、外部接続用の安全なオプションではありません。このオプションは、外部ロードバランサーがすでに安全な TLS 接続を終端している状態で VM/ベアメタルの Runtime Fabric に HTTP 経由でトラフィックを転送するネットワーク接続で使用してください。
### [](#https-の-tls-コンテキストを設定する)HTTPS の TLS コンテキストを設定する **\[Protocol (プロトコル)\]**​ セクションで ​**\[Accept HTTPS requests…​ (HTTPS 要求を受け入れる…​)\]**​ を選択した場合は、Anypoint Runtime Fabric が受信するすべてのインバウンドトラフィックは TLS で暗号化されます。この場合、インバウンドトラフィックを有効化すると、最大 10 件の証明書を提供できますが、最低 1 件の有効な TLS 証明書が必要です。詳細は、​[「鍵と証明書の CPU 要件」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-resource-allocation#cpu_cert_req)​を参照してください。 TLS をセットアップするときには次のいずれかを使用します。 - 公開証明書、非公開キー、CA パス 公開証明書と非公開キーは Privacy-Enhanced Mail (PEM) 形式にして、TLS のデフォルト値を使用する必要があります。PEM ファイルは ​`.cer`​、​`.crt`​、または ​`.pem`​ 拡張子の Base64 でエンコードされた ASCII ファイルです。CA パスには、証明書からルートへのパスを提供する中間証明書とルート証明書が含まれます。このファイルは、証明書に署名した CA からダウンロードできます。この項目にエントリを入力すると、すべての接続における VM/ベアメタルの Runtime Fabric のロードバランサーは証明書とクライアントへのパスの両方を送信します。多くのクライアントでは、証明書を検証できるように、サーバーが CA パスを送信する必要があります。 このオプションを使用する場合、TLS バージョン、暗号、その他の TLS 設定オプションのデフォルト値を変更することはできません。これは、VM/ベアメタルの Runtime Fabric 用に TLS コンテキストが存在しない場合のデフォルトのオプションです。 - Java Keystore (JKS) ファイル JKS ファイルは認証用のリポジトリまたは公開キー証明書であり、秘密鍵は保存されません。このオプションを使用する場合、TLS バージョン、暗号、その他の TLS 設定オプションのデフォルト値を変更することはできません。 - シークレットマネージャーからインポートされた TLS コンテキスト このオプションは高度なユーザーのみが使用してください。シークレットマネージャーから TLS コンテキストをインポートし、TLS コンテキストの作成、相互認証、暗号化の選択、TLS バージョンの選択などの高度な設定をサポートしています。 所有している Runtime Fabric インスタンスの TLS 設定とポリシーのみを変更できます。継承された Runtime Fabric インスタンスの場合、TLS 設定は参照のみです。 TLS の終端は計算コストが高くなるため、十分な量の CPU を割り当ててスループットを増やし、レイテンシーを減らしてください。TLS 非公開キーの種類とサイズが与える影響を含め、CPU 割り当ておよびスループットについての詳細は、​[「内部ロードバランサーのメモリ割り当て」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-resource-allocation#internal-load-balancer-memory-allocation)​を参照してください。 1. Runtime Manager で ​**\[Add Certificate (証明書を追加)\]**​ を選択します。 2. HTTPS の TLS コンテキストを設定するには、適切なオプションを選択します。 - オプション 1: **\[Upload PEM (JKS をアップロード)\]** 1. **\[Public certificate (公開証明書)\]**​ には、インバウンドトラフィックサーバーの公開証明書を指定します。​**\[Domains (ドメイン)\]**​ 項目には、​**\[Application url (アプリケーション URL)\]**​ に使用できるドメインがリストされます。最初のドメインがデフォルトです。その他の値は ​**\[Applications (アプリケーション)\]→\[Ingress (イングレス)\]**​ ページで選択できます。 証明書はパスフレーズと、Runtime Fabric にデプロイされている各アプリケーションのドメインを指定する共通名 (CN) を使用して設定されている必要があります。 - 共通名にワイルドカードが含まれている場合、デプロイされている各アプリケーションのエンドポイントの形式は ​`{app-name}.{common-name}`​ のようになります。 - 共通名にワイルドカードが含まれていない場合、エンドポイントの形式は ​`{common-name}/{app-name}`​ のようになります。 2. **\[Private key (非公開キー)\]**​ の値を指定します。これは、証明書の非公開キーを含む PEM 形式のファイルです。 鍵が暗号化されていない場合は (推奨されません)、​**\[Key password (キーパスワード)\]**​ 項目を空白のままにします。 3. **\[CA path certificate File (Optional) (CA パス証明書ファイル (省略可能))\]**​ の値を指定します。 4. **\[Add certificate (証明書を追加)\]**​ を選択します。​**\[Key password (キーパスワード)\]**​ 項目はセキュリティ上の理由から無効になっています。 公開証明書、非公開キー、キーパスコードはシークレットマネージャーに保存されます。 - オプション 2: **\[Upload JKS (JKS をアップロード)\]** 1. **\[Keystore File (キーストアファイル)\]**​ の値を指定します。少なくとも、キーストアファイルには公開証明書と非公開キーが含まれています。 2. **\[Keystore Password (キーストアパスワード)\]**​ の値を指定します。 3. **\[Select alias from keystore (キーストアから別名を選択)\]**​ ウィンドウで、​**\[Alias (別名)\]**​ に値を指定します。別名は、特定のキーペアを選択するために使用されます。 4. **\[Add certificate (証明書を追加)\]**​ を選択します。​**\[Keystore Passcode (キーストアパスコード)\]**​ 項目と ​**\[Key Passcode (キーパスコード)\]**​ 項目はセキュリティ上の理由から無効になっています。 JKS ファイルの情報は組織のグローバルシークレットグループに保存されます。 - オプション 3: **\[Import from Secrets Manager (シークレットマネージャーからインポート)\]**​ [「シークレットマネージャーからの TLS コンテキストのインポート (高度なユーザー向け)」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/configure-adv-tls-context)​の手順を参照してください。
シークレットマネージャーで TLS コンテキストを変更しても、インバウンドトラフィック設定には自動的に適用されません。変更後に ​[Inbound Traffic (インバウンドトラフィック)]​ タブに移動して、​[Save and Deploy (保存してデプロイ)]​ をクリックしてください。
## [](#省略可能-セキュリティポリシーを選択する)(省略可能) セキュリティポリシーを選択する セキュリティポリシーを追加する必要がある場合は、まずセキュリティポリシーを定義する必要があります。定義すると、​**\[HTTP Limits (HTTP 制限)\]**​、​**\[Web Application Firewall (WAF) (Web アプリケーションファイアウォール (WAF))\]**​、​**\[IP Whitelist (IP ホワイトリスト)\]**​、または ​**\[Denial of Service (DoS) (サービス拒否 (DoS))\]**​ ドロップダウンリストのオプションとして表示されます。 複数の FQDN を使用して VM/ベアメタルの Runtime Fabric インスタンスにアクセスするには、サブジェクト代替名 (SAN) 証明書プロパティに FQDN エントリを追加します。証明書の SAN プロパティに複数の FQDN エントリが登録されている場合、アプリケーションをデプロイすると、利用できる URL のリストが ​**\[Applications (アプリケーション)\] → \[Ingress (イングレス)\]**​ セクションに表示されます。URL は優先度の順にリストされているわけではなく、最初の URL がデフォルトというわけでもありません。
Anypoint Security でセキュリティポリシーを定義するには、Anypoint Platform アカウントの「Anypoint Security - Edge」エンタイトルメントが必要です。​[Management Center]​ で ​[Security (セキュリティ)]​ がリストされていない場合は、アカウントで Anypoint Security を有効にするようにカスタマーサクセスマネージャーに依頼してください。詳細は、​「Edge の Anypoint Security ポリシー」​を参照してください。
## [](#省略可能-詳細オプションを選択する)(省略可能) 詳細オプションを選択する 次の表では、環境で設定する場合がある追加の設定オプションについて説明します。 この表では、​**「Source IP (送信元 IP)」**​は要求を行っているクライアントを指します。
値 説明

Max Connections (最大接続数)

最大許容同時接続数。

デフォルト値​: 512 接続

Max Requests per Connection (接続あたりの最大要求数)

接続あたりの最大許容要求数。
この値の範囲は 1 ～ 4194304 です。
この値により、接続でどれぐらいの再利用が許可されるのかが決まるため、この値を低くする場合、TLS で暗号化された接続を終了および再確立するのに必要な CPU の量を考慮してください。

最大許容値​: 接続あたり 1000 要求

デフォルト値​: 1000。この値で、セキュリティとパフォーマンスのバランスを取ります。詳細は、​「Anypoint Runtime Fabric でのリソース割り当てとパフォーマンス」​を参照してください。

Connection Idle Time-out (接続アイドルタイムアウト)

アイドル接続を許可する最大時間。
この値は、アイドル接続を終了してリソースを解放するのに役立ちます。
この値は、常に ​[Read Request Time-out (読み取り要求タイムアウト)]​ よりも高くする必要があります。

デフォルト値​: 15 秒

Read Request Time-out (読み取り要求タイムアウト)

要求の読み取りに費やすことができる最大時間。この時間を超えると終了します。
この値により、大きなペイロードの要求や低速なクライアントを終了して、リソースを使用できる状態を維持できます。これは、応答の送信後に接続を終了しないクライアントや低速な要求によって接続プールが枯渇することを回避するのに役立ちます。

たとえば、Mule アプリケーションの応答時間がこの値よりも長くなると、接続が自動的に終了します。
この値は、常に上記で設定される ​[Connection Idle Time-out (接続アイドルタイムアウト)]​ の値よりも低くする必要があります。

デフォルト値​: 10 秒

Read Response Time-out (読み取り応答タイムアウト)

応答の開始に費やすことができる最大時間。この時間を超えると接続が終了します。
この値により、大きなペイロードの要求を終了して、リソースを使用できる状態を維持できます。

デフォルト値​: 300 秒

Write Response Time-out (書き込み応答タイムアウト)

リクエストヘッダーの読み取りの終了から応答の書き込みの終了までに費やすことができる最大時間。この時間を超えると要求が終了します。

デフォルト値​: 10 秒

Max Pipeline Depth (最大パイプライン深度)

同じクライアントからの最大許容要求数。
この値は、クライアントが送信できる同時要求数を定義します。
クライアントがこの数値を超えると、キューの要求が応答を受信するまで超過要求が読み取られなくなります。

デフォルト値​: クライアントあたり 10 要求

[Source IP header name (送信元 IP ヘッダー名)]​ と ​[enable proxy protocol (プロキシプロトコルを有効化)]

適用されるシナリオに基づいて次の値を設定します。

  1. VM/ベアメタルの Runtime Fabric がロードバランサーの背後にデプロイされていない。
    次の値を設定する必要はありません。

    Source IP header name (送信元 IP ヘッダー名)​: 空白
    Enable proxy protocol (プロキシプロトコルを有効化)​: オフ

  2. VM/ベアメタルの Runtime Fabric がプロキシプロトコルが設定された AWS ロードバランサーの背後にデプロイされている。
    ​[enable proxy protocol (プロキシプロトコルを有効化)]​ オプションをオンにする必要があります。

    Source IP header name (送信元 IP ヘッダー名)​: 空白
    Enable proxy protocol (プロキシプロトコルを有効化)​: オン

  3. VM/ベアメタルの Runtime Fabric が AWS 以外のロードバランサーの背後にある。
    VM/ベアメタルの Runtime Fabric が別の種別のロードバランサー (F5 や NGINX など) の背後にデプロイされている場合、[HTTP Header (HTTP ヘッダー)] 項目で送信元 IP アドレスを指定できます。この場合、送信元 IP ヘッダーが含まれる HTTP ヘッダー名を入力します。

    このヘッダー項目が含まれていない HTTP メッセージは拒否されます。送信元 IP アドレスに使用される 2 つの共通の HTTP ヘッダー名は次のとおりです。

    • Forwarded: RFC7239 準拠の IP ヘッダー。

    • X-Forwarded-For: ロードバランサーの 1 つ以上の IP (「192.16.23.34、172.16.21.36」など) が含まれる 2014 年以前の非標準ヘッダー

      Source IP header name (送信元 IP ヘッダー名)​: 空白以外
      Enable proxy protocol (プロキシプロトコルを有効化)​: オフ

デフォルト値​: 空白とオフ。
WebSockets を使用している場合は、次の手順を実行します。 - HTTP 接続を WebSockets にアップグレードするための正しいリクエストヘッダーを提供します。 - [WebSockets リスナーを使用して Mule Runtime Engine を設定します](https://docs.mulesoft.com/mule-runtime/latest/mule-server-notifications)​。 - `Connection Idle Time-out`​ の値を 900 秒 (15 分) に増加して、WebSockets Mule アプリケーションのデフォルト値との一貫性を確保します。 ## [](#省略可能-内部ロードバランサーログを設定する)(省略可能) 内部ロードバランサーログを設定する 内部ロードバランサーのログレベルを定義できます。Runtime Fabric では、次のログレベル (詳細度の昇順で記載) がサポートされています。 - FATAL - ERROR - WARNING - INFO - VERBOSE - DEBUG - TRACE ログレベルが詳細になるほど (WARNING、INFO、VERBOSE、DEBUG、TRACE など)、各要求でコンシュームする CPU リソースが増えます。ログレベルを調整したり、内部ロードバランサーのリソースを割り当てたりする場合、この点を考慮してください。 デフォルトでは、エンドポイントの背後にあるすべての IP アドレスのアクティビティが記録されます。より詳細なログレベルを使用する場合、CPU 消費量を減らすには、IP 検索条件を追加して特定の IP アドレスのみを記録します。また、この機能を使用して、特定の IP アドレスまたは限られた数の IP アドレスの接続をデバッグすると、ログの数量が減少します。 1. **\[Inbound Traffic (インバウンドトラフィック)\]**​ タブから、​**\[Logs (ログ)\]**​ を選択します。 2. **\[Add Filter (検索条件を追加)\]**​ を選択します。 3. **\[IP\]**​ 項目で、CIDR 表記を使用して 1 つの IP アドレスまたはアドレスのサブセットを入力します。 4. この IP 検索条件に適用するログレベルを選択します。 5. **\[OK\]**​ を選択します。 6. **\[Save and Deploy (保存してデプロイ)\]**​ を選択して内部ロードバランサーをデプロイします。 デプロイメントが完了するまでには、最大 1 分かかる場合があります。 検証エラーが発生すると、エラーメッセージが返されます。検証に成功すると、ページの右下にメッセージが緑色のテキストで表示され、デプロイメント要求が受け入れられたことを示します。デプロイメントの状況は、ページの一番上で確認できます。 ## [](#インバウンドトラフィックが有効になっていることを確認する)インバウンドトラフィックが有効になっていることを確認する デプロイされたアプリケーションのインバウンドトラフィックをテストするため、ドメインに設定されたホストヘッダーと共にコントローラーの IP アドレスを使用して要求を送信できます。ホストヘッダーは、アプリケーション URL の構造によって異なります。 1. アプリケーションを公開するエンドポイントを特定します。Runtime Manager の ​**\[Manage application (アプリケーションを管理)\]**​ ページの ​**\[Application url (アプリケーション URL)\]**​ 項目にこの情報が含まれます。 2. 次の cURL コマンドを実行して検証します。 ```none curl -Lvk -XGET {application-path-from-runtime-manager} --resolve {hostname}:443:{ip-address-of-controller} ``` 次の例では、​`{application-path-from-runtime-manager}`​ は ​`[https://newapp.example-rtf.dev](https://newapp.example-rtf.dev)`​ に設定され、​`192.168.64.14`​ はクラスターのコントローラーマシンの IP アドレスです。 ```none curl -Lvk https://newapp.example-rtf.dev/ --resolve newapp.example-rtf.dev:443:192.168.64.14 ``` ## [](#外部ロードバランサーを設定する)外部ロードバランサーを設定する インバウンドトラフィックを有効にしたら、クライアントがデプロイされたアプリケーションに要求を送信できるように、有効になっている各アプリケーションに受信トラフィックをルーティングするよう VM/ベアメタルの Runtime Fabric を設定する必要があります。 HTTPS 要求の場合は、VM/ベアメタルの Runtime Fabric の各コントローラー VM で HTTPS トラフィックを負荷分散するように外部ロードバランサーを設定する必要があります。コントローラー VM は、Anypoint Runtime Fabric を強化するコンポーネントを実行する専用の仮想マシンです。各コントローラー VM は、内部ロードバランサーのレプリカを実行し、ポート 443 でリスンするように設定されています。 インストール時に指定した IP の VM/ベアメタルの Runtime Fabric コントローラーノードまたは専用ノードにトラフィックを転送するように、外部 TCP ロードバランサーをプロビジョニングします。 ### [](#外部ロードバランサーの要件)外部ロードバランサーの要件 複数のコントローラー VM を実行する場合、各コントローラー VM に直面する VM/ベアメタルの Runtime Fabric 外に外部ロードバランサーが必要になります。 外部ロードバランサーは TCP 負荷分散をサポートしている必要があり、各コントローラー VM の IP アドレスが含まれるサーバープールを使用して設定されている必要があります。また、外部ロードバランサーには、ポート 443 をリスンする状態チェックも設定されている必要があります。 この外部ロードバランサーの設定では、次のことを実現できます。 - 高可用性 - 障害からの保護 - 内部ロードバランサーのレプリカが再起動するか、削除されて別のコントローラー VM で再スケジュールされた場合の自動フェールオーバー 外部ロードバランサーを設定する手順は、次のとおりです。 1. 外部ロードバランサーを追加するときは、​**「詳細オプション」**​で説明している情報を確認してください。 2. TLS 証明書から取得される共通名を使用する前に DNS を設定します。DNS は、Runtime Fabric にデプロイされているアプリケーションや API ゲートウェイに要求を送信するために必要になります。共通名を外部ロードバランサーまたはコントローラー VM の IP アドレスにマップするために「A レコード」を DNS プロバイダーに追加します。 ## [](#アプリケーションをデプロイする)アプリケーションをデプロイする アプリケーションをデプロイする準備ができたら、以下の手順を実行します。 1. [「Runtime Fabric に Mule アプリケーションをデプロイする」](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-to-runtime-fabric)​の手順に従ってください。 2. アプリケーションの URL を確認します。 **\[Ingress (イングレス)\]**​ タブでは、アプリケーション要求の設定を更新できます。インバウンドトラフィックを有効にすると、デフォルトの動作は新しいアプリケーションのデプロイメントを許可するように変更されます。インバウンドトラフィックを有効にする前に Runtime Fabric にデプロイされたアプリケーションがある場合、この設定が有効になるまでそれらはインバウンド要求を受信しません。 アプリケーションの URL には、アプリケーションのルーティングパスが含まれています。アプリケーションのドメインをデフォルトドメイン以外に設定する場合は、​**\[Domain (ドメイン)\]**​ ドロップダウンからドメインを選択します。 ## [](#tls-証明書を表示する)TLS 証明書を表示する 既存のデプロイメントの TLS 証明書を表示するには、次の手順を実行します。 1. Runtime Fabric インスタンスの ​**\[Inbound Traffic (インバウンドトラフィック)\]**​ タブを選択します。 2. **\[Domains (ドメイン)\]**​ セクションまでスクロールします。 3. **\[…\]**​ を選択します。 4. **\[View details (詳細を詳細)\]**​ を選択します。 ## [](#tls-証明書を更新または削除する)TLS 証明書を更新または削除する TLS 証明書の情報を更新または削除するには、次の手順を実行します。 1. Runtime Manager で、​**\[Inbound Traffic (インバウンドトラフィック)\]**​ タブを選択します。 2. **\[Domains (ドメイン)\]**​ セクションまでスクロールします。 3. **\[…\]**​ を選択します。 4. **\[Delete (削除)\]**​ を選択します。 5. 更新された証明書の情報を追加するには、​**\[Add certificate (証明書を追加)\]**​ を選択して、ステップ 1 の手順に従って新しい証明書を設定します。 ## [](#共有モードと専用モードの切り替え)共有モードと専用モードの切り替え 共有モードと専用モードを切り替える必要がある場合、次の点を確認します。 - 変更の前に、共有 IP アドレスまたは専用 IP アドレスがロードバランサーまたは DNS 解決に含まれない場合、すべてのインバウンドトラフィックが失われます。 - **共有モードから専用モード**​に変更する場合、コントローラーノードの IP アドレスの代わりに専用の内部ロードバランサーノードの IP アドレスを外部ロードバランサーに含める必要があります。インバウンド要求を転送するまではコントローラーノードと専用の内部ロードバランサーノードの両方を一時的に含めます。 - **専用モードから共有モード**​に変更する場合、デプロイメントに合わせて ​**\[CPU Cores (CPU コア)\]**​ および ​**\[Memory (メモリ)\]**​ 項目を適切に設定します。使用可能なリソースの量は、すべてのノードリソースをコンシュームできる専用モードと共有モードでは大幅に異なる可能性があります。 ## [](#アップグレードの変更点)アップグレードの変更点 Runtime Fabric バージョン 1.5.0 以降の場合、内部ロードバランサーは Runtime Fabric コンポーネントのアップグレードプロセス中にアップグレードされます。 ## [](#テストのために-tls-証明書を生成する)テストのために TLS 証明書を生成する テスト目的で、次の手順を使用して証明書と鍵のペアを生成できます。 1. マシンで次のコマンドを実行して証明書と鍵のペアを生成します。 openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 2. 鍵のパスフレーズを入力します。 3. 必要な情報を入力します。共通名を求められた場合、Runtime Fabric で使用するドメインを入力します。 共通名にワイルドカード (​`*.example.com`​ など) を使用する場合、アプリケーション URL では ​`{app-name}.example.com`​ の形式が使用されます。使用しない場合、アプリケーション URL では ​`example.com/{app-name}`​ の形式が使用されます。 ## [](#tls-証明書の期限切れ)TLS 証明書の期限切れ 証明書 (自己署名と CA 署名の両方) には必ず有効期限があります。デフォルトでは、証明書は作成されてから 1 年後に有効期限が切れます。 30 日以内に期限が切れる証明書については次の警告が表示され、証明書の期限が切れる前に新しい証明書と鍵のペアをアップロードするよう促されます。 - **\[Runtime Fabrics\]**​ ページでは、TLS 証明書が 30 日以内に期限切れになる場合、​`TLS Expiring`​ が ​**\[Inbound traffic (インバウンドトラフィック)\]**​ 列に表示されます。 - **\[Runtime Fabrics\]**​ ページでは、TLS 証明書が期限切れになると、警告がその Runtime Fabric インスタンスの ​**\[Inbound traffic (インバウンドトラフィック)\]**​ 列に表示されます。 - **\[Inbound Traffic (インバウンドトラフィック)\]**​ タブでは、TLS 証明書が 30 に以内に期限切れになる場合、警告が表示されます。TLS 証明書が期限切れになると、有効期限情報で ​**\[Certificate File (証明書ファイル)\]**​ 項目に赤い警告が含まれます。 ## [](#関連情報)関連情報 - [Anypoint Runtime Fabric でのリソース割り当ての決定](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-resource-allocation) - [Anypoint Runtime Fabric への Mule アプリケーションのデプロイ](https://docs.mulesoft.com/jp/runtime-fabric/1.13/deploy-to-runtime-fabric)