Service Fabric toepassings- en servicemanifests

  • Artikel
  • 8 minuten om te lezen

In dit artikel wordt beschreven Service Fabric toepassingen en services worden gedefinieerd en geversiereerd met behulp van de ApplicationManifest.xml en ServiceManifest.xml bestanden. Zie voorbeelden van toepassings- en servicemanifests voor meer gedetailleerde voorbeelden. Het XML-schema voor deze manifestbestanden wordt beschreven in de schemadocumentatie serviceFabricServiceModel.xsd.

Waarschuwing

Het XML-manifestbestandsschema dwingt de juiste volgorde van onderliggende elementen af. Als gedeeltelijke tijdelijke oplossing opent u C:\Program Files\Microsoft SDK's\Service Fabric\schemas\ServiceFabricServiceModel.xsd in Visual Studio tijdens het maken of wijzigen van een van de Service Fabric-manifesten. Hiermee kunt u de volgorde van onderliggende elementen controleren en intelli-zinnig zijn.

Een service in ServiceManifest.xml

Het servicemanifest definieert declaratief het servicetype en de versie. Hiermee worden servicemetagegevens opgegeven, zoals servicetype, statuseigenschappen, metrische gegevens voor taakverdeling, binaire servicebestanden en configuratiebestanden. Anders gezegd, het beschrijft de code, configuratie en gegevenspakketten die een servicepakket vormen ter ondersteuning van een of meer servicetypen. Een servicemanifest kan meerdere code-, configuratie- en gegevenspakketten bevatten, die onafhankelijk van elkaar versienummer kunnen krijgen. Hier is een servicemanifest voor de ASP.NET Core web-front-endservice van de voorbeeldtoepassing voting (en hier zijn enkele meer gedetailleerde voorbeelden):

<?xml version="1.0" encoding="utf-8"?>
<ServiceManifest Name="VotingWebPkg"
                 Version="1.0.0"
                 xmlns="http://schemas.microsoft.com/2011/01/fabric"
                 xmlns:xsd="https://www.w3.org/2001/XMLSchema"
                 xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance">
  <ServiceTypes>
    <!-- This is the name of your ServiceType. 
         This name must match the string used in RegisterServiceType call in Program.cs. -->
    <StatelessServiceType ServiceTypeName="VotingWebType" />
  </ServiceTypes>

  <!-- Code package is your service executable. -->
  <CodePackage Name="Code" Version="1.0.0">
    <EntryPoint>
      <ExeHost>
        <Program>VotingWeb.exe</Program>
        <WorkingFolder>CodePackage</WorkingFolder>
      </ExeHost>
    </EntryPoint>
  </CodePackage>

  <!-- Config package is the contents of the Config directory under PackageRoot that contains an 
       independently-updateable and versioned set of custom configuration settings for your service. -->
  <ConfigPackage Name="Config" Version="1.0.0" />

  <Resources>
    <Endpoints>
      <!-- This endpoint is used by the communication listener to obtain the port on which to 
           listen. Please note that if your service is partitioned, this port is shared with 
           replicas of different partitions that are placed in your code. -->
      <Endpoint Protocol="http" Name="ServiceEndpoint" Type="Input" Port="8080" />
    </Endpoints>
  </Resources>
</ServiceManifest>

Versiekenmerken zijn ongestructureerde tekenreeksen en worden niet geparseerd door het systeem. Versiekenmerken worden gebruikt om een versie van elk onderdeel voor upgrades uit te voeren.

ServiceTypes declareer welke servicetypen worden ondersteund door CodePackages in dit manifest. Wanneer een service wordt gemaakt op basis van een van deze servicetypen, worden alle codepakketten die in dit manifest zijn gedeclareerd, geactiveerd door hun toegangspunten uit te voeren. De resulterende processen registreren naar verwachting de ondersteunde servicetypen tijdens run time. Servicetypen worden gedeclareerd op manifestniveau en niet op het niveau van het codepakket. Wanneer er dus meerdere codepakketten zijn, worden ze allemaal geactiveerd wanneer het systeem zoekt naar een van de gedeclareerde servicetypen.

Het uitvoerbare bestand dat is opgegeven door EntryPoint is doorgaans de langlopende servicehost. SetupEntryPoint is een bevoorrecht toegangspunt dat wordt uitgevoerd met dezelfde referenties als Service Fabric (meestal het LocalSystem-account) vóór een ander toegangspunt. De aanwezigheid van een afzonderlijk installatie-ingangspunt voorkomt dat u de servicehost met hoge bevoegdheden voor langere tijd moet uitvoeren. Het uitvoerbare bestand dat is opgegeven door EntryPoint, wordt uitgevoerd nadat SetupEntryPoint is afgesloten. Als het proces ooit wordt beëindigd of vast loopt, wordt het resulterende proces bewaakt en opnieuw gestart (te beginnen met SetupEntryPoint).

Typische scenario's voor het gebruik van SetupEntryPoint zijn wanneer u een uitvoerbaar bestand uitvoert voordat de service wordt gestart of wanneer u een bewerking met verhoogde bevoegdheden hebt uitgevoerd. Bijvoorbeeld:

  • Omgevingsvariabelen instellen en initialiseren die het uitvoerbare bestand van de service nodig heeft. Dit is niet beperkt tot alleen uitvoerbare bestanden die zijn geschreven via de Service Fabric programmeermodellen. Zo moeten npm.exe omgevingsvariabelen zijn geconfigureerd voor het implementeren van een node.js toepassing.
  • Toegangsbeheer instellen door beveiligingscertificaten te installeren.

Zie Het beleid configureren voor een service-installatie-ingangspunt voor meer informatie over het configureren van SetupEntryPoint

EnvironmentVariables (niet ingesteld in het voorgaande voorbeeld) bevat een lijst met omgevingsvariabelen die zijn ingesteld voor dit codepakket. Omgevingsvariabelen kunnen worden overschrijven in de ApplicationManifest.xml om verschillende waarden voor verschillende service-exemplaren te bieden.

DataPackage (niet ingesteld in het voorgaande voorbeeld) declareert een map met de naam van het kenmerk Naam die willekeurige statische gegevens bevat die tijdens run time door het proces moeten worden gebruikt.

ConfigPackage declareer een map met de naam van het kenmerk Naam die een Settings.xml bevat. Het instellingenbestand bevat secties van door de gebruiker gedefinieerde instellingen voor sleutel-waardeparen die tijdens run time worden teruggelezen. Als tijdens een upgrade alleen de versie van ConfigPackage is gewijzigd, wordt het lopende proces niet opnieuw gestart. In plaats daarvan waarschuwt een callback het proces dat de configuratie-instellingen zijn gewijzigd, zodat ze dynamisch opnieuw kunnen worden geladen. Hier is een voorbeeld van Settings.xml bestand:

<Settings xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/2011/01/fabric">
  <Section Name="MyConfigurationSection">
    <Parameter Name="MySettingA" Value="Example1" />
    <Parameter Name="MySettingB" Value="Example2" />
  </Section>
</Settings>

Een Service Fabric service-eindpunt is een voorbeeld van een Service Fabric resource. Een Service Fabric resource kan worden gedeclareerd/gewijzigd zonder de gecompileerde code te wijzigen. Toegang tot de Service Fabric resources die zijn opgegeven in het servicemanifest, kan worden beheerd via de SecurityGroup in het toepassingsmanifest. Wanneer een eindpuntresource wordt gedefinieerd in het servicemanifest, wijst Service Fabric poorten toe vanuit het poortbereik van de gereserveerde toepassing wanneer een poort niet expliciet is opgegeven. Lees meer over het opgeven of overschrijven van eindpuntresources.

Waarschuwing

Statische poorten mogen niet overlappen met het poortbereik van de toepassing dat is opgegeven in ClusterManifest. Als u een statische poort opgeeft, wijst u deze toe buiten het poortbereik van de toepassing, anders leidt dit tot poortconflicten. Met release 6.5CU2 geven we een statuswaarschuwing wanneer we een dergelijk conflict detecteren, maar de implementatie synchroon laten gaan met het verzonden 6.5-gedrag. Het is echter mogelijk dat de implementatie van de toepassing wordt voorkomen in de volgende grote releases.

Een toepassing in ApplicationManifest.xml

Het toepassingsmanifest beschrijft declaratief het toepassingstype en de versie. Hiermee worden metagegevens van de servicesamenstelling opgegeven, zoals stabiele namen, partitieschema, aantal instanties/replicatiefactor, beveiligings-/isolatiebeleid, plaatsingsbeperkingen, configuratie-overschrijvingen en samenstellende servicetypen. De taakverdelingsdomeinen waarin de toepassing wordt geplaatst, worden ook beschreven.

Een toepassingsmanifest beschrijft daarom elementen op toepassingsniveau en verwijst naar een of meer servicemanifests om een toepassingstype samen te stellen. Hier is het toepassingsmanifest voor de voorbeeldtoepassing voor stemmen (en hier zijn enkele meer gedetailleerde voorbeelden):

<?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="VotingType" ApplicationTypeVersion="1.0.0" xmlns="http://schemas.microsoft.com/2011/01/fabric">
  <Parameters>
    <Parameter Name="VotingData_MinReplicaSetSize" DefaultValue="3" />
    <Parameter Name="VotingData_PartitionCount" DefaultValue="1" />
    <Parameter Name="VotingData_TargetReplicaSetSize" DefaultValue="3" />
    <Parameter Name="VotingWeb_InstanceCount" DefaultValue="-1" />
  </Parameters>
  <!-- Import the ServiceManifest from the ServicePackage. The ServiceManifestName and ServiceManifestVersion 
       should match the Name and Version attributes of the ServiceManifest element defined in the 
       ServiceManifest.xml file. -->
  <ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName="VotingDataPkg" ServiceManifestVersion="1.0.0" />
    <ConfigOverrides />
  </ServiceManifestImport>
  <ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName="VotingWebPkg" ServiceManifestVersion="1.0.0" />
    <ConfigOverrides />
  </ServiceManifestImport>
  <DefaultServices>
    <!-- The section below creates instances of service types, when an instance of this 
         application type is created. You can also create one or more instances of service type using the 
         ServiceFabric PowerShell module.
         
         The attribute ServiceTypeName below must match the name defined in the imported ServiceManifest.xml file. -->
    <Service Name="VotingData">
      <StatefulService ServiceTypeName="VotingDataType" TargetReplicaSetSize="[VotingData_TargetReplicaSetSize]" MinReplicaSetSize="[VotingData_MinReplicaSetSize]">
        <UniformInt64Partition PartitionCount="[VotingData_PartitionCount]" LowKey="0" HighKey="25" />
      </StatefulService>
    </Service>
    <Service Name="VotingWeb" ServicePackageActivationMode="ExclusiveProcess">
      <StatelessService ServiceTypeName="VotingWebType" InstanceCount="[VotingWeb_InstanceCount]">
        <SingletonPartition />
         <PlacementConstraints>(NodeType==NodeType0)</PlacementConstraints
      </StatelessService>
    </Service>
  </DefaultServices>
</ApplicationManifest>

Net als servicemanifests zijn versiekenmerken ongestructureerde tekenreeksen en worden ze niet geparseerd door het systeem. Versiekenmerken worden ook gebruikt om versies van elk onderdeel voor upgrades uit te voeren.

Parameters definiëren de parameters die in het toepassingsmanifest worden gebruikt. De waarden van deze parameters kunnen worden opgegeven wanneer de toepassing wordt gemaakt en de configuratie-instellingen van de toepassing of service kunnen overschrijven. De standaardparameterwaarde wordt gebruikt als de waarde niet wordt gewijzigd tijdens het instantiëring van de toepassing. Zie Toepassingsparameters voor meerdere omgevingen beheren voor meer informatie over het onderhouden van verschillende toepassings- en serviceparameters voor afzonderlijke omgevingen.

ServiceManifestImport bevat verwijzingen naar servicemanifesten waaruit dit toepassingstype bestaat. Een toepassingsmanifest kan meerdere importen van servicemanifests bevatten. Elk manifest kan onafhankelijk van elkaar worden geversiereerd. Geïmporteerde servicemanifests bepalen welke servicetypen geldig zijn binnen dit toepassingstype. In serviceManifestImport overschrijven u configuratiewaarden in Settings.xml en omgevingsvariabelen in ServiceManifest.xml bestanden. Beleidsregels (niet ingesteld in het vorige voorbeeld) voor eindpuntbinding, beveiliging en toegang en het delen van pakketten kunnen worden ingesteld op geïmporteerde servicemanifests. Zie Beveiligingsbeleid configureren voor uw toepassing voor meer informatie.

DefaultServices declareer service-exemplaren die automatisch worden gemaakt wanneer een toepassing wordt gemaakt voor dit toepassingstype. Standaardservices zijn slechts een gemak en gedragen zich in alle opzichten als normale services nadat ze zijn gemaakt. Ze worden samen met andere services in het exemplaar van de toepassing bijgewerkt en kunnen ook worden verwijderd. Een toepassingsmanifest kan meerdere standaardservices bevatten.

Certificaten (niet ingesteld in het voorgaande voorbeeld) declareren de certificaten die worden gebruikt voor het instellen van HTTPS-eindpunten of het versleutelen van geheimen in het toepassingsmanifest.

Plaatsingsbeperkingen zijn de instructies die bepalen waar services moeten worden uitgevoerd. Deze instructies zijn gekoppeld aan afzonderlijke services die u selecteert voor een of meer knooppunteigenschappen. Zie Plaatsingsbeperkingen en syntaxis van knooppunt-eigenschappen voor meer informatie

Beleidsregels (niet ingesteld in het voorgaande voorbeeld) beschrijft de logboekverzameling, het standaardbeleid voor uitvoeren als,status en beveiligingstoegang dat moet worden ingesteld op toepassingsniveau, inclusief of de service(s) toegang hebben tot de Service Fabric-runtime.

Notitie

Standaard hebben Service Fabric-toepassingen toegang tot de Service Fabric-runtime, in de vorm van een eindpunt dat toepassingsspecifieke aanvragen accepteert, en omgevingsvariabelen die naar bestandspaden op de host met fabric- en toepassingsspecifieke bestanden wijzen. Overweeg deze toegang uit te voeren wanneer de toepassing niet-vertrouwde code host (dat wil zeggen code waarvan de herkomst onbekend is of waarvan de eigenaar van de toepassing weet dat deze niet veilig kan worden uitgevoerd). Zie best practices voor beveiliging in Service Fabric.

Principals (niet ingesteld in het voorgaande voorbeeld) beschrijven de beveiligingsprincipalen (gebruikers of groepen) die nodig zijn om services uit te voeren en servicebronnen te beveiligen. Naar principals wordt verwezen in de sectie Beleidsregels.

Volgende stappen