Om inställningen ImageStoreConnectionString
I en del av vår dokumentation nämner vi kortfattat förekomsten av en "ImageStoreConnectionString"-parameter utan att beskriva vad det egentligen innebär. Och när du har gått igenom en artikel som Distribuera och ta bort program med PowerShell ser det ut som att allt du gör är att kopiera/klistra in värdet som visas i klustermanifestet för målklustret. Så inställningen måste vara konfigurerbar per kluster, men när du skapar ett kluster via Azure-portalen finns det inget alternativ för att konfigurera den här inställningen och det är alltid "fabric:ImageStore". Vad är syftet med den här inställningen då?
Service Fabric började som en plattform för intern Microsoft-förbrukning av många olika team, så vissa aspekter av det är mycket anpassningsbara – "Image Store" är en sådan aspekt. I grund och botten är Image Store en lagringsplats som kan anslutas för lagring av programpaket. När programmet distribueras till en nod i klustret laddar noden ned innehållet i programpaketet från Image Store. ImageStoreConnectionString är en inställning som innehåller all nödvändig information för både klienter och noder för att hitta rätt avbildningslager för ett visst kluster.
Det finns för närvarande tre möjliga typer av Image Store-leverantörer och deras motsvarande niska veze är följande:
Image Store Service: "fabric:ImageStore"
Filsystem: "file:[file system path]"
Azure Storage: "xstore:DefaultEndpointsProtocol=https; AccountName=[...]; AccountKey=[...]; Container=[...]"
Providertypen som används i produktion är Image Store-tjänsten, som är en tillståndskänslig beständig systemtjänst som du kan se från Service Fabric Explorer.
Att vara värd för avbildningsarkivet i en systemtjänst i själva klustret eliminerar externa beroenden för paketlagringsplatsen och ger oss mer kontroll över lagringens plats. Framtida förbättringar runt Image Store kommer sannolikt att riktas mot Image Store-providern först, om inte uteslutande. Niska veze för image store-tjänstleverantören har ingen unik information eftersom klienten redan är ansluten till målklustret. Klienten behöver bara veta att protokoll som riktar sig till systemtjänsten ska användas.
Filsystemprovidern används i stället för image store-tjänsten för lokala one-box-kluster under utvecklingen för att starta klustret något snabbare. Skillnaden är vanligtvis liten, men det är en användbar optimering för de flesta under utvecklingen. Det är möjligt att distribuera ett lokalt one-box-kluster med de andra lagringsprovidertyperna också, men det finns vanligtvis ingen anledning att göra det eftersom arbetsflödet för utveckling/testning förblir detsamma oavsett provider. Azure Storage-providern finns bara för äldre stöd för gamla kluster som distribuerades innan image store-tjänstleverantören introducerades.
Dessutom bör inte filsystemprovidern eller Azure Storage-providern användas som en metod för att dela ett avbildningslager mellan flera kluster. Detta leder till att klusterkonfigurationsdata skadas eftersom varje kluster kan skriva motstridiga data till Image Store. Om du vill dela etablerade programpaket mellan flera kluster använder du sfpkg-filer i stället, som kan laddas upp till valfri extern lagring med en nedladdnings-URI.
Så även om ImageStoreConnectionString kan konfigureras använder du bara standardinställningen. När du publicerar till Azure via Visual Studio anges parametern automatiskt åt dig. För programmatisk distribution till kluster som finns i Azure är niska veze alltid "fabric:ImageStore". Om du är osäker kan dess värde alltid verifieras genom att hämta klustermanifestet av PowerShell, .NET eller REST. Både lokala test- och produktionskluster bör alltid konfigureras för att även använda image store-tjänstleverantören.