Grundlegendes zur ImageStoreConnectionString-Einstellung
In einigen Teilen unserer Dokumentation erwähnen wir kurz den Parameter „ImageStoreConnectionString“, ohne zu beschreiben, was es damit auf sich hat. Artikel wie Bereitstellen und Entfernen von Anwendungen mit PowerShell vermitteln den Eindruck, dass Sie lediglich den im Clustermanifest des Zielclusters angezeigten Wert kopieren/einfügen. Die Einstellung muss also pro Cluster konfigurierbar sein, aber bei der Erstellung eines Clusters über das Azure-Portal gibt es keine Option zum Konfigurieren dieser Einstellung, und sie lautet immer „fabric:ImageStore“. Wo liegt also der Zweck dieser Einstellung?
Service Fabric begann als Plattform für den Microsoft-internen Gebrauch durch vielen verschiedene Teams, daher sind einige Aspekte extrem anpassbar – der „Imagespeicher“ ist ein solcher Aspekt. Im Wesentlichen ist der Imagespeicher ein austauschbares Repository zum Speichern von Anwendungspaketen. Wenn Ihre Anwendung für einen Knoten im Cluster bereitgestellt wird, lädt der jeweilige Knoten den Inhalt des Anwendungspakets aus dem Imagespeicher herunter. ImageStoreConnectionString ist eine Einstellung, die alle erforderlichen Informationen enthält, damit sowohl Clients als auch Knoten den richtigen Imagespeicher für einen bestimmten Cluster finden können.
Es gibt derzeit drei möglichen Arten von Imagespeicheranbietern, und ihre entsprechenden Verbindungszeichenfolgen lauten wie folgt:
Imagespeicherdienst: „fabric:ImageStore“
Dateisystem: „file:[file system path]“
Azure Storage: „xstore:DefaultEndpointsProtocol=https;AccountName=[...];AccountKey=[...];Container=[...]“
Der in der Produktion verwendete Anbietertyp ist der Imagespeicherdienst. Dabei handelt es sich um einen zustandsbehafteten persistenten Systemdienst, der Ihnen im Service Fabric Explorer angezeigt wird.
Durch das Hosten des Imagespeichers in einem Systemdienst innerhalb des Clusters selbst entfallen externe Abhängigkeiten für das Paketrepository, und wir erhalten mehr Kontrolle über den Speicherort. Künftige Verbesserungen rund um den Imagespeicher werden wahrscheinlich in erster Linie – wenn nicht ausschließlich – den Imagespeicheranbieter betreffen. Die Verbindungszeichenfolge für den Anbieter des Imagespeicherdiensts enthält keine eindeutigen Informationen, da der Client bereits mit dem Zielcluster verbunden ist. Dem Client muss nur bekannt sein, dass Protokolle für den Systemdienst verwendet werden müssen.
Der Dateisystemanbieter wird während der Entwicklung anstelle des Imagespeicherdiensts für lokale One-Box-Cluster verwendet, um den Cluster etwas schneller zu starten. Der Unterschied ist in der Regel gering, aber für die meisten Entwickler eine nützliche Optimierung. Es ist auch mit den anderen Speicheranbietertypen möglich, einen lokalen One-Box-Cluster bereitzustellen, aber dazu besteht normalerweise kein Grund, weil der Entwicklungs-/Testworkflow unabhängig vom Anbieter gleich bleibt. Der Azure Storage-Anbieter ist nur für die Unterstützung alter Cluster bestimmt, die vor der Einführung des Imagespeicher-Dienstanbieters bereitgestellt wurden.
Darüber hinaus sollte weder der Dateisystemanbieter noch der Azure Storage-Anbieter als Methode für die gemeinsame Verwendung eines Imagespeichers durch mehrere Cluster verwendet werden – dies führt zu einer Beschädigung der Clusterkonfigurationsdaten, da die einzelnen Cluster widersprüchliche Daten in den Imagespeicher schreiben können. Verwenden Sie zum Freigeben von bereitgestellten Anwendungspaketen zwischen mehreren Clustern stattdessen SFPKG-Dateien. Diese können in beliebige externe Speicher mit einem Download-URI hochgeladen werden.
„ImageStoreConnectionString“ ist zwar konfigurierbar, Sie verwenden jedoch einfach die Standardeinstellung. Beim Veröffentlichen in Azure mithilfe von Visual Studio wird der Parameter automatisch entsprechend für Sie festgelegt. Für die programmgesteuerte Bereitstellung für in Azure gehostete Cluster lautet die Verbindungszeichenfolge immer „fabric:ImageStore“. Im Zweifelsfall kann ihr Wert jedoch immer durch das Abrufen des Clustermanifests über PowerShell, .NET oder REST überprüft werden. Sowohl lokale Test- als auch Produktionscluster sollten immer auch für die Verwendung des Anbieters für den Imagespeicherdienst konfiguriert werden.