--- schema_version: "1" id: 58a95a5219003df6efbbfb5648f1fff7a7f7d37612756cc81d0f53c2fb7c6b84 title: 非公開スペースにデプロイされたアプリケーションのエンドポイントとパスの設定 collection: mulesoft version: current locale: ja-jp portal_url: https://docs.salesforce.com/mulesoft/current/ja-jp/cloudhub-2/ch2-config-endpoints-paths.md canonical_url: https://docs.mulesoft.com/jp/cloudhub-2/ch2-config-endpoints-paths source_site: docs.mulesoft.com content_type: documentation content_hash: 6591fd7ce3016fabd7eb1dfbfaf1d6023cc963b6ff1770ce68dd4ee38ad1af2b description: MuleSoft Documentation Site latest: true --- # 非公開スペースにデプロイされたアプリケーションのエンドポイントとパスの設定
CloudHub 2.0 では、共有スペースではなく非公開スペースにデプロイされたアプリケーションでのみ、エンドポイントのカスタマイズがサポートされています。
非公開スペースは、クライアントからの要求を非公開スペースにデプロイされたアプリケーションに転送します。 アプリケーションを非公開スペースにデプロイすると、2 種類の​_エンドポイント_​が作成されます。 - **エンドポイント**​: 公開スペースにデプロイされたアプリケーションに到達するために使用される URL。このコンテキストでは、外部からエンドポイントにアクセスできるため、ネットワーク外のクライアントがアプリケーションに到達できます。このエンドポイントを削除すれば、外部トラフィックがアプリケーションに到達することを回避できます。 - **内部エンドポイント**​: 公開スペースにデプロイされたアプリケーションに到達するために使用される URL。ただし、非公開ネットワーク内、VPN、またはトランジットゲートウェイ (TGW) でのみアクセスできます。このエンドポイント種別は変更または削除できません。 エンドポイント URL の例としては、​`https://my-app.example.com/`​ のようになります。エンドポイントでは、ネットワーク外のクライアントがアプリケーションに到達できます。内部エンドポイントには、非公開ネットワーク内、VPN、またはトランジットゲートウェイ (TGW) でのみアクセスできます。ネットワーク内でのみアプリケーションにアクセスできるようにするには、内部エンドポイントを使用します。 次の設定により、クライアントからの要求がアプリケーションに到達する方法をカスタマイズできます。 - 複数のカスタムエンドポイント システム管理者は、非公開スペース設定で TLS コンテキストを設定することにより、エンドポイントに使用できるドメインを指定します。 詳細は、[非公開スペースのドメインおよび証明書 (TLS コンテキスト) の設定](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-domains)を参照してください。 - アプリケーションとエンドポイント URL で異なるパス _パス_​は、アプリケーションの HTTP リスナーに必要なベースパス (​`my-app.example.com/v1/api`​ など) です。 詳細は、​[「HTTP リスナーリファレンス - Mule 4」](https://docs.mulesoft.com/http-connector/latest/http-listener-ref)​を参照してください。 エンドポイントを削除して、非公開ネットワークの外部にあるクライアントがアプリケーションに要求を送信できないようにすることもできます。 ## [](#before-you-begin)始める前に システム管理者は、アプリケーションのエンドポイントとパスを設定する前に、非公開スペースの TLS コンテキストをセットアップする必要があります。 詳細は、[非公開スペースのドメインおよび証明書 (TLS コンテキスト) の設定](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-domains)を参照してください。 ## [](#configure-multiple-endpoints)複数のエンドポイントを設定する 複数のエンドポイント (​`my-app.example.com`​ と ​`my-old-app.oldname.com`​ など) を介してアプリケーションに到達可能にすることができます。
各エンドポイント名が一意になるように、サブドメインで ​app-name​ プレースホルダーを使用するか、ドメインにワイルドカードが含まれていない場合はパスを使用します。
複数のエンドポイントを設定する手順は、次のとおりです。 1. アプリケーションを非公開スペースにデプロイする場合、​**\[Ingress (イングレス)\]**​ タブをクリックします。 [非公開スペースへのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/cloudhub-2/ch2-deploy-private-space)を参照してください。 アプリケーションがすでにデプロイ済みの場合: 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Settings (設定)\]**​ をクリックします。 4. **\[Ingress (イングレス)\]**​ タブをクリックします。 2. 最初のエンドポイントを設定します。 1. **\[Domain (ドメイン)\]**​ ドロップダウンリストから、最初のドメイン (​`*.example.com`​ など) を選択します。 ドメインにワイルドカードが含まれる場合、​**\[Subdomain (サブドメイン)\]**​ 項目を使用できます。 2. サブドメインを入力するか、​**\[Subdomain (サブドメイン)\]**​ 項目に ​`my-app`​ プレースホルダーを入力して、​**\[Application Name (アプリケーション名)\]**​ 項目で指定したアプリケーションの名前をサブドメインとして使用します。 詳細は、​[「プレースホルダー」](#placeholder-table)​を参照してください。 3. アプリケーションの HTTP リスナーがリスンするパス (​`v1/api`​ など) を入力します。 3. 追加のエンドポイントを設定する場合は、​**\[Add Endpoint (エンドポイントを追加)\]**​ をクリックして、ステップ 2.1 ～ 2.3 を繰り返します。 4. デプロイメントの状況に応じて、次のいずれかを選択します。 - アプリケーションをデプロイする準備ができている場合、​**\[Deploy (デプロイ)\]**​ をクリックします。 - このアプリケーションがデプロイされている場合、​**\[Apply Changes (変更を適用)\]**​ をクリックします。 5. 設定された各エンドポイントでアプリケーションに到達できることを確認します。 ### [](#placeholder-table)プレースホルダー サブドメインとパスでは、次の小文字プレースホルダー (省略可能) がサポートされます。
プレースホルダー 解決対象

app-name

アプリケーションをデプロイするときに ​[Application Name (アプリケーション名)]​ 項目で指定したアプリケーションの名前

business-group-id

アプリケーションに関連付けられビジネスグループ ID

environment-id

アプリケーションをデプロイする環境
## [](#configure-different-paths)アプリケーションと URL エンドポイントに異なるパスを設定する アプリケーションと URL エンドポイントに異なるパスを設定できます。 たとえば、アプリケーションが ​`my-app.example.com/v1/api`​ でリスンしているときに、​`my-app.example.com/api`​ を使用してインターネットからアプリケーションにアクセスすることができます。 パス URL を書き換えると、新しいパスがすべてのエンドポイントに適用されます。 異なるパスを設定する手順は、次のとおりです。 1. [非公開スペースにアプリケーションをデプロイします](https://docs.mulesoft.com/jp/cloudhub-2/ch2-deploy-private-space)​。 2. **\[Ingress (イングレス)\]**​ タブをクリックします。 3. **\[Path (パス)\]**​ 項目で、アプリケーションにアクセスできるようにするパス (​`/api`​ など) を入力します。 4. **\[Path Rewrite (パス書き換え)\]**​ 項目で、アプリケーションの HTTP リスナーに必要なベースパス (​`/v1/api`​ など) を入力します。 この項目は、カスタム TLS コンテキストでデプロイされたアプリケーションでのみ使用できます。 5. アプリケーションの新しい設定を作成するには、​**\[Apply Changes (変更を適用)\]**​ をクリックします。 ## [](#remove-external-endpoint)エンドポイントを削除する エンドポイントを変更する手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Settings (設定)\]**​ をクリックします。 4. **\[Ingress (イングレス)\]**​ タブをクリックします。 5. エンドポイントリンクの行で、​**\[X\]**​ (​**\[Delete (削除)\]**​) をクリックします。 ## [](#view-internal-endpoint)アプリケーションの内部エンドポイントを表示する 内部エンドポイントには、同じ非公開スペース内から、または非公開スペースの VPN やトランジットゲートウェイ接続を介してアクセスできます。内部エンドポイントのパスまたはドメインを変更することはできません。 内部エンドポイントの URL を表示またはコピーする手順は、次のとおりです。 1. Anypoint Platform から、​**\[Runtime Manager\]**​ > ​**\[Applications (アプリケーション)\]**​ を選択します。 2. アプリケーション名をクリックします。 3. ナビゲーションメニューで ​**\[Settings (設定)\]**​ をクリックします。 4. **\[Ingress (イングレス)\]**​ タブをクリックします。 5. **\[internal endpoint (内部エンドポイント)\]**​ にマウスポインターを置きます。 ## [](#非公開スペース内でアプリケーション間要求を送信する)非公開スペース内でアプリケーション間要求を送信する 非公開スペースでは、すべてのアプリケーションレプリカが非公開スペース内のエンドポイントを公開しています。インバウンドトラフィックを有効にすると、このエンドポイントは外部に公開されます。 非公開スペースの内部ドメイン内のすべてのアプリケーションに DNS レコードがあります。たとえば、​`2abc2ce6-cce6-463b-afaa-a1979e3xxxxx`​ 環境のアプリケーション ​`helloch2`​ の DNS レコードは次のとおりです。 ```none helloch2.2abc2ce6-cce6-463b-afaa-a1979e3xxxxx.svc.cluster.local ``` アプリケーションレプリカは親ドメインを検索する前にまず同じドメイン内の DNS レコードを検索するため、同じ非公開スペース内の別のアプリケーションに要求を送信するには、アプリケーション名のみが必要です。両方のアプリケーションが同じ名前空間にある場合は、アプリケーション名のみが必要です。 ```none http://helloch2:8081/hello ``` 必要に応じて ​`http`​ を ​`https`​ に置き換えます。
svc.cluster.local​ エンドポイントを使用して、異なる名前空間のアプリケーション間でトラフィックを送信することはできません。
### [](#アプリケーション間の通信)アプリケーション間の通信 アプリケーション間の通信方法を次に示します。 - デフォルトの公開 DNS 名: `app.sxjsip.aus-s1.cloudhub.io` - デフォルトの内部 DNS 名 (非公開スペースのみ): `app.internal-sxjsip.aus-s1.cloudhub.io` - カスタムドメイン名 (設定されている場合): `acme.example.com` - クラスターローカル DNS: `app`​ または ​`app.envid.svc.cluster.local` 内部 DNS 名を使用する場合、トラフィックは非公開スペースネットワークに留まります。アプリケーションを非公開スペースにデプロイする場合、外部に公開されるエンドポイントを削除または省略できます。その場合、内部トラフィック用にアプリケーションの内部エンドポイントを使用できます。 クラスターローカルエンドポイントを使用する場合、トラフィックはクラスター内に留まります。ただし、クラスターローカルエンドポイントは高可用性ではありません。一部のクラスター操作 (障害回復など) により、エンドポイントに到達できなくなる可能性があります。 障害回復中にアプリケーションが新しいクラスターに移行すると、クラスターローカル DNS エンドポイントが失敗する可能性があります。これは、ローカル DNS エンドポイントを介してルーティングされるトラフィックが、トラフィックを新しいクラスターに転送するために必要なイングレスロードバランサーをトラバースしないために発生します。ただし、ほかの使用可能なエンドポイントを使用すると、トラフィックがイングレスロードバランサーを通過するようになります。イングレスロードバランサーは、障害回復イベントが発生しているかどうかを検出します。また、特定のエンドポイントにリンクされているアプリケーションが新しいクラスターに移動したかどうかも把握しています。これにより、必要に応じてトラフィックが新しいクラスターにルーティングされます。 複数のアプリケーションレプリカをデプロイすれば、ノードのアップグレードおよびスケーリング中にクラスターローカル DNS エンドポイントは到達可能な状態を維持できます。 クラスターローカルエンドポイントでは、同じ環境内のトラフィックのみが許可されます。 ## [](#関連情報)関連情報 - [非公開スペースへのアプリケーションのデプロイ](https://docs.mulesoft.com/jp/cloudhub-2/ch2-deploy-private-space) - [非公開スペースのドメインおよび証明書 (TLS コンテキスト) の設定](https://docs.mulesoft.com/jp/cloudhub-2/ps-config-domains) - [HTTP リスナーリファレンス - Mule 4](https://docs.mulesoft.com/http-connector/latest/http-listener-ref)