ImageStoreConnectionString 設定を理解するUnderstand the ImageStoreConnectionString setting

いくつかのドキュメントで、"ImageStoreConnectionString" パラメーターの存在について、それが何を意味するかの説明なしで、簡単に触れられています。In some of our documentation, we briefly mention the existence of an "ImageStoreConnectionString" parameter without describing what it really means. PowerShell を使用してアプリケーションのデプロイと削除を実行する」などの記事を読み進めると、自分がすることは、ターゲット クラスターのクラスター マニフェストに表示される値をコピー/貼り付けすることだけのように思えます。And after going through an article like Deploy and remove applications using PowerShell, it looks like all you do is copy/paste the value as shown in the cluster manifest of the target cluster. このように、この設定はクラスターごとに構成可能ではありますが、Azure Portal を使用してクラスターを作成する場合はこの設定を構成するというオプションはなく、常に "fabric: ImageStore" が使用されます。So the setting must be configurable per cluster, but when you create a cluster through the Azure portal, there's no option to configure this setting and it's always "fabric:ImageStore". それでは、この設定は何のためにあるのでしょうか。What's the purpose of this setting then?

クラスター マニフェスト

Service Fabric は、マイクロソフトの社内で数多くの多様なチームが使用するためのプラットフォームとして始まったため、いくつかの側面は高度にカスタマイズ可能であり、"イメージ ストア" もそのような側面の 1 つです。Service Fabric started off as a platform for internal Microsoft consumption by many diverse teams, so some aspects of it are highly customizable - the "Image Store" is one such aspect. 本質的に、イメージ ストアは、アプリケーション パッケージを格納するためのプラグ可能なリポジトリです。Essentially, the Image Store is a pluggable repository for storing application packages. アプリケーションがクラスター内のノードにデプロイされると、そのノードは、イメージ ストアからアプリケーション パッケージの内容をダウンロードします。When your application is deployed to a node in the cluster, that node downloads the contents of your application package from the Image Store. ImageStoreConnectionString は、クライアントとノードが、特定のクラスター用の適切なイメージ ストアを検索するために必要なすべての情報を含む設定です。The ImageStoreConnectionString is a setting that includes all the necessary information for both clients and nodes to find the correct Image Store for a given cluster.

現時点では、次の 3 つの可能な種類のイメージ ストア プロバイダーがあり、対応する接続文字列は次のようになります。There are currently three possible kinds of Image Store providers and their corresponding connection strings are as follows:

  1. イメージ ストア サービス: "fabric:ImageStore"Image Store Service: "fabric:ImageStore"

  2. ファイル システム: "file:[ファイルシステムのパス]"File System: "file:[file system path]"

  3. Azure Storage: "xstore:DefaultEndpointsProtocol=https;AccountName=[...];AccountKey=[...];Container=[...]"Azure Storage: "xstore:DefaultEndpointsProtocol=https;AccountName=[...];AccountKey=[...];Container=[...]"

実稼働環境で使用されるプロバイダーの種類は、イメージ ストア サービスです。これは、Service Fabric Explorer で確認できるステートフルな永続化システム サービスです。The provider type used in production is the Image Store Service, which is a stateful persisted system service that you can see from Service Fabric Explorer.

イメージ ストア サービス

システム サービス内のイメージ ストアをクラスター自体の内部でホストすることで、パッケージのリポジトリに関する外部依存関係が排除され、ストレージをもっとローカルに制御することができます。Hosting the Image Store in a system service within the cluster itself eliminates external dependencies for the package repository and gives us more control over the locality of storage. イメージ ストアに関する今後の改善は、まずイメージ ストア プロバイダーを対象とする可能性がありますが、これのみに限定されるわけではありません。Future improvements around the Image Store are likely to target the Image Store provider first, if not exclusively. クライアントは既にターゲット クラスターに接続されているために、イメージ ストア サービス プロバイダーの接続文字列には固有の情報はありません。The connection string for the Image Store Service provider doesn't have any unique information since the client is already connected to the target cluster. クライアントが知る必要があるのは、システム サービスを対象とするプロトコルを使用する必要があることだけです。The client only needs to know that protocols targeting the system service should be used.

ファイル システム プロバイダーは、ローカルのワンボックス クラスターの開発時に、クラスターのブート処理を少しでも速くするためにイメージ ストア サービスの代わりに使用されます。The File System provider is used instead of the Image Store Service for local one-box clusters during development to bootstrap the cluster slightly faster. 通常、その違いは小さいものですが、開発時には有効な最適化です。The difference is typically small, but it's a useful optimization for most folks during development. ローカルのワンボックス クラスターを他の種類のストレージ プロバイダーでデプロイすることもできますが、プロバイダーが何であっても、開発/テスト ワークフローは変わらないため、通常はそうする理由がありません。It's possible to deploy a local one-box cluster with the other storage provider types as well, but there's usually no reason to do so since the develop/test workflow remains the same regardless of provider. Azure Storage プロバイダーは、イメージ ストア サービス プロバイダーがリリースされる前にデプロイされた古いクラスターをサポートする目的でのみ存在します。The Azure Storage provider only exists for legacy support of old clusters deployed before the Image Store Service provider was introduced.

また、ファイル システム プロバイダーも Azure Storage プロバイダーも、複数のクラスター間で 1 つの Image Store を共有する手段として使うことは避けてください。それぞれのクラスターによって Image Store に競合するデータが書き込まれる可能性があるため、クラスターの構成データの破損につながります。Furthermore, not the File System provider or the Azure Storage provider should be used as a method of sharing an Image Store between multiple clusters - this will result in corruption of cluster configuration data as each cluster can write conflicting data to the Image Store. プロビジョニングしたアプリケーション パッケージを複数のクラスター間で共有する場合は、sfpkg ファイルを使用してください。このファイルは、ダウンロード URI で任意の外部ストアにアップロードすることができます。To share provisioned application packages between multiple clusters, use sfpkg files instead, which can be uploaded to any external store with a download URI.

したがって、ImageStoreConnectionString を構成することはできますが、単純に既定の設定を使用します。So while the ImageStoreConnectionString is configurable, you just use the default setting. Visual Studio から Azure に発行する場合、パラメーターは、状況に応じて自動的に設定されます。When publishing to Azure through Visual Studio, the parameter is automatically set for you accordingly. Azure でホストされるクラスターにプログラムでデプロイする場合、接続文字列は常に "fabric:ImageStore" です。For programmatic deployment to clusters hosted in Azure, the connection string is always "fabric:ImageStore". 不確かな場合は、PowerShell.NET、またはREST でクラスター マニフェストを取得することで、その値を常に検証できます。Though when in doubt, its value can always be verified by retrieving the cluster manifest by PowerShell, .NET, or REST. オンプレミス テストと運用クラスターはどちらも、常にイメージ ストア サービス プロバイダーを使用するように構成する必要があります。Both on-premises test and production clusters should always be configured to use the Image Store Service provider as well.

次の手順Next steps

PowerShell を使用してアプリケーションのデプロイと削除を実行するDeploy and remove applications using PowerShell