Azure Service Fabric Reliable Services での ASP.NET CoreASP.NET Core in Azure Service Fabric Reliable Services

ASP.NET Core は、オープンソースでクロスプラットフォームのフレームワークです。ASP.NET Core is an open-source and cross-platform framework. このフレームワークは、Web アプリ、IoT アプリ、モバイル バックエンドなど、クラウドベースのインターネットに接続されたアプリケーションを構築することを目的に設計されています。This framework is designed for building cloud-based, internet-connected applications, such as web apps, IoT apps, and mobile back ends.

この記事は、Service Fabric Reliable Services で ASP.NET Core サービスをホスティングするための詳細なガイドであり、Microsoft.ServiceFabric.AspNetCore.This article is an in-depth guide to hosting ASP.NET Core services in Service Fabric Reliable Services by using the Microsoft.ServiceFabric.AspNetCore. セットの NuGet パッケージを使います。set of NuGet packages.

Service Fabric の ASP.NET Core の入門チュートリアルと、開発環境のセットアップ方法については、「チュートリアル: ASP.NET Core Web API フロントエンド サービスとステートフルなバックエンド サービスを含むアプリケーションを作成およびデプロイする」をご覧ください。For an introductory tutorial on ASP.NET Core in Service Fabric and instructions on getting your development environment set up, see Tutorial: Create and deploy an application with an ASP.NET Core Web API front-end service and a stateful back-end service.

この記事の残りの部分では、読者が ASP.NET Core に慣れているものと想定しています。The rest of this article assumes you're already familiar with ASP.NET Core. そうでない場合は、ASP.NET Core の基礎に関するページをご覧ください。If not, please read through the ASP.NET Core fundamentals.

Service Fabric 環境の ASP.NET CoreASP.NET Core in the Service Fabric environment

ASP.NET Core アプリと Service Fabric アプリは、.NET Core または完全な .NET Framework で実行できます。Both ASP.NET Core and Service Fabric apps can run on .NET Core or full .NET Framework. Service Fabric では、ASP.NET Core を 2 つの方法で使用できます。You can use ASP.NET Core in two different ways in Service Fabric:

  • ゲスト実行可能ファイルとしてホストするHosted as a guest executable. この方法は、主に、コードを変更せずに Service Fabric 上で既存の ASP.NET Core アプリケーションを実行するために使います。This way is primarily used to run existing ASP.NET Core applications on Service Fabric with no code changes.
  • リライアブル サービス内で実行するRun inside a reliable service. この方法では、Service Fabric ランタイムとの統合がより密になり、ステートフルな ASP.NET Core サービスが可能になります。This way allows better integration with the Service Fabric runtime and allows stateful ASP.NET Core services.

この記事の残りの部分では、Service Fabric SDK に付属する ASP.NET Core 統合コンポーネントを使用して、リライアブル サービス内で ASP.NET Core を使用する方法について説明します。The rest of this article explains how to use ASP.NET Core inside a reliable service, through the ASP.NET Core integration components that ship with the Service Fabric SDK.

Service Fabric サービスのホスティングService Fabric service hosting

Service Fabric では、サービスの 1 つまたは複数のインスタンスやレプリカが "サービス ホスト プロセス" (サービス コードを実行する実行可能ファイル) で実行されます。In Service Fabric, one or more instances and/or replicas of your service run in a service host process: an executable file that runs your service code. サービス作成者はサービス ホスト プロセスを所有し、Service Fabric はそれをアクティブ化して監視します。You, as a service author, own the service host process, and Service Fabric activates and monitors it for you.

従来の ASP.NET (MVC 5 まで) は、System.Web.dll を通じて IIS に厳密に結合されています。Traditional ASP.NET (up to MVC 5) is tightly coupled to IIS through System.Web.dll. ASP.NET Core は、Web サーバーと Web アプリケーションの分離を実現します。ASP.NET Core provides a separation between the web server and your web application. この分離により、Web アプリケーションを異なる Web サーバー間で移植できます。This separation allows web applications to be portable between different web servers. また、Web サーバーを "セルフホステッド" にできます。It also allows web servers to be self-hosted. つまり、IIS のような専用の Web サーバー ソフトウェアによって所有されるプロセスではなく、独自のプロセスで Web サーバーを起動することができます。This means you can start a web server in your own process, as opposed to a process that's owned by dedicated web server software, such as IIS.

Service Fabric サービスと ASP.NET をゲスト実行可能ファイルとして結合するか、リライアブル サービス内で結合するには、サービス ホスト プロセス内で ASP.NET を起動できる必要があります。To combine a Service Fabric service and ASP.NET, either as a guest executable or in a reliable service, you must be able to start ASP.NET inside your service host process. ASP.NET Core の自己ホストにより、これを行うことができます。ASP.NET Core self-hosting allows you to do this.

リライアブル サービスでの ASP.NET Core のホスティングHosting ASP.NET Core in a reliable service

通常、自己ホスト型の ASP.NET Core アプリケーションでは、Program.csstatic void Main() メソッドのように、アプリケーションのエントリ ポイントに WebHost が作成されます。Typically, self-hosted ASP.NET Core applications create a WebHost in an application's entry point, such as the static void Main() method in Program.cs. この場合、WebHost のライフサイクルはプロセスのライフサイクルに拘束されます。In this case, the life cycle of the WebHost is bound to the life cycle of the process.

プロセスでの ASP.NET Core のホスティング

ただし、アプリケーション エントリ ポイントはリライアブル サービス内で WebHost を作成する適切な場所はありません。But the application entry point isn't the right place to create a WebHost in a reliable service. それは、アプリケーション エントリ ポイントは、あるサービスの種類のインスタンスを作成できるように、そのサービスの種類を Service Fabric ランタイムに登録するためだけに使われるからです。That's because the application entry point is only used to register a service type with the Service Fabric runtime, so that it can create instances of that service type. WebHost は、リライアブル サービス自体内に作成する必要があります。The WebHost should be created in a reliable service itself. サービス ホスト プロセス内で、サービス インスタンスやレプリカは、複数のライフサイクルをたどることができます。Within the service host process, service instances and/or replicas can go through multiple life cycles.

リライアブル サービス インスタンスは、StatelessService または StatefulService から派生したサービス クラスによって表されます。A Reliable Service instance is represented by your service class deriving from StatelessService or StatefulService. サービスの通信スタックは、サービス クラスの ICommunicationListener 実装に含まれています。The communication stack for a service is contained in an ICommunicationListener implementation in your service class. Microsoft.ServiceFabric.AspNetCore.* NuGet パッケージには、リライアブル サービス内で Kestrel または HTTP.sys 用の ASP.NET Core WebHost を開始および管理する ICommunicationListener の実装が含まれています。The Microsoft.ServiceFabric.AspNetCore.* NuGet packages contain implementations of ICommunicationListener that start and manage the ASP.NET Core WebHost for either Kestrel or HTTP.sys in a reliable service.

リライアブル サービスでの ASP.NET Core のホスティングの図

ASP.NET Core ICommunicationListenerASP.NET Core ICommunicationListeners

Microsoft.ServiceFabric.AspNetCore.* NuGet パッケージ内の Kestrel および HTTP.sys 用の ICommunicationListener の実装には、似た使用パターンがあります。The ICommunicationListener implementations for Kestrel and HTTP.sys in the Microsoft.ServiceFabric.AspNetCore.* NuGet packages have similar use patterns. ただし、Web サーバーごとに固有の若干異なるアクションが実行されます。But they perform slightly different actions specific to each web server.

どちらの通信リスナーも、次の引数を受け取るコンストラクターを提供します。Both communication listeners provide a constructor that takes the following arguments:

  • ServiceContext serviceContext :これは、実行中のサービスに関する情報を含む ServiceContext オブジェクトです。ServiceContext serviceContext: This is the ServiceContext object that contains information about the running service.
  • string endpointName :これは、ServiceManifest.xml での Endpoint 構成の名前です。string endpointName: This is the name of an Endpoint configuration in ServiceManifest.xml. 2 つの通信リスナーが異なるのは主にこの部分です。It's primarily where the two communication listeners differ. HTTP.sys では Endpoint 構成が "必要です" が、Kestrel では必要ありません。HTTP.sys requires an Endpoint configuration, while Kestrel doesn't.
  • Func<string, AspNetCoreCommunicationListener, IWebHost> build :これは、IWebHost を作成して返すために実装するラムダです。Func<string, AspNetCoreCommunicationListener, IWebHost> build: This is a lambda that you implement, in which you create and return an IWebHost. それにより、ASP.NET Core アプリケーションで通常行う方法で、IWebHost を構成することができます。It allows you to configure IWebHost the way you normally would in an ASP.NET Core application. ラムダによって URL が提供されます。この URL は、使用した Service Fabric 統合オプションと提供した Endpoint 構成に応じて自動的に生成されます。The lambda provides a URL that's generated for you, depending on the Service Fabric integration options you use and the Endpoint configuration you provide. その後、その URL を変更したり、その URL を使って Web サーバーを起動したりできます。You can then modify or use that URL to start the web server.

Service Fabric 統合ミドルウェアService Fabric integration middleware

Microsoft.ServiceFabric.AspNetCore NuGet パッケージには、Service Fabric 対応のミドルウェアを追加する IWebHostBuilderUseServiceFabricIntegration 拡張メソッドが含まれています。The Microsoft.ServiceFabric.AspNetCore NuGet package includes the UseServiceFabricIntegration extension method on IWebHostBuilder that adds Service Fabric–aware middleware. このミドルウェアでは、Service Fabric Naming Service に一意のサービス URL を登録するように、Kestrel または HTTP.sys の ICommunicationListener が構成されます。This middleware configures the Kestrel or HTTP.sys ICommunicationListener to register a unique service URL with the Service Fabric Naming Service. その後、クライアント要求を検証して、クライアントが適切なサービスに接続していることが確認されます。It then validates client requests to ensure clients are connecting to the right service.

このステップは、クライアントが誤って間違ったサービスに接続するのを防ぐために必要です。This step is necessary to prevent clients from mistakenly connecting to the wrong service. それは、Service Fabric のような共有ホスト環境では、複数の Web アプリケーションが同一の物理マシンまたは仮想マシンで実行できますが、一意のホスト名を使わないためです。That's because, in a shared-host environment such as Service Fabric, multiple web applications can run on the same physical or virtual machine but don't use unique host names. このシナリオについては、次のセクションで詳しく説明します。This scenario is described in more detail in the next section.

ID が誤っている場合A case of mistaken identity

サービス レプリカは、プロトコルに関係なく、一意の "IP:ポート" の組み合わせでリッスンします。Service replicas, regardless of protocol, listen on a unique IP:port combination. "IP:ポート" エンドポイントでリッスンを開始したサービス レプリカでは、そのエンドポイント アドレスが Service Fabric Naming Service に報告されます。Once a service replica has started listening on an IP:port endpoint, it reports that endpoint address to the Service Fabric Naming Service. そこでは、クライアントまたは他のサービスがそれを検出できます。There, clients or other services can discover it. 動的に割り当てられるアプリケーション ポートがサービスで使用されている場合、同じ物理マシンまたは仮想マシンに以前に存在していた別のサービスの同じ "IP:ポート" エンドポイントがサービス レプリカによって偶然使用される可能性があります。If services use dynamically assigned application ports, a service replica might coincidentally use the same IP:port endpoint of another service previously on the same physical or virtual machine. これにより、クライアントが誤って不適切なサービスに接続する可能性があります。This can cause a client to mistakenly connect to the wrong service. このシナリオは、次の一連のイベントが発生した場合に発生する可能性があります。This scenario can result if the following sequence of events occurs:

  1. サービス A が、HTTP 経由で 10.0.0.1:30000 でリッスンする。Service A listens on 10.0.0.1:30000 over HTTP.
  2. クライアントがサービス A を解決して、アドレス 10.0.0.1:30000 を取得する。Client resolves Service A and gets address 10.0.0.1:30000.
  3. サービス A が別のノードに移動する。Service A moves to a different node.
  4. サービス B が 10.0.0.1 に配置され、偶然に同じポート 30000 を使用する。Service B is placed on 10.0.0.1 and coincidentally uses the same port 30000.
  5. クライアントが、キャッシュされているアドレス 10.0.0.1:30000 を使用してサービス A への接続を試みる。Client attempts to connect to service A with cached address 10.0.0.1:30000.
  6. クライアントが、不適切なサービスに接続されていることを認識しないままサービス B に接続される。Client is now successfully connected to service B, not realizing it's connected to the wrong service.

これが原因で、診断するのが困難なバグが不規則に発生する場合があります。This can cause bugs at random times that can be difficult to diagnose.

一意のサービス URL の使用Using unique service URLs

これらのバグを防ぐため、サービスでは、一意の識別子を使用して Naming Service にエンドポイントを送信し、クライアント要求中にその一意の識別子を検証できます。To prevent these bugs, services can post an endpoint to the Naming Service with a unique identifier, and then validate that unique identifier during client requests. これは、悪意のないテナントの信頼できる環境におけるサービス間の協調アクションです。This is a cooperative action between services in a non-hostile-tenant trusted environment. それにより、悪意のあるテナント環境でセキュリティで保護されたサービスの認証が提供されるわけではありません。It doesn't provide secure service authentication in a hostile-tenant environment.

信頼できる環境では、UseServiceFabricIntegration メソッドによって追加されたミドルウェアによって、Naming Service に送信されるアドレスに一意の識別子が自動的に追加されます。In a trusted environment, the middleware that's added by the UseServiceFabricIntegration method automatically appends a unique identifier to the address posted to the Naming Service. それにより、各要求でその識別子が検証されます。It validates that identifier on each request. 識別子が一致しない場合、ミドルウェアでは即座に HTTP 410 Gone 応答が返されます。If the identifier doesn't match, the middleware immediately returns an HTTP 410 Gone response.

動的に割り当てられたポートを使用するサービスでは、このミドルウェアを使用する必要があります。Services that use a dynamically assigned port should make use of this middleware.

固定された一意のポートを使用するサービスでは、協調環境においてこの問題は発生しません。Services that use a fixed unique port don't have this problem in a cooperative environment. 通常、固定された一意のポートは、クライアント アプリケーションが接続するための一般的なポートを必要とする外部向けサービスに使用されます。A fixed unique port is typically used for externally facing services that need a well-known port for client applications to connect to. たとえば、ほとんどのインターネット接続 Web アプリケーションでは、Web ブラウザー接続にポート 80 または 443 が使用されます。For example, most internet-facing web applications will use port 80 or 443 for web browser connections. この場合は、一意の識別子を有効にしないでください。In this case, the unique identifier shouldn't be enabled.

次の図は、ミドルウェアを有効にした場合の要求フローを示しています。The following diagram shows the request flow with the middleware enabled:

Service Fabric ASP.NET Core の統合

Kestrel と HTTP.sys のどちらの ICommunicationListener の実装でも、まったく同じ方法でこのメカニズムが使用されます。Both Kestrel and HTTP.sys ICommunicationListener implementations use this mechanism in exactly the same way. HTTP.sys では、基になる HTTP.sys ポート共有機能を使用して、一意の URL パスを基に要求を内部的に区別できますが、その機能は HTTP.sys の ICommunicationListener の実装では使用 "されません"。Although HTTP.sys can internally differentiate requests based on unique URL paths by using the underlying HTTP.sys port sharing feature, that functionality is not used by the HTTP.sys ICommunicationListener implementation. それは、前述のシナリオで HTTP 503 および HTTP 404 エラー状態コードになるためです。That's because it results in HTTP 503 and HTTP 404 error status codes in the scenario described earlier. さらに、HTTP 503 と HTTP 404 は他のエラーを示すために一般的に使用されるため、クライアントでエラーの意味を判断するのが困難になります。That in turn makes it difficult for clients to determine the intent of the error, as HTTP 503 and HTTP 404 are commonly used to indicate other errors.

このため、Kestrel と HTTP.sys どちらの ICommunicationListener の実装も、UseServiceFabricIntegration 拡張メソッドによって提供されるミドルウェアで標準化されます。Thus, both Kestrel and HTTP.sys ICommunicationListener implementations standardize on middleware provided by the UseServiceFabricIntegration extension method. したがって、クライアントでは、HTTP 410 の応答に対するサービス エンドポイントの再解決アクションを実行することだけが必要です。Therefore, clients only need to perform a service endpoint re-resolve action on HTTP 410 responses.

Reliable Services での HTTP.sysHTTP.sys in Reliable Services

Microsoft.ServiceFabric.AspNetCore.HttpSys NuGet パッケージをインポートすることにより、Reliable Services で HTTP.sys を使用できます。You can use HTTP.sys in Reliable Services by importing the Microsoft.ServiceFabric.AspNetCore.HttpSys NuGet package. このパッケージには、ICommunicationListener の実装である HttpSysCommunicationListener が含まれます。This package contains HttpSysCommunicationListener, an implementation of ICommunicationListener. HttpSysCommunicationListener により、Web サーバーとして HTTP.sys を使って、リライアブル サービスの内部に ASP.NET Core WebHost を作成できます。HttpSysCommunicationListener allows you to create an ASP.NET Core WebHost inside a reliable service by using HTTP.sys as the web server.

HTTP.sys は、Windows HTTP Server API に基づいて構築されています。HTTP.sys is built on the Windows HTTP Server API. この API では、HTTP.sys カーネル ドライバーを使って HTTP 要求が処理され、Web アプリケーションを実行するプロセスにルーティングされます。This API uses the HTTP.sys kernel driver to process HTTP requests and route them to processes that run web applications. これにより、同一の物理マシンまたは仮想マシン上の複数のプロセスが、一意の URL パスまたはホスト名によって明確化された Web アプリケーションを同じポート上でホストできます。This allows multiple processes on the same physical or virtual machine to host web applications on the same port, disambiguated by either a unique URL path or host name. これらの機能は、Service Fabric で同じクラスター内の複数の Web サイトをホストする場合に役立ちます。These features are useful in Service Fabric for hosting multiple websites in the same cluster.

注意

HTTP.sys の実装は、Windows プラットフォームでのみ動作します。HTTP.sys implementation works only on the Windows platform.

次の図では、HTTP.sys がポート共有のために Windows 上で HTTP.sys カーネル ドライバーを使用する方法を示します。The following diagram illustrates how HTTP.sys uses the HTTP.sys kernel driver on Windows for port sharing:

HTTP.sys の図

ステートレス サービスでの HTTP.sysHTTP.sys in a stateless service

ステートレス サービスで HttpSys を使用するには、CreateServiceInstanceListeners メソッドをオーバーライドして HttpSysCommunicationListener インスタンスを返します。To use HttpSys in a stateless service, override the CreateServiceInstanceListeners method and return a HttpSysCommunicationListener instance:

protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
{
    return new ServiceInstanceListener[]
    {
        new ServiceInstanceListener(serviceContext =>
            new HttpSysCommunicationListener(serviceContext, "ServiceEndpoint", (url, listener) =>
                new WebHostBuilder()
                    .UseHttpSys()
                    .ConfigureServices(
                        services => services
                            .AddSingleton<StatelessServiceContext>(serviceContext))
                    .UseContentRoot(Directory.GetCurrentDirectory())
                    .UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.None)
                    .UseStartup<Startup>()
                    .UseUrls(url)
                    .Build()))
    };
}

ステートフル サービスでの HTTP.sysHTTP.sys in a stateful service

HttpSysCommunicationListener は、基になる HTTP.sys ポート共有機能に関する複雑な要素が絡んでくるため、現時点ではステートフル サービス向けには設計されていません。HttpSysCommunicationListener isn't currently designed for use in stateful services due to complications with the underlying HTTP.sys port sharing feature. 詳細については、HTTP.sys を使用した動的ポート割り当てに関する次のセクションを参照してください。For more information, see the following section on dynamic port allocation with HTTP.sys. ステートフル サービスの場合、Web サーバーとして Kestrel が推奨されます。For stateful services, Kestrel is the suggested web server.

Endpoint configuration (エンドポイントの構成)Endpoint configuration

HTTP.sys を含む Windows HTTP Server API を使用する Web サーバーには、Endpoint 構成が必要です。An Endpoint configuration is required for web servers that use the Windows HTTP Server API, including HTTP.sys. Windows HTTP Server API を使用する Web サーバーでは、最初に HTTP.sys で URL を予約する必要があります (通常、この操作は netsh ツールを使用して実行します)。Web servers that use the Windows HTTP Server API must first reserve their URL with HTTP.sys (this is normally accomplished with the netsh tool).

このアクションには、サービスに既定では付与されていない昇格された特権が必要です。This action requires elevated privileges that your services don't have by default. ServiceManifest.xml の Endpoint 構成の Protocol プロパティの "http" または "https" オプションは、ユーザーの代わりに HTTP.sys に URL を登録するよう Service Fabric ランタイムに明確に指示するために使用されます。The "http" or "https" options for the Protocol property of the Endpoint configuration in ServiceManifest.xml are used specifically to instruct the Service Fabric runtime to register a URL with HTTP.sys on your behalf. それは、強力なワイルドカード URL プレフィックスを使用して行われます。It does this by using the strong wildcard URL prefix.

たとえば、サービス用に http://+:80 を予約するには、ServiceManifest.xml で次の構成を使用します。For example, to reserve http://+:80 for a service, use the following configuration in ServiceManifest.xml:

<ServiceManifest ... >
    ...
    <Resources>
        <Endpoints>
            <Endpoint Name="ServiceEndpoint" Protocol="http" Port="80" />
        </Endpoints>
    </Resources>

</ServiceManifest>

また、エンドポイント名は HttpSysCommunicationListener コンストラクターに渡す必要があります。And the endpoint name must be passed to the HttpSysCommunicationListener constructor:

 new HttpSysCommunicationListener(serviceContext, "ServiceEndpoint", (url, listener) =>
 {
     return new WebHostBuilder()
         .UseHttpSys()
         .UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.None)
         .UseUrls(url)
         .Build();
 })

静的ポートで HTTP.sys を使用するUse HTTP.sys with a static port

HTTP.sys で静的ポートを使用するには、Endpoint 構成でポート番号を指定します。To use a static port with HTTP.sys, provide the port number in the Endpoint configuration:

  <Resources>
    <Endpoints>
      <Endpoint Protocol="http" Name="ServiceEndpoint" Port="80" />
    </Endpoints>
  </Resources>

動的ポートで HTTP.sys を使用するUse HTTP.sys with a dynamic port

HTTP.sys で動的に割り当てられたポートを使用するには、Endpoint 構成の Port プロパティを省略します。To use a dynamically assigned port with HTTP.sys, omit the Port property in the Endpoint configuration:

  <Resources>
    <Endpoints>
      <Endpoint Protocol="http" Name="ServiceEndpoint" />
    </Endpoints>
  </Resources>

Endpoint 構成によって割り当てられた動的ポートでは、"ホスト プロセスごとに" 1 つのポートのみが提供されます。A dynamic port allocated by an Endpoint configuration provides only one port per host process. 現在の Service Fabric ホスティング モデルは、複数のサービス インスタンスやレプリカを、同じプロセスでホストできます。The current Service Fabric hosting model allows multiple service instances and/or replicas to be hosted in the same process. つまり、Endpoint 構成によって割り当てられると、それぞれで同じポートが共有されます。This means each one will share the same port when allocated through the Endpoint configuration. 基になる HTTP.sys ポート共有機能を使用して、複数の HTTP.sys インスタンスで 1 つのポートを共有できます。Multiple HTTP.sys instances can share a port by using the underlying HTTP.sys port sharing feature. ただし、HttpSysCommunicationListener の場合は、クライアント要求にもたらされる複雑さのためサポートされません。But it's not supported by HttpSysCommunicationListener due to the complications it introduces for client requests. ポートを動的に使用する場合、Web サーバーとして Kestrel が推奨されます。For dynamic port usage, Kestrel is the suggested web server.

リライアブル サービスでの KestrelKestrel in Reliable Services

Microsoft.ServiceFabric.AspNetCore.Kestrel NuGet パッケージをインポートすることにより、Reliable Services で Kestrel を使用できます。You can use Kestrel in Reliable Services by importing the Microsoft.ServiceFabric.AspNetCore.Kestrel NuGet package. このパッケージには、ICommunicationListener の実装である KestrelCommunicationListener が含まれます。This package contains KestrelCommunicationListener, an implementation of ICommunicationListener. KestrelCommunicationListener により、Web サーバーとして Kestrel を使って、リライアブル サービスの内部に ASP.NET Core WebHost を作成できます。KestrelCommunicationListener allows you to create an ASP.NET Core WebHost inside a reliable service by using Kestrel as the web server.

Kestrel は、ASP.NET Core 用のクロスプラットフォーム Web サーバーです。Kestrel is a cross-platform web server for ASP.NET Core. HTTP.sys とは異なり、Kestrel では一元的なエンドポイント マネージャーは使用されません。Unlike HTTP.sys, Kestrel doesn't use a centralized endpoint manager. また、HTTP.sys とは異なり、Kestrel では複数のプロセス間のポート共有はサポートされません。Also unlike HTTP.sys, Kestrel doesn't support port sharing between multiple processes. Kestrel の各インスタンスは、一意のポートを使用する必要があります。Each instance of Kestrel must use a unique port. Kestrel の詳細については、実装の詳細 に関する記事を参照してください。For more on Kestrel, see the Implementation Details.

Kestrel の図

ステートレス サービスでの KestrelKestrel in a stateless service

ステートレス サービスで Kestrel を使用するには、CreateServiceInstanceListeners メソッドをオーバーライドして KestrelCommunicationListener インスタンスを返します。To use Kestrel in a stateless service, override the CreateServiceInstanceListeners method and return a KestrelCommunicationListener instance:

protected override IEnumerable<ServiceInstanceListener> CreateServiceInstanceListeners()
{
    return new ServiceInstanceListener[]
    {
        new ServiceInstanceListener(serviceContext =>
            new KestrelCommunicationListener(serviceContext, "ServiceEndpoint", (url, listener) =>
                new WebHostBuilder()
                    .UseKestrel()
                    .ConfigureServices(
                        services => services
                            .AddSingleton<StatelessServiceContext>(serviceContext))
                    .UseContentRoot(Directory.GetCurrentDirectory())
                    .UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.UseUniqueServiceUrl)
                    .UseStartup<Startup>()
                    .UseUrls(url)
                    .Build();
            ))
    };
}

ステートフル サービスでの KestrelKestrel in a stateful service

ステートフル サービスで Kestrel を使用するには、CreateServiceReplicaListeners メソッドをオーバーライドして KestrelCommunicationListener インスタンスを返します。To use Kestrel in a stateful service, override the CreateServiceReplicaListeners method and return a KestrelCommunicationListener instance:

protected override IEnumerable<ServiceReplicaListener> CreateServiceReplicaListeners()
{
    return new ServiceReplicaListener[]
    {
        new ServiceReplicaListener(serviceContext =>
            new KestrelCommunicationListener(serviceContext, (url, listener) =>
                new WebHostBuilder()
                    .UseKestrel()
                    .ConfigureServices(
                         services => services
                             .AddSingleton<StatefulServiceContext>(serviceContext)
                             .AddSingleton<IReliableStateManager>(this.StateManager))
                    .UseContentRoot(Directory.GetCurrentDirectory())
                    .UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.UseUniqueServiceUrl)
                    .UseStartup<Startup>()
                    .UseUrls(url)
                    .Build();
            ))
    };
}

この例では、IReliableStateManager のシングルトン インスタンスが WebHost 依存関係挿入コンテナーに提供されています。In this example, a singleton instance of IReliableStateManager is provided to the WebHost dependency injection container. これは厳密には必要ではありませんが、MVC コントローラーのアクション メソッドで IReliableStateManager と Reliable Collection を使用することができます。This isn't strictly necessary, but it allows you to use IReliableStateManager and Reliable Collections in your MVC controller action methods.

Endpoint 構成名はステートフル サービスの KestrelCommunicationListener に提供されませんAn Endpoint configuration name is not provided to KestrelCommunicationListener in a stateful service. これについては、次のセクションで詳しく説明します。This is explained in more detail in the following section.

HTTPS を使用するように Kestrel を構成するConfigure Kestrel to use HTTPS

サービスの Kestrel で HTTPS を有効にするときは、複数のリッスン オプションを設定する必要があります。When enabling HTTPS with Kestrel in your service, you'll need to set several listening options. EndpointHttps エンドポイントを使用し、特定のポート (ポート 443 など) でリッスンするように、ServiceInstanceListener を更新します。Update the ServiceInstanceListener to use an EndpointHttps endpoint and listen on a specific port (such as port 443). Kestrel Web サーバーを使用するよう Web ホストを構成するときは、すべてのネットワーク インターフェイスで IPv6 アドレスをリッスンするように Kestrel を構成する必要があります。When configuring the web host to use the Kestrel web server, you must configure Kestrel to listen for IPv6 addresses on all network interfaces:

new ServiceInstanceListener(
serviceContext =>
    new KestrelCommunicationListener(
        serviceContext,
        "EndpointHttps",
        (url, listener) =>
        {
            ServiceEventSource.Current.ServiceMessage(serviceContext, $"Starting Kestrel on {url}");

            return new WebHostBuilder()
                .UseKestrel(opt =>
                {
                    int port = serviceContext.CodePackageActivationContext.GetEndpoint("EndpointHttps").Port;
                    opt.Listen(IPAddress.IPv6Any, port, listenOptions =>
                    {
                        listenOptions.UseHttps(GetCertificateFromStore());
                        listenOptions.NoDelay = true;
                    });
                })
                .ConfigureAppConfiguration((builderContext, config) =>
                {
                    config.AddJsonFile("appsettings.json", optional: false, reloadOnChange: true);
                })

                .ConfigureServices(
                    services => services
                        .AddSingleton<HttpClient>(new HttpClient())
                        .AddSingleton<FabricClient>(new FabricClient())
                        .AddSingleton<StatelessServiceContext>(serviceContext))
                .UseContentRoot(Directory.GetCurrentDirectory())
                .UseStartup<Startup>()
                .UseServiceFabricIntegration(listener, ServiceFabricIntegrationOptions.None)
                .UseUrls(url)
                .Build();
        }))

チュートリアルの例の完全なものについては、「HTTPS を使用するように Kestrel を構成する」をご覧ください。For a full example in a tutorial, see Configure Kestrel to use HTTPS.

Endpoint configuration (エンドポイントの構成)Endpoint configuration

Kestrel を使用するうえで Endpoint 構成は必要ありません。An Endpoint configuration isn't required to use Kestrel.

Kestrel は単純なスタンドアロンの Web サーバーです。Kestrel is a simple standalone web server. HTTP.sys (または HttpListener) とは異なり、開始する前に URL を登録する必要がないため、ServiceManifest.xml の Endpoint 構成は必要ありません。Unlike HTTP.sys (or HttpListener), it doesn't need an Endpoint configuration in ServiceManifest.xml because it doesn't require URL registration before starting.

Kestrel での静的ポートの使用Use Kestrel with a static port

ServiceManifest.xml の Endpoint 構成において、Kestrel で使用する静的ポートを構成できます。You can configure a static port in the Endpoint configuration of ServiceManifest.xml for use with Kestrel. これは厳密には必要ではありませんが、2 つの潜在的な利点があります。Although this isn't strictly necessary, it offers two potential benefits:

  • ポートがアプリケーションのポート範囲にない場合、Service Fabric によって OS のファイアウォールを介してポートが開かれます。If the port doesn't fall in the application port range, it's opened through the OS firewall by Service Fabric.
  • KestrelCommunicationListener を介して提供される URL では、このポートが使用されます。The URL provided to you through KestrelCommunicationListener will use this port.
  <Resources>
    <Endpoints>
      <Endpoint Protocol="http" Name="ServiceEndpoint" Port="80" />
    </Endpoints>
  </Resources>

Endpoint が構成されている場合は、その名前を KestrelCommunicationListener コンストラクターに渡す必要があります。If an Endpoint is configured, its name must be passed into the KestrelCommunicationListener constructor:

new KestrelCommunicationListener(serviceContext, "ServiceEndpoint", (url, listener) => ...

ServiceManifest.xml で Endpoint 構成を使わない場合は、KestrelCommunicationListener コンストラクター内で名前を省略します。If ServiceManifest.xml doesn't use an Endpoint configuration, omit the name in the KestrelCommunicationListener constructor. この場合、動的ポートが使用されます。In this case, it will use a dynamic port. この詳細については、次のセクションを参照してください。See the next section for more information about this.

Kestrel での動的ポートの使用Use Kestrel with a dynamic port

Kestrel では、ServiceManifest.xml での Endpoint 構成からの自動ポート割り当てを使用できません。Kestrel can't use the automatic port assignment from the Endpoint configuration in ServiceManifest.xml. それは、Endpoint 構成からの自動ポート割り当てでは "ホスト プロセス" ごとに一意のポートが割り当てられ、単一のホスト プロセスが複数の Kestrel インスタンスを含むことができるためです。That's because automatic port assignment from an Endpoint configuration assigns a unique port per host process, and a single host process can contain multiple Kestrel instances. Kestrel では、ポート共有がサポートされていないため、これは動作しません。This doesn't work with Kestrel because it doesn't support port sharing. そのため、各 Kestrel インスタンスを固有のポートで開く必要があります。Therefore, each Kestrel instance must be opened on a unique port.

Kestrel で動的ポート割り当てを使用するには、ServiceManifest.xml の Endpoint 構成を省略し、次のように、エンドポイント名を KestrelCommunicationListener コンストラクターに渡さないようにします。To use dynamic port assignment with Kestrel, omit the Endpoint configuration in ServiceManifest.xml entirely, and don't pass an endpoint name to the KestrelCommunicationListener constructor, as follows:

new KestrelCommunicationListener(serviceContext, (url, listener) => ...

この構成では、KestrelCommunicationListener により、アプリケーション ポートの範囲から未使用のポートが自動的に選択されます。In this configuration, KestrelCommunicationListener will automatically select an unused port from the application port range.

Service Fabric 構成プロバイダーService Fabric configuration provider

ASP.NET Core でのアプリの構成は、構成プロバイダーによって設定されるキーと値のペアに基づきます。App configuration in ASP.NET Core is based on key-value pairs established by the configuration provider. 一般的な ASP.NET Core 構成のサポートの詳細については、「ASP.NET Core の構成」を参照してください。Read Configuration in ASP.NET Core to understand more on general ASP.NET Core configuration support.

このセクションでは、Microsoft.ServiceFabric.AspNetCore.Configuration NuGet パッケージをインポートして、ASP.NET Core の構成に Service Fabric 構成プロバイダーを統合する方法について説明します。This section describes how the Service Fabric configuration provider integrates with ASP.NET Core configuration by importing the Microsoft.ServiceFabric.AspNetCore.Configuration NuGet package.

AddServiceFabricConfiguration 起動の拡張機能AddServiceFabricConfiguration startup extensions

Microsoft.ServiceFabric.AspNetCore.Configuration NuGet パッケージをインポートした後、ASP.NET Core 構成 API に Service Fabric 構成ソースを登録する必要があります。After you import the Microsoft.ServiceFabric.AspNetCore.Configuration NuGet package, you need to register the Service Fabric Configuration source with ASP.NET Core configuration API. これを行うには、IConfigurationBuilder に対して Microsoft.ServiceFabric.AspNetCore.Configuration 名前空間で AddServiceFabricConfiguration 拡張機能をチェックします。You do this by checking AddServiceFabricConfiguration extensions in the Microsoft.ServiceFabric.AspNetCore.Configuration namespace against IConfigurationBuilder.

using Microsoft.ServiceFabric.AspNetCore.Configuration;

public Startup(IHostingEnvironment env)
{
    var builder = new ConfigurationBuilder()
        .SetBasePath(env.ContentRootPath)
        .AddJsonFile("appsettings.json", optional: false, reloadOnChange: true)
        .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true)
        .AddServiceFabricConfiguration() // Add Service Fabric configuration settings.
        .AddEnvironmentVariables();
    Configuration = builder.Build();
}

public IConfigurationRoot Configuration { get; }

これで、他のアプリケーション設定と同様に ASP.NET Core サービスが Service Fabric 構成設定にアクセスできるようになります。Now the ASP.NET Core service can access the Service Fabric configuration settings, just like any other application settings. たとえば、このオプションのパターンを使用すると、厳密に型指定されたオブジェクトに設定を読み込むことができます。For example, you can use the options pattern to load settings into strongly typed objects.

public void ConfigureServices(IServiceCollection services)
{
    services.Configure<MyOptions>(Configuration);  // Strongly typed configuration object.
    services.AddMvc();
}

既定のキー マッピングDefault key mapping

既定では、Service Fabric 構成プロバイダーには、パッケージ名、セクション名、およびプロパティ名が含まれます。By default, the Service Fabric configuration provider includes the package name, section name, and property name. これらにより、次のように、ASP.NET Core 構成キーが形成されます。Together, these form the ASP.NET Core configuration key, as follows:

$"{this.PackageName}{ConfigurationPath.KeyDelimiter}{section.Name}{ConfigurationPath.KeyDelimiter}{property.Name}"

たとえば、次の内容の MyConfigPackage という名前の構成パッケージがある場合、構成値は ASP.NET Core IConfiguration で、MyConfigPackage:MyConfigSection:MyParameter を介して使用可能になります。For example, if you have a configuration package named MyConfigPackage with the following content, then the configuration value will be available on ASP.NET Core IConfiguration through MyConfigPackage:MyConfigSection:MyParameter.

<?xml version="1.0" encoding="utf-8" ?>
<Settings xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/2011/01/fabric">  
  <Section Name="MyConfigSection">
    <Parameter Name="MyParameter" Value="Value1" />
  </Section>  
</Settings>

Service Fabric の構成オプションService Fabric configuration options

Service Fabric 構成プロバイダーでは、キー マッピングの既定の動作を変更する ServiceFabricConfigurationOptions もサポートされています。The Service Fabric configuration provider also supports ServiceFabricConfigurationOptions to change the default behavior of key mapping.

暗号化された設定Encrypted settings

Service Fabric では暗号化された設定がサポートされており、Service Fabric 構成プロバイダーでもサポートされています。Service Fabric supports encrypted settings, as does the Service Fabric configuration provider. 暗号化された設定は、既定では ASP.NET Core IConfiguration に復号化されません。The encrypted settings aren't decrypted to ASP.NET Core IConfiguration by default. 代わりに暗号化された値がそこに保存されます。The encrypted values are stored there instead. ただし、ASP.NET Core IConfiguration に格納する値を暗号化解除したい場合、次のように AddServiceFabricConfiguration 拡張機能で DecryptValue フラグを false に設定できます。But if you want to decrypt the value to store in ASP.NET Core IConfiguration, you can set the DecryptValue flag to false in the AddServiceFabricConfiguration extension, as follows:

public Startup()
{
    ICodePackageActivationContext activationContext = FabricRuntime.GetActivationContext();
    var builder = new ConfigurationBuilder()        
        .AddServiceFabricConfiguration(activationContext, (options) => options.DecryptValue = false); // set flag to decrypt the value
    Configuration = builder.Build();
}

複数の構成パッケージMultiple configuration packages

Service Fabric では複数の構成パッケージをサポートしています。Service Fabric supports multiple configuration packages. 既定では、パッケージ名は構成キーに含まれます。By default, the package name is included in the configuration key. ただし、次のように IncludePackageName フラグを false に設定することができます。But you can set the IncludePackageName flag to false, as follows:

public Startup()
{
    ICodePackageActivationContext activationContext = FabricRuntime.GetActivationContext();
    var builder = new ConfigurationBuilder()        
        // exclude package name from key.
        .AddServiceFabricConfiguration(activationContext, (options) => options.IncludePackageName = false); 
    Configuration = builder.Build();
}

カスタム キー マッピング、値の抽出、およびデータの設定Custom key mapping, value extraction, and data population

Service Fabric 構成プロバイダーでは、ExtractKeyFunc によるキー マッピングのカスタマイズや、ExtractValueFunc による値のカスタム抽出など、より高度なシナリオもサポートされています。The Service Fabric configuration provider also supports more advanced scenarios to customize the key mapping with ExtractKeyFunc and custom-extract the values with ExtractValueFunc. Service Fabric 構成から ASP.NET Core 構成にデータを設定するプロセス全体を、ConfigAction を使用して変更することもできます。You can even change the whole process of populating data from Service Fabric configuration to ASP.NET Core configuration by using ConfigAction.

次の例では、ConfigAction を使用してデータ設定をカスタマイズする方法を示します。The following examples illustrate how to use ConfigAction to customize data population:

public Startup()
{
    ICodePackageActivationContext activationContext = FabricRuntime.GetActivationContext();
    
    this.valueCount = 0;
    this.sectionCount = 0;
    var builder = new ConfigurationBuilder();
    builder.AddServiceFabricConfiguration(activationContext, (options) =>
        {
            options.ConfigAction = (package, configData) =>
            {
                ILogger logger = new ConsoleLogger("Test", null, false);
                logger.LogInformation($"Config Update for package {package.Path} started");

                foreach (var section in package.Settings.Sections)
                {
                    this.sectionCount++;

                    foreach (var param in section.Parameters)
                    {
                        configData[options.ExtractKeyFunc(section, param)] = options.ExtractValueFunc(section, param);
                        this.valueCount++;
                    }
                }

                logger.LogInformation($"Config Update for package {package.Path} finished");
            };
        });
  Configuration = builder.Build();
}

構成の更新Configuration updates

Service Fabric の構成プロバイダーでは、構成の更新もサポートされています。The Service Fabric configuration provider also supports configuration updates. ASP.NET Core の IOptionsMonitor を使って変更通知を受け取った後、IOptionsSnapshot を使って構成データを再度読み込むことができます。You can use ASP.NET Core IOptionsMonitor to receive change notifications, and then use IOptionsSnapshot to reload configuration data. 詳細については、ASP.NET Core のオプションに関するページを参照してください。For more information, see ASP.NET Core options.

これらのオプションは既定でサポートされています。These options are supported by default. 構成の更新を有効にするために、さらにコーディングする必要はありません。No further coding is needed to enable configuration updates.

シナリオと構成Scenarios and configurations

このセクションでは、以下のシナリオをトラブルシューティングするために推奨される、Web サーバー、ポート構成、Service Fabric 統合オプション、およびその他の設定の組み合わせを示します。This section provides the combination of web server, port configuration, Service Fabric integration options, and miscellaneous settings we recommend to troubleshoot the following scenarios:

  • 外部に公開される ASP.NET Core ステートレス サービスExternally exposed ASP.NET Core stateless services
  • 内部専用の ASP.NET Core ステートレス サービスInternal-only ASP.NET Core stateless services
  • 内部専用の ASP.NET Core ステートフル サービスInternal-only ASP.NET Core stateful services

外部に公開されるサービスとは、通常はロード バランサーを介してクラスターの外部から呼び出されるエンドポイントを公開するサービスです。An externally exposed service is one that exposes an endpoint that's called from outside the cluster, usually through a load balancer.

内部専用のサービスとは、クラスター内からのみエンドポイントを呼び出すことができるサービスです。An internal-only service is one whose endpoint is only called from within the cluster.

注意

ステートフル サービス エンドポイントは、通常、インターネットに公開されません。Stateful service endpoints generally shouldn't be exposed to the internet. Azure Load Balancer など、Service Fabric のサービス解決に対応していないロード バランサーの背後にあるクラスターでは、ステートフル サービスを公開できません。Clusters behind load balancers that are unaware of Service Fabric service resolution, such as Azure Load Balancer, will be unable to expose stateful services. それは、ロード バランサーで適切なステートフル サービス レプリカを特定してトラフィックをルーティングできないためです。That's because the load balancer won't be able to locate and route traffic to the appropriate stateful service replica.

外部に公開される ASP.NET Core ステートレス サービスExternally exposed ASP.NET Core stateless services

外部のインターネットに接続された HTTP エンドポイントを公開するフロントエンド サービス用の Web サーバーとして、Kestrel をお勧めします。Kestrel is the suggested web server for front-end services that expose external, internet-facing HTTP endpoints. Windows では、HTTP.sys で提供できるポート共有機能により、同じポートを使用して同じノードのセットで複数の Web サービスをホストすることができます。On Windows, HTTP.sys can provide port sharing capability, which allows you to host multiple web services on the same set of nodes using the same port. このシナリオでは、Web サービスはホスト名またはパスによって区別され、HTTP ルーティングを提供するためにフロントエンド プロキシまたはゲートウェイに依存しません。In this scenario, the web services are differentiated by host name or path, without relying on a front-end proxy or gateway to provide HTTP routing.

インターネットに公開されるステートレス サービスでは、ロード バランサーを介して到達できる、安定した一般的なエンドポイントを使用する必要があります。When exposed to the internet, a stateless service should use a well-known and stable endpoint that's reachable through a load balancer. アプリケーションのユーザーにこの URL を提供します。You'll provide this URL to your application's users. 次の構成をお勧めします。We recommend the following configuration:

メモNotes
Web サーバーWeb server KestrelKestrel Kestrel は Windows と Linux でサポートされているため、好まれている Web サーバーです。Kestrel is the preferred web server, as it's supported across Windows and Linux.
ポート構成Port configuration 静的static 一般的な静的ポートを ServiceManifest.xml の Endpoints 構成で構成する必要があります (HTTP の場合は 80、HTTPS の場合は 443 など)。A well-known static port should be configured in the Endpoints configuration of ServiceManifest.xml, such as 80 for HTTP or 443 for HTTPS.
ServiceFabricIntegrationOptionsServiceFabricIntegrationOptions なしNone Service Fabric 統合ミドルウェアを構成するときに ServiceFabricIntegrationOptions.None オプションを使用し、サービスによって受信要求で一意の識別子が検証されないようにします。Use the ServiceFabricIntegrationOptions.None option when configuring Service Fabric integration middleware, so that the service doesn't attempt to validate incoming requests for a unique identifier. アプリケーションの外部ユーザーは、ミドルウェアで使用される一意の識別情報を知りません。External users of your application won't know the unique identifying information that the middleware uses.
Instance CountInstance Count -1-1 一般的なユース ケースでは、インスタンス数の設定を -1 に設定する必要があります。In typical use cases, the instance count setting should be set to -1. このようにするのは、ロード バランサーからトラフィックを受信するすべてのノードでインスタンスを使用できるようにするためです。This is done so that an instance is available on all nodes that receive traffic from a load balancer.

外部に公開される複数のサービスで同じノードのセットを共有する場合は、URL パスが一意でありながら安定している HTTP.sys を使用できます。If multiple externally exposed services share the same set of nodes, you can use HTTP.sys with a unique but stable URL path. これは、IWebHost の構成時に提供される URL を変更することで実現できます。You can accomplish this by modifying the URL provided when configuring IWebHost. これは HTTP.sys にのみ適用されることに注意してください。Note that this applies to HTTP.sys only.

new HttpSysCommunicationListener(serviceContext, "ServiceEndpoint", (url, listener) =>
{
    url += "/MyUniqueServicePath";

    return new WebHostBuilder()
        .UseHttpSys()
        ...
        .UseUrls(url)
        .Build();
})

内部専用のステートレス ASP.NET Core サービスInternal-only stateless ASP.NET Core service

クラスター内からのみ呼び出されるステートレス サービスでは、複数のサービス間の協調動作を保証するために、一意の URL と動的に割り当てられたポートを使用する必要があります。Stateless services that are only called from within the cluster should use unique URLs and dynamically assigned ports to ensure cooperation between multiple services. 次の構成をお勧めします。We recommend the following configuration:

メモNotes
Web サーバーWeb server KestrelKestrel 内部のステートレス サービスに HTTP.sys を使用することもできますが、サーバーで複数のサービス インスタンスがホストを共有できるようにするには、Kestrel が推奨されます。Although you can use HTTP.sys for internal stateless services, Kestrel is the best server to allow multiple service instances to share a host.
ポート構成Port configuration 動的割り当てdynamically assigned ステートフル サービスの複数のレプリカでは、ホスト プロセスまたはホスト オペレーティング システムを共有できるため、一意のポートが必要になります。Multiple replicas of a stateful service might share a host process or host operating system and thus will need unique ports.
ServiceFabricIntegrationOptionsServiceFabricIntegrationOptions UseUniqueServiceUrlUseUniqueServiceUrl 動的なポート割り当てでこの設定を行うことにより、前述の誤った ID に関する問題を防ぐことができます。With dynamic port assignment, this setting prevents the mistaken identity issue described earlier.
InstanceCountInstanceCount 任意any インスタンス数の設定は、サービスの実行に必要な任意の値に設定することができます。The instance count setting can be set to any value necessary to operate the service.

内部専用のステートフル ASP.NET Core サービスInternal-only stateful ASP.NET Core service

クラスター内からのみ呼び出されるステートフル サービスでは、複数のサービス間の協調動作を保証するために、動的に割り当てられたポートを使用する必要があります。Stateful services that are only called from within the cluster should use dynamically assigned ports to ensure cooperation between multiple services. 次の構成をお勧めします。We recommend the following configuration:

メモNotes
Web サーバーWeb server KestrelKestrel HttpSysCommunicationListener は、レプリカがホスト プロセスを共有するステートフル サービス向けに設計されていません。The HttpSysCommunicationListener isn't designed for use by stateful services in which replicas share a host process.
ポート構成Port configuration 動的割り当てdynamically assigned ステートフル サービスの複数のレプリカでは、ホスト プロセスまたはホスト オペレーティング システムを共有できるため、一意のポートが必要になります。Multiple replicas of a stateful service might share a host process or host operating system and thus will need unique ports.
ServiceFabricIntegrationOptionsServiceFabricIntegrationOptions UseUniqueServiceUrlUseUniqueServiceUrl 動的なポート割り当てでこの設定を行うことにより、前述の誤った ID に関する問題を防ぐことができます。With dynamic port assignment, this setting prevents the mistaken identity issue described earlier.

次の手順Next steps

Visual Studio による Service Fabric アプリケーションのデバッグDebug your Service Fabric application by using Visual Studio