Dela via


Paketera och distribuera en befintlig körbar fil till Service Fabric

När du paketerar en befintlig körbar fil som körbar gäst kan du välja att antingen använda en Visual Studio-projektmall eller skapa programpaketet manuellt. Med Visual Studio skapas programpaketstrukturen och manifestfilerna av den nya projektmallen åt dig.

Dricks

Det enklaste sättet att paketera en befintlig Körbar Windows-fil i en tjänst är att använda Visual Studio och Linux för att använda Yeoman

Använda Visual Studio för att paketera och distribuera en befintlig körbar fil

Visual Studio tillhandahåller en Service Fabric-tjänstmall som hjälper dig att distribuera en körbar gäst till ett Service Fabric-kluster.

  1. Välj Arkiv>Nytt projekt och skapa ett Service Fabric-program.
  2. Välj Körbar gäst som tjänstmall.
  3. Klicka på Bläddra för att välja mappen med den körbara filen och fyll i resten av parametrarna för att skapa tjänsten.
    • Beteende för kodpaket. Kan ställas in för att kopiera allt innehåll i mappen till Visual Studio Project, vilket är användbart om den körbara filen inte ändras. Om du förväntar dig att den körbara filen ska ändras och vill kunna hämta nya versioner dynamiskt kan du välja att länka till mappen i stället. Du kan använda länkade mappar när du skapar programprojektet i Visual Studio. Detta länkar till källplatsen inifrån projektet, vilket gör det möjligt för dig att uppdatera den körbara gästen i källmålet. Dessa uppdateringar blir en del av programpaketet som byggs.
    • Programmet anger den körbara fil som ska köras för att starta tjänsten.
    • Argument anger de argument som ska skickas till den körbara filen. Det kan vara en lista med parametrar med argument.
    • WorkingFolder anger arbetskatalogen för den process som ska startas. Du kan ange tre värden:
      • CodeBase anger att arbetskatalogen ska anges till kodkatalogen i programpaketet (Code katalogen som visas i föregående filstruktur).
      • CodePackage anger att arbetskatalogen ska anges till roten för programpaketet (GuestService1Pkg som visas i föregående filstruktur).
      • Work anger att filerna placeras i en underkatalog som kallas arbete.
  4. Namnge tjänsten och klicka på OK.
  5. Om tjänsten behöver en slutpunkt för kommunikation kan du nu lägga till protokollet, porten och typen i filen ServiceManifest.xml. Exempel: <Endpoint Name="NodeAppTypeEndpoint" Protocol="http" Port="3000" UriScheme="http" PathSuffix="myapp/" Type="Input" />.
  6. Nu kan du använda paketet och publicera åtgärden mot ditt lokala kluster genom att felsöka lösningen i Visual Studio. När du är klar kan du publicera programmet till ett fjärrkluster eller checka in lösningen på källkontrollen.
  7. Läs kontrollera ditt program som körs för att se hur du visar din körbara gästtjänst som körs i Service Fabric Explorer.

En exempelgenomgång finns i Skapa ditt första körbara gästprogram med Visual Studio.

Paketera flera körbara filer med Visual Studio

Du kan använda Visual Studio för att skapa ett programpaket som innehåller flera körbara gästprogram. När du har lagt till den första körbara gästen högerklickar du på programprojektet och väljer Tjänsten Lägg till> ny Service Fabric för att lägga till det andra körbara gästprojektet i lösningen.

Kommentar

Om du väljer att länka källan i Visual Studio-projektet och skapar Visual Studio-lösningen ser du till att programpaketet är uppdaterat med ändringar i källan.

Använda Yeoman för att paketera och distribuera en befintlig körbar fil i Linux

Proceduren för att skapa och distribuera en körbar gäst i Linux är densamma som att distribuera ett C#- eller Java-program.

  1. I en terminal, skriver du in yo azuresfguest.
  2. Namnge ditt program.
  3. Namnge din tjänst och ange information, inklusive sökvägen för den körbara filen och de parametrar som den måste anropas med.

Yeoman skapar ett programpaket med lämpliga program- och manifestfiler tillsammans med installations- och avinstallationsskript.

Paketera flera körbara filer med Yeoman i Linux

Om du vill lägga till en till tjänst till ett program som redan har skapats med hjälp av yo utför du följande steg:

  1. Ändra katalogen till roten för det befintliga programmet. Till exempel cd ~/YeomanSamples/MyApplication om MyApplication är programmet som skapats av Yeoman.
  2. Kör yo azuresfguest:AddService och ange nödvändig information.

Paketera och distribuera en befintlig körbar fil manuellt

Processen för att manuellt paketera en körbar gäst baseras på följande allmänna steg:

  1. Skapa paketkatalogstrukturen.
  2. Lägg till programmets kod- och konfigurationsfiler.
  3. Redigera tjänstmanifestfilen.
  4. Redigera programmanifestfilen.

Skapa paketkatalogstrukturen

Du kan börja med att skapa katalogstrukturen enligt beskrivningen i Paketera en Azure Service Fabric-app.

Lägg till programmets kod- och konfigurationsfiler

När du har skapat katalogstrukturen kan du lägga till programmets kod- och konfigurationsfiler under kod- och konfigurationskatalogerna. Du kan också skapa ytterligare kataloger eller underkataloger under koden eller konfigurationskatalogerna.

Service Fabric gör en xcopy av innehållet i programmets rotkatalog, så det finns ingen fördefinierad struktur att använda förutom att skapa två toppkataloger, kod och inställningar. (Du kan välja olika namn om du vill. Mer information finns i nästa avsnitt.)

Kommentar

Se till att du inkluderar alla filer och beroenden som programmet behöver. Service Fabric kopierar innehållet i programpaketet på alla noder i klustret där programmets tjänster ska distribueras. Paketet ska innehålla all kod som programmet behöver köra. Anta inte att beroendena redan är installerade.

Redigera tjänstmanifestfilen

Nästa steg är att redigera tjänstmanifestfilen så att den innehåller följande information:

  • Namnet på tjänsttypen. Det här är ett ID som Service Fabric använder för att identifiera en tjänst.
  • Kommandot som ska användas för att starta programmet (ExeHost).
  • Alla skript som måste köras för att konfigurera programmet (SetupEntrypoint).

Följande är ett exempel på en ServiceManifest.xml fil:

<?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>

Följande avsnitt går över de olika delarna av filen som du behöver uppdatera.

Uppdatera ServiceTypes

<ServiceTypes>
  <StatelessServiceType ServiceTypeName="NodeApp" UseImplicitHost="true" />
</ServiceTypes>
  • Du kan välja valfritt namn som du vill för ServiceTypeName. Värdet används i ApplicationManifest.xml filen för att identifiera tjänsten.
  • Ange UseImplicitHost="true". Det här attributet anger för Service Fabric att tjänsten baseras på en fristående app, så allt Service Fabric behöver göra är att starta den som en process och övervaka dess hälsa.

Uppdatera CodePackage

CodePackage-elementet anger platsen (och versionen) för tjänstens kod.

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

Elementet Name används för att ange namnet på katalogen i programpaketet som innehåller tjänstens kod. CodePackage har också attributet version . Detta kan användas för att ange kodens version och kan även användas för att uppgradera tjänstens kod med hjälp av infrastrukturen för programlivscykelhantering i Service Fabric.

Valfritt: Uppdatera installationsprogrammetFörsökspunkt

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

Elementet SetupEntryPoint används för att ange alla körbara filer eller batchfiler som ska köras innan tjänstens kod startas. Det är ett valfritt steg, så det behöver inte inkluderas om det inte krävs någon initiering. SetupEntryPoint körs varje gång tjänsten startas om.

Det finns bara en SetupEntryPoint, så installationsskript måste grupperas i en enda batchfil om programmets installation kräver flera skript. SetupEntryPoint kan köra alla typer av filer: körbara filer, batchfiler och PowerShell-cmdletar. Mer information finns i Konfigurera setupEntryPoint.

I föregående exempel kör SetupEntryPoint en batchfil med namnet LaunchConfig.cmd som finns i underkatalogen scripts för kodkatalogen (förutsatt att WorkingFolder-elementet är inställt på CodeBase).

Uppdatera EntryPoint

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

Elementet EntryPoint i tjänstmanifestfilen används för att ange hur tjänsten ska startas.

Elementet ExeHost anger de körbara (och argument) som ska användas för att starta tjänsten. Du kan också lägga till IsExternalExecutable="true" attributet för ExeHost att ange att programmet är en extern körbar fil utanför kodpaketet. Exempel: <ExeHost IsExternalExecutable="true">

  • Program anger namnet på den körbara fil som ska starta tjänsten.
  • Arguments anger de argument som ska skickas till den körbara filen. Det kan vara en lista med parametrar med argument.
  • WorkingFolder anger arbetskatalogen för den process som ska startas. Du kan ange tre värden:
    • CodeBase anger att arbetskatalogen ska anges till kodkatalogen i programpaketet (Code katalog i föregående filstruktur).
    • CodePackage anger att arbetskatalogen ska anges till roten för programpaketet (GuestService1Pkg i föregående filstruktur).
      • Work anger att filerna placeras i en underkatalog som kallas arbete.

WorkingFolder är användbart för att ange rätt arbetskatalog så att relativa sökvägar kan användas av antingen program- eller initieringsskripten.

Uppdatera slutpunkter och registrera med namngivningstjänsten för kommunikation

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

I föregående exempel anger elementet Endpoint de slutpunkter som programmet kan lyssna på. I det här exemplet lyssnar Node.js-programmet på http på port 3000.

Dessutom kan du be Service Fabric att publicera den här slutpunkten till namngivningstjänsten så att andra tjänster kan identifiera slutpunktsadressen till den här tjänsten. På så sätt kan du kommunicera mellan tjänster som är körbara gästtjänster. Den publicerade slutpunktsadressen är av formuläret UriScheme://IPAddressOrFQDN:Port/PathSuffix. UriScheme och PathSuffix är valfria attribut. IPAddressOrFQDN är IP-adressen eller det fullständigt kvalificerade domännamnet för noden som den här körbara filen placeras på, och den beräknas åt dig.

I följande exempel, när tjänsten har distribuerats, ser du i Service Fabric Explorer en slutpunkt som liknar http://10.1.4.92:3000/myapp/ publicerad för tjänstinstansen. Eller om det här är en lokal dator visas http://localhost:3000/myapp/.

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

Du kan använda dessa adresser med omvänd proxy för att kommunicera mellan tjänster.

Redigera programmanifestfilen

När du har konfigurerat Servicemanifest.xml filen måste du göra några ändringar i ApplicationManifest.xml filen för att säkerställa att rätt tjänsttyp och namn används.

<?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>

ServiceManifestImportera

I -elementet ServiceManifestImport kan du ange en eller flera tjänster som du vill inkludera i appen. Tjänster refereras till med ServiceManifestName, som anger namnet på den katalog där ServiceManifest.xml filen finns.

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

Konfigurera loggning

För körbara gästfiler är det användbart att kunna se konsolloggar för att ta reda på om programmet och konfigurationsskripten visar några fel. Konsolomdirigering kan konfigureras i ServiceManifest.xml filen med hjälp av -elementet ConsoleRedirection .

Varning

Använd aldrig omdirigeringsprincipen för konsolen i ett program som distribueras i produktion eftersom detta kan påverka programredundansen. Använd endast detta för lokal utveckling och felsökning.

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

ConsoleRedirection kan användas för att omdirigera konsolutdata (både stdout och stderr) till en arbetskatalog. Detta ger möjlighet att kontrollera att det inte finns några fel under installationen eller körningen av programmet i Service Fabric-klustret.

FileRetentionCount avgör hur många filer som sparas i arbetskatalogen. Värdet 5 innebär till exempel att loggfilerna för de föregående fem körningarna lagras i arbetskatalogen.

FileMaxSizeInKb anger den maximala storleken på loggfilerna.

Loggfiler sparas i en av tjänstens arbetskataloger. För att avgöra var filerna finns använder du Service Fabric Explorer för att avgöra vilken nod tjänsten körs på och vilken arbetskatalog som används. Den här processen beskrivs senare i den här artikeln.

Distribution

Det sista steget är att distribuera programmet. Följande PowerShell-skript visar hur du distribuerar ditt program till det lokala utvecklingsklustret och startar en ny Service Fabric-tjänst.


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

Dricks

Komprimera paketet innan du kopierar till avbildningsarkivet om paketet är stort eller har många filer. Läs mer här.

En Service Fabric-tjänst kan distribueras i olika "konfigurationer". Den kan till exempel distribueras som en eller flera instanser, eller så kan den distribueras på ett sådant sätt att det finns en instans av tjänsten på varje nod i Service Fabric-klustret.

Parametern InstanceCount för cmdleten New-ServiceFabricService används för att ange hur många instanser av tjänsten som ska startas i Service Fabric-klustret. Du kan ange värdet InstanceCount , beroende på vilken typ av program du distribuerar. De två vanligaste scenarierna är:

  • InstanceCount = "1". I det här fallet distribueras endast en instans av tjänsten i klustret. Service Fabrics schemaläggare avgör vilken nod tjänsten ska distribueras på.
  • InstanceCount ="-1". I det här fallet distribueras en instans av tjänsten på varje nod i Service Fabric-klustret. Resultatet är att det finns en (och endast en) instans av tjänsten för varje nod i klustret.

Det här är en användbar konfiguration för klientdelsprogram (till exempel en REST-slutpunkt), eftersom klientprogram måste "ansluta" till någon av noderna i klustret för att använda slutpunkten. Den här konfigurationen kan också användas när till exempel alla noder i Service Fabric-klustret är anslutna till en lastbalanserare. Klienttrafik kan sedan distribueras över den tjänst som körs på alla noder i klustret.

Kontrollera ditt program som körs

I Service Fabric Explorer identifierar du noden där tjänsten körs. I det här exemplet körs den på Node1:

Nod där tjänsten körs

Om du navigerar till noden och bläddrar till programmet visas viktig nodinformation, inklusive dess plats på disken.

Plats på disk

Om du bläddrar till katalogen med hjälp av Server Explorer kan du hitta arbetskatalogen och tjänstens loggmapp, enligt följande skärmbild:

Loggens plats

Nästa steg

I den här artikeln har du lärt dig att paketera en körbar gäst och distribuera den till Service Fabric. Se följande artiklar för relaterad information och uppgifter.