Packen und Bereitstellen einer vorhandenen ausführbaren Datei für Service Fabric

Artikel
06/01/2023

Beim Packen einer vorhandenen ausführbaren Datei als ausführbare Gastanwendungsdatei können Sie wählen, ob Sie eine Visual Studio-Projektvorlage verwenden oder das Anwendungspaket manuell erstellen. Mit Visual Studio werden die Anwendungspaketstruktur und Manifestdateien mit der neuen Projektvorlage für Sie erstellt.

Tipp

Der einfachste Weg zum Verpacken einer vorhandenen ausführbaren Windows-Datei in einen Dienst ist die Verwendung von Visual Studio unter Windows und von Yeoman unter Linux.

Verwenden von Visual Studio zum Verpacken und Bereitstellen einer vorhandenen ausführbaren Datei

In Visual Studio wird eine Service Fabric-Dienstvorlage bereitgestellt, um Sie beim Bereitstellen einer ausführbaren Gastanwendung für einen Service Fabric-Cluster zu unterstützen.

Wählen Sie Datei>Neues Projekt, und erstellen Sie eine Service Fabric-Anwendung.
Wählen Sie als Dienstvorlage die Option Guest Executable (Ausführbare Gastdatei).
Klicken Sie auf Durchsuchen, um den Ordner mit der ausführbaren Datei auszuwählen, und geben Sie die restlichen Parameter an, um den Dienst zu erstellen.
- Codepaketverhalten: Sie können das Codepaketverhalten so festlegen, dass der gesamte Inhalt Ihres Ordners in das Visual Studio-Projekt kopiert wird. Dies ist hilfreich, wenn sich die ausführbare Datei nicht ändert. Wenn Sie erwarten, dass sich die ausführbare Datei ändert, und neue Builds dynamisch übernehmen möchten, können Sie stattdessen auch einen Link zum Ordner angeben. Sie können einen verknüpfte Ordner verwenden, wenn Sie das Anwendungsprojekt in Visual Studio erstellen. Im Projekt wird ein Link zum Quellspeicherort erstellt, damit Sie die ausführbare Gastanwendungsdatei an der Quelle aktualisieren können. Diese Updates werden beim Buildvorgang Teil des Anwendungspakets.
- Program: Gibt die ausführbare Datei an, die zum Starten des Diensts ausgeführt werden soll.
- Arguments: Gibt die Argumente an, die an die ausführbare Datei übergeben werden sollen. Dies kann eine Liste von Parametern mit Argumenten sein.
- WorkingFolder: Gibt das Arbeitsverzeichnis für den Prozess an, der gestartet werden soll. Sie können drei Werte angeben:
  - CodeBase gibt an, dass das Arbeitsverzeichnis auf das Verzeichnis „code“ im Anwendungspaket festgelegt wird (das Verzeichnis Code in der obigen Dateistruktur).
  - CodePackage gibt an, dass das Arbeitsverzeichnis auf das Stammverzeichnis des Anwendungspakets festgelegt wird (GuestService1Pkg in der obigen Dateistruktur).
  - Work gibt an, dass die Dateien in einem Unterverzeichnis mit dem Namen „work“ angeordnet werden.
Geben Sie dem Dienst einen Namen, und klicken Sie auf OK.
Wenn der Dienst einen Endpunkt für die Kommunikation benötigt, können Sie das Protokoll, den Port und den Typ der Datei „ServiceManifest.xml“ hinzufügen. Beispiel: <Endpoint Name="NodeAppTypeEndpoint" Protocol="http" Port="3000" UriScheme="http" PathSuffix="myapp/" Type="Input" />.
Sie können die Aktion zum Packen und Veröffentlichen jetzt für Ihren lokalen Cluster verwenden, indem Sie die Projektmappe in Visual Studio debuggen. Wenn Sie bereit sind, können Sie die Anwendung in einem Remotecluster veröffentlichen oder die Projektmappe in die Quellcodeverwaltung einchecken.
Lesen Sie Überprüfen der ausgeführten Anwendung, um zu erfahren, wie Sie die ausführbare Gastdatei für den Dienst anzeigen, der im Service Fabric Explorer ausgeführt wird.

Eine exemplarische Vorgehensweise finden Sie im Artikel zum Thema Erstellen Ihrer ersten ausführbaren Gastdateianwendung mit Visual Studio.

Packeterstellung mehrerer ausführbarer Dateien mit Visual Studio

Sie können Visual Studio verwenden, um ein Anwendungspaket mit mehreren ausführbaren Gastanwendungsdateien zu generieren. Klicken Sie nach dem Hinzufügen der ersten ausführbaren Gastanwendungsdatei mit der rechten Maustaste auf das Anwendungsprojekt und dann auf Hinzufügen > Neuer Service Fabric-Dienst, um der Projektmappe das zweite ausführbare Gastanwendungsprojekt hinzuzufügen.

Hinweis

Wenn Sie die Quelle im Visual Studio-Projekt verknüpfen und die Visual Studio-Projektmappe erstellen, wird Ihr Anwendungspaket mit den Änderungen in der Quelle aktualisiert.

Verwenden von Yeoman zum Verpacken und Bereitstellen einer vorhandenen ausführbaren Datei unter Linux

Zum Erstellen und Bereitstellen einer ausführbaren Gastanwendungsdatei unter Linux wird das gleiche Verfahren verwendet wie beim Bereitstellen einer C#- oder Java-Anwendung.

Geben Sie in einem Terminal yo azuresfguest ein.
Benennen Sie Ihre Anwendung.
Benennen Sie den Dienst, und geben Sie die Details der ausführbaren Datei an, einschließlich der Parameter, mit denen sie aufgerufen werden muss.

Yeoman erstellt ein Anwendungspaket mit der entsprechenden Anwendung und den Manifestdateien sowie ein Installations- und ein Deinstallationsskript.

Paketerstellung mehrerer ausführbarer Dateien mit Yeoman unter Linux

Führen Sie zum Hinzufügen eines weiteren Diensts zu einer Anwendung, die bereits mit yo erstellt wurde, die folgenden Schritte aus:

Legen Sie das Verzeichnis auf den Stamm der vorhandenen Anwendung fest. Beispiel: cd ~/YeomanSamples/MyApplication, wenn MyApplication die von Yeoman erstellte Anwendung ist.
Führen Sie yo azuresfguest:AddService aus, und geben Sie die erforderlichen Informationen an.

Manuelles Packen und Bereitstellen einer vorhandenen ausführbaren Datei

Der Vorgang zum manuellen Packen einer ausführbaren Gastanwendungsdatei basiert auf den folgenden allgemeinen Schritten:

Erstellen der Verzeichnisstruktur des Pakets.
Hinzufügen von Anwendungscode und Konfigurationsdateien.
Bearbeiten der Dienstmanifestdatei
Bearbeiten der Anwendungsmanifestdatei.

Erstellen der Verzeichnisstruktur des Pakets

Sie können zunächst die Verzeichnisstruktur wie in Packen einer Anwendung beschrieben erstellen.

Hinzufügen von Anwendungscode und Konfigurationsdateien

Nachdem Sie die Verzeichnisstruktur erstellt haben, können Sie den Anwendungscode und die Konfigurationsdateien den Verzeichnissen „code“ und „config“ hinzufügen. In den Verzeichnissen „code“ und „config“ können Sie auch weitere Verzeichnisse bzw. Unterverzeichnisse erstellen.

Service Fabric führt einen xcopy-Vorgang für den Inhalt des Stammverzeichnisses der Anwendung aus. Mit Ausnahme der Erstellung der beiden übergeordneten Verzeichnisse „code“ und „settings“ gibt es also keine vordefinierte Struktur, die verwendet werden muss. (Sie können auch andere Namen verwenden. Weitere Informationen finden Sie im nächsten Abschnitt.)

Hinweis

Stellen Sie sicher, dass Sie alle Dateien und Abhängigkeiten einbeziehen, die für die Anwendung erforderlich sind. Service Fabric kopiert den Inhalt des Anwendungspakets auf alle Knoten im Cluster, auf denen die Anwendungsdienste bereitgestellt werden sollen. Das Paket muss den gesamten Code enthalten, den die Anwendung zur Ausführung benötigt. Gehen Sie nicht davon aus, dass die Abhängigkeiten bereits installiert sind.

Bearbeiten der Dienstmanifestdatei

Im nächsten Schritt wird die Dienstmanifestdatei so bearbeitet, dass sie folgende Informationen enthält:

Den Namen des Diensttyps. Dies ist eine ID, die von Service Fabric zum Identifizieren eines Diensts verwendet wird.
Den Befehl zum Starten der Anwendung (ExeHost).
Alle Skripts, die ausgeführt werden müssen, um die Anwendung einzurichten (SetupEntryPoint).

Es folgt ein Beispiel für die Datei ServiceManifest.xml :

<?xml version="1.0" encoding="utf-8"?>
<ServiceManifest xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" Name="NodeApp" Version="1.0.0.0" xmlns="http://schemas.microsoft.com/2011/01/fabric">
   <ServiceTypes>
      <StatelessServiceType ServiceTypeName="NodeApp" UseImplicitHost="true"/>
   </ServiceTypes>
   <CodePackage Name="code" Version="1.0.0.0">
      <SetupEntryPoint>
         <ExeHost>
             <Program>scripts\launchConfig.cmd</Program>
         </ExeHost>
      </SetupEntryPoint>
      <EntryPoint>
         <ExeHost>
            <Program>node.exe</Program>
            <Arguments>bin/www</Arguments>
            <WorkingFolder>CodePackage</WorkingFolder>
         </ExeHost>
      </EntryPoint>
   </CodePackage>
   <Resources>
      <Endpoints>
         <Endpoint Name="NodeAppTypeEndpoint" Protocol="http" Port="3000" Type="Input" />
      </Endpoints>
   </Resources>
</ServiceManifest>

In den folgenden Abschnitten geht es um die anderen Teile der Datei, die Sie aktualisieren müssen.

Aktualisieren von ServiceTypes

<ServiceTypes>
  <StatelessServiceType ServiceTypeName="NodeApp" UseImplicitHost="true" />
</ServiceTypes>

Sie können für ServiceTypeNameeinen beliebigen Namen auswählen. Der Wert wird in der Datei ApplicationManifest.xml zum Identifizieren des Diensts verwendet.
Geben Sie UseImplicitHost="true" an. Dieses Attribut informiert Service Fabric, dass der Dienst auf einer eigenständigen Anwendung beruht. Service Fabric muss ihn also lediglich als Prozess starten und seine Integrität überwachen.

Aktualisieren von CodePackage

Das Element „CodePackage“ gibt den Speicherort (und die Version) des Dienstcodes an.

<CodePackage Name="Code" Version="1.0.0.0">

Das Element Name wird verwendet, um den Namen des Verzeichnisses im Anwendungspaket anzugeben, das den Dienstcode enthält. CodePackage weist auch das version-Attribut auf. Es kann verwendet werden, um die Version des Codes anzugeben. Außerdem kann es dazu genutzt werden, den Dienstcode mithilfe der Infrastruktur für die Anwendungslebenszyklusverwaltung in Service Fabric zu aktualisieren.

Optional: Aktualisieren von SetupEntrypoint

<SetupEntryPoint>
   <ExeHost>
       <Program>scripts\launchConfig.cmd</Program>
   </ExeHost>
</SetupEntryPoint>

Der Element „SetupEntryPoint“ wird verwendet, um eine ausführbare Datei oder eine Batchdatei anzugeben, die vor dem Starten des Dienstcodes ausgeführt werden soll. Dies ist ein optionaler Schritt, der nicht angegeben werden muss, wenn keine Initialisierung erforderlich ist. Der „SetupEntryPoint“ wird bei jedem Neustart des Diensts ausgeführt.

Es gibt nur ein Element „SetupEntryPoint“. Daher müssen Setupskripts in einer Batchdatei gruppiert werden, wenn für das Setup der Anwendung mehrere Skripts erforderlich sind. Das Element „SetupEntryPoint“ kann jeden beliebigen Dateityp ausführen: ausführbare Dateien, Batchdateien und PowerShell-Cmdlets. Weitere Informationen finden Sie unter Konfigurieren von SetupEntryPoint.

Im obigen Beispiel führt „SetupEntryPoint“ eine Batchdatei mit dem Namen LaunchConfig.cmd aus, die sich im Unterverzeichnis scripts des Codeverzeichnisses befindet (vorausgesetzt, das WorkingFolder-Element ist auf „CodeBase“ festgelegt).

Aktualisieren von EntryPoint

<EntryPoint>
  <ExeHost>
    <Program>node.exe</Program>
    <Arguments>bin/www</Arguments>
    <WorkingFolder>CodeBase</WorkingFolder>
  </ExeHost>
</EntryPoint>

Mit dem Element EntryPoint in der Dienstmanifestdatei wird angegeben, wie der Dienst gestartet werden soll.

Das Element ExeHost gibt die ausführbare Datei (und die Argumente) an, die zum Starten des Diensts verwendet werden soll. Sie können optional das Attribut IsExternalExecutable="true" zu ExeHost hinzufügen, um anzugeben, dass das Programm eine externe ausführbare Datei außerhalb des Codepakets ist. Beispiel: <ExeHost IsExternalExecutable="true">.

Program gibt den Namen der ausführbaren Datei an, die zum Starten des Diensts verwendet werden soll.
Arguments gibt die Argumente an, die an die ausführbare Datei übergeben werden sollen. Dies kann eine Liste von Parametern mit Argumenten sein.
WorkingFolder gibt das Arbeitsverzeichnis für den Prozess an, der gestartet werden soll. Sie können drei Werte angeben:
- CodeBase gibt an, dass das Arbeitsverzeichnis auf das Verzeichnis „code“ im Anwendungspaket festgelegt wird (das Verzeichnis Code in der obigen Dateistruktur).
- CodePackage gibt an, dass das Arbeitsverzeichnis auf das Stammverzeichnis des Anwendungspakets festgelegt wird (GuestService1Pkg in der obigen Dateistruktur).
  - Work gibt an, dass die Dateien in einem Unterverzeichnis mit dem Namen „work“ angeordnet werden.

WorkingFolder ist nützlich, um das richtige Arbeitsverzeichnis festzulegen, damit von der Anwendung oder von Initialisierungsskripts relative Pfade verwendet werden können.

Aktualisieren der Endpunkte und Registrieren beim Naming Service für die Kommunikation

<Endpoints>
   <Endpoint Name="NodeAppTypeEndpoint" Protocol="http" Port="3000" Type="Input" />
</Endpoints>

Im vorherigen Beispiel werden mit dem Endpoint-Element die Endpunkte angegeben, über die die Anwendung lauschen kann. In diesem Beispiel lauscht die Node.js-Anwendung über Port 3000 (HTTP).

Außerdem können Sie angeben, dass Service Fabric diesen Endpunkt für den Naming Service veröffentlicht, damit andere Dienste die Endpunktadresse für diesen Dienst ermitteln können. Dies ermöglicht Ihnen die Kommunikation zwischen Diensten, bei denen es sich um ausführbare Gastanwendungsdateien handelt. Die veröffentlichte Endpunktadresse hat das Format UriScheme://IPAddressOrFQDN:Port/PathSuffix. UriScheme und PathSuffix sind optionale Attribute. IPAddressOrFQDN ist die IP-Adresse oder der vollqualifizierte Domänenname des Knotens, auf dem die ausführbare Datei angeordnet wird. Dieser Wert wird für Sie berechnet.

Im folgenden Beispiel sehen Sie nach der Bereitstellung des Diensts im Service Fabric Explorer einen Endpunkt, der in etwa http://10.1.4.92:3000/myapp/ lautet und für die Dienstinstanz veröffentlicht wird. Falls es sich um einen lokalen Computer handelt, wird http://localhost:3000/myapp/ angezeigt.

<Endpoints>
   <Endpoint Name="NodeAppTypeEndpoint" Protocol="http" Port="3000"  UriScheme="http" PathSuffix="myapp/" Type="Input" />
</Endpoints>

Sie können diese Adressen mit dem Reverseproxy verwenden, um zwischen den Diensten zu kommunizieren.

Bearbeiten der Anwendungsmanifestdatei

Nach der Konfiguration der Datei Servicemanifest.xml müssen Sie einige Änderungen an der Datei ApplicationManifest.xml vornehmen, um sicherzustellen, dass der richtige Diensttyp und der richtige Name verwendet werden.

<?xml version="1.0" encoding="utf-8"?>
<ApplicationManifest xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" ApplicationTypeName="NodeAppType" ApplicationTypeVersion="1.0" xmlns="http://schemas.microsoft.com/2011/01/fabric">
   <ServiceManifestImport>
      <ServiceManifestRef ServiceManifestName="NodeApp" ServiceManifestVersion="1.0.0.0" />
   </ServiceManifestImport>
</ApplicationManifest>

ServiceManifestImport

Im Element ServiceManifestImport können Sie einen oder mehrere Dienste angeben, die in der Anwendung enthalten sein sollen. ServiceManifestName verweist auf die Dienste. Dieses Element gibt den Namen des Verzeichnisses an, in dem sich die Datei ServiceManifest.xml befindet.

<ServiceManifestImport>
  <ServiceManifestRef ServiceManifestName="NodeApp" ServiceManifestVersion="1.0.0.0" />
</ServiceManifestImport>

Einrichten der Protokollierung

Bei ausführbaren Gastanwendungsdateien ist es nützlich, Konsolenprotokolle anzeigen zu können, um festzustellen, ob die Anwendungs- und Konfigurationsskripts Fehler aufweisen. In der Datei ServiceManifest.xml kann mit dem Element ConsoleRedirection eine Konsolenumleitung konfiguriert werden.

Warnung

Verwenden Sie die Richtlinie zur Konsolenumleitung nie in einer Anwendung, die in der Produktionsumgebung bereitgestellt wurde, da sich dies auf das Anwendungsfailover auswirken kann. Verwenden Sie diese nur für die lokale Entwicklung und das Debuggen.

<EntryPoint>
  <ExeHost>
    <Program>node.exe</Program>
    <Arguments>bin/www</Arguments>
    <WorkingFolder>CodeBase</WorkingFolder>
    <ConsoleRedirection FileRetentionCount="5" FileMaxSizeInKb="2048"/>
  </ExeHost>
</EntryPoint>

ConsoleRedirection kann verwendet werden, um die Konsolenausgabe (sowohl stdout als auch stderr) in ein Arbeitsverzeichnis umzuleiten. So kann per Überprüfung sichergestellt werden, dass während des Setups oder der Ausführung der Anwendung im Service Fabric-Cluster keine Fehler auftreten.

FileRetentionCount legt fest, wie viele Dateien im Arbeitsverzeichnis gespeichert werden. Der Wert 5 bedeutet beispielsweise, dass die Protokolldateien für die letzten fünf Ausführungsvorgänge im Arbeitsverzeichnis gespeichert werden.

FileMaxSizeInKb gibt die maximale Größe der Protokolldateien an.

Protokolldateien werden in einem der Arbeitsverzeichnisse des Diensts gespeichert. Verwenden Sie den Service Fabric Explorer, um zu bestimmen, wo sich die Dateien befinden. Damit können Sie ermitteln, auf welchem Knoten der Dienst ausgeführt wird und welches Arbeitsverzeichnis verwendet wird. Dieser Vorgang wird weiter unten in diesem Artikel erläutert.

Bereitstellung

Der letzte Schritt ist das Bereitstellen der Anwendung. Das folgende PowerShell-Skript veranschaulicht, wie Sie die Anwendung im lokalen Entwicklungscluster bereitstellen und einen neuen Service Fabric-Dienst starten.


Connect-ServiceFabricCluster localhost:19000

Write-Host 'Copying application package...'
Copy-ServiceFabricApplicationPackage -ApplicationPackagePath 'C:\Dev\MultipleApplications' -ImageStoreConnectionString 'file:C:\SfDevCluster\Data\ImageStoreShare' -ApplicationPackagePathInImageStore 'nodeapp'

Write-Host 'Registering application type...'
Register-ServiceFabricApplicationType -ApplicationPathInImageStore 'nodeapp'

New-ServiceFabricApplication -ApplicationName 'fabric:/nodeapp' -ApplicationTypeName 'NodeAppType' -ApplicationTypeVersion 1.0

New-ServiceFabricService -ApplicationName 'fabric:/nodeapp' -ServiceName 'fabric:/nodeapp/nodeappservice' -ServiceTypeName 'NodeApp' -Stateless -PartitionSchemeSingleton -InstanceCount 1

Tipp

Komprimieren Sie das Paket vor dem Kopieren in den Imagespeicher, wenn das Paket sehr groß ist oder viele Dateien enthält. Weitere Informationen finden Sie hier.

Ein Service Fabric-Dienst kann mit verschiedenen „Konfigurationen“ bereitgestellt werden: als eine Instanz, als mehrere Instanzen oder als eine Instanz des Diensts auf jedem Knoten des Service Fabric-Clusters.

Mit dem InstanceCount-Parameter des Cmdlets New-ServiceFabricService wird angegeben, wie viele Instanzen des Diensts im Service Fabric-Cluster gestartet werden sollen. Sie können den Wert InstanceCount abhängig vom Typ der bereitzustellenden Anwendung festlegen. Die beiden häufigsten Szenarien:

InstanceCount = "1". In diesem Fall wird nur eine Instanz des Diensts im Cluster bereitgestellt. Der Service Fabric-Scheduler bestimmt den Knoten, auf dem der Dienst bereitgestellt werden soll.
InstanceCount ="-1". In diesem Fall wird eine Instanz des Diensts auf jedem Knoten im Service Fabric-Cluster bereitgestellt. Das Ergebnis ist eine (und nur eine) Instanz des Diensts für jeden Knoten im Cluster.

Dies ist eine praktische Konfiguration für Front-End-Anwendungen (z.B. REST-Endpunkte), da Clientanwendungen eine Verbindung mit einem Knoten im Cluster herstellen müssen, um den Endpunkt zu verwenden. Diese Konfiguration kann auch verwendet werden, wenn beispielsweise alle Knoten des Service Fabric-Clusters mit einem Lastenausgleichsmodul verbunden sind. Der Clientdatenverkehr kann dann über den Dienst verteilt werden, der auf allen Knoten im Cluster ausgeführt wird.

Überprüfen der ausgeführten Anwendung

Bestimmen Sie im Service Fabric Explorer den Knoten, auf dem der Dienst ausgeführt wird. In diesem Beispiel ist es „Node1“:

Knoten, auf dem der Dienst ausgeführt wird

Wenn Sie zum Knoten navigieren und zur Anwendung wechseln, sehen Sie die wesentlichen Knoteninformationen, einschließlich des Speicherorts auf dem Datenträger.

Speicherort auf dem Datenträger

Wenn Sie im Server-Explorer zum jeweiligen Verzeichnis wechseln, sehen Sie das Arbeitsverzeichnis und den Protokollordner des Diensts, wie im folgenden Screenshot dargestellt:

Speicherort des Protokolls

Nächste Schritte

In diesem Artikel wurden das Packen einer ausführbaren Gastanwendungsdatei sowie ihre Bereitstellung in Service Fabric beschrieben. Entsprechende Informationen und Aufgaben finden Sie in den folgenden Artikeln.

Beispiel für das Packen und Bereitstellen einer ausführbaren Gastdatei, einschließlich eines Links zur Vorabversion des Packtools
Beispiel für zwei ausführbare Gastdateien (C# und Node.js), die über den Naming Service mithilfe von REST kommunizieren
Erstellen Ihrer ersten Service Fabric-Anwendung in Visual Studio