Przykłady aplikacji reliable services i manifestów usług

Poniżej przedstawiono przykłady manifestów aplikacji i usługi dla aplikacji Service Fabric z front-endem internetowym platformy ASP.NET Core i stanowym backendem. Celem tych przykładów jest pokazanie, jakie ustawienia są dostępne i jak ich używać. Te manifesty aplikacji i usługi są oparte na manifestach szybkiego startu platformy .NET usługi Service Fabric .

Poniżej przedstawiono następujące funkcje:

Manifest	Funkcje
Manifest aplikacji	zarządzanie zasobami, uruchamianie usługi jako konta administratora lokalnego, stosowanie domyślnych zasad do wszystkich pakietów kodu usługi, tworzenie jednostek użytkowników i grup, udostępnianie pakietu danych między wystąpieniami usługi, zastępowanie punktów końcowych usługi
Manifest usługi FrontEndService	Uruchamianie skryptu podczas uruchamiania usługi, definiowanie punktu końcowego HTTPS
Manifest usługi BackEndService	Deklarowanie pakietu konfiguracji, deklarowanie pakietu danych, konfigurowanie punktu końcowego

Zobacz Elementy manifestu aplikacji, elementy manifestu usługi VotingWeb i elementy manifestuusługi VotingData , aby uzyskać więcej informacji na temat określonych elementów XML.

Manifest aplikacji

<?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" />
    <Parameter Name="CpuCores" DefaultValue="2" />
    <Parameter Name="Memory" DefaultValue="4084" />
    <Parameter Name="BlockIOWeight" DefaultValue="200" />
    <Parameter Name="MaximumIOBandwidth" DefaultValue="1024" />
    <Parameter Name="MemoryReservationInMB" DefaultValue="1024" />
    <Parameter Name="MemorySwapInMB" DefaultValue="4084"/>
    <Parameter Name="Port" DefaultValue="8081" />
    <Parameter Name="Protocol" DefaultValue="tcp" />
    <Parameter Name="Type" DefaultValue="internal" />
  </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" />
    <!-- Override endpoints declared in the service manifest. -->
    <ResourceOverrides>
      <Endpoints>
        <Endpoint Name="DataEndpoint" Port="[Port]" Protocol="[Protocol]" Type="[Type]" />
      </Endpoints>
    </ResourceOverrides>

    <!-- Policies to be applied to the imported service manifest. -->
    <Policies>
      
      <!-- Set resource governance at the service package level. -->
      <ServicePackageResourceGovernancePolicy CpuCores="[CpuCores]" MemoryInMB="[Memory]"/>

      <!-- Set resource governance at the code package level. -->
      <ResourceGovernancePolicy CodePackageRef="Code" CpuPercent="10" MemoryInMB="[Memory]" BlockIOWeight="[BlockIOWeight]" 
                                MaximumIOBandwidth="[MaximumIOBandwidth]" MaximumIOps="[MaximumIOps]" MemoryReservationInMB="[MemoryReservationInMB]" 
                                MemorySwapInMB="[MemorySwapInMB]"/>

      <!-- Share the data package across multiple instances of the VotingData service-->
      <PackageSharingPolicy PackageRef="Data"/>

      <!-- Give read rights on the "DataEndpoint" endpoint to the Customer2 account.-->
      <SecurityAccessPolicy GrantRights="Read" PrincipalRef="Customer2" ResourceRef="DataEndpoint" ResourceType="Endpoint"/>         
    </Policies>
  </ServiceManifestImport>
  
  <!-- 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="VotingWebPkg" ServiceManifestVersion="1.0.0" />
    
    <!-- Policies to be applied to the imported service manifest. -->
    <Policies>
      <!-- Run the setup entry point (defined in the imported service manifest) as the SetupAdminUser account 
      (declared in the following Principals section). -->
      <RunAsPolicy CodePackageRef="Code" UserRef="SetupAdminUser" EntryPointType="Setup" />
      
    </Policies>

  </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 />
      </StatelessService>
    </Service>
  </DefaultServices>
  <!-- Define users and groups required to run the services and access resources.  Principals are used in the Policies section(s). -->
  <Principals>
    <!-- Declare a set of groups as security principals, which can be referenced in policies. Groups are useful if there are multiple users 
    for different service entry points and they need to have certain common privileges that are available at the group level. -->
    <Groups>
      <!-- Create a group that has administrator privileges. -->
      <Group Name="LocalAdminGroup">
        <Membership>
          <SystemGroup Name="Administrators" />
        </Membership>
      </Group>
    </Groups>
    <Users>
      <!-- Declare a user and add the user to the Administrators system group. The SetupAdminUser account is used to run the 
      setup entry point of the VotingWebPkg code package (described in the preceding Policies section).-->
      <User Name="SetupAdminUser">
        <MemberOf>
          <SystemGroup Name="Administrators" />
        </MemberOf>
      </User>
      <!-- Create a user. Local user accounts are created on the machines where the application is deployed. By default, these accounts 
      do not have the same names as those specified here. Instead, they are dynamically generated and have random passwords. -->
      <User Name="Customer1" >
        <MemberOf>
          <!-- Add the user to the local administrators group.-->
          <Group NameRef="LocalAdminGroup" />
        </MemberOf>
      </User>
      <!-- Create a user as a local user with the specified account name and password. Local user accounts are created on the machines 
      where the application is deployed. -->
      <User Name="Customer2" AccountType="LocalUser" AccountName="Customer1" Password="MyPassword">
        <MemberOf>
          <!-- Add the user to the local administrators group.-->
          <Group NameRef="LocalAdminGroup" />
        </MemberOf>
      </User>
      <!-- Create a user as NetworkService. -->
      <User Name="MyDefaultAccount" AccountType="NetworkService" />      
    </Users>
  </Principals>
  <!-- Policies applied at the application level. -->
  <Policies>
    <!-- Specify a default user account for all code packages that don’t have a specific RunAsPolicy defined in 
    the ServiceManifestImport section(s). -->
    <DefaultRunAsPolicy UserRef="MyDefaultAccount" />
    
  </Policies>
</ApplicationManifest>

Manifest usługi VotingWeb

<?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">
    <!-- A privileged entry point that by default runs with the same credentials as Service Fabric (typically the NetworkService account) before 
    any other entry point. Use the setup entry point to set system environment variables, give the account running the service (NETWORK SERVICE, by default) 
    access to a certificate's private key, or perform other setup tasks. In the application manifest, you can change the security permissions to run the startup script 
    under a local system account or an administrator account.  -->
    <SetupEntryPoint>
      <ExeHost>
        <!-- The setup script to run. -->
        <Program>Setup.bat</Program>
        <!-- Pass arguments to the script when it runs.-->
        <Arguments>MyValue</Arguments>
        <!-- The working directory for the process in the code package on the node where the application is deployed. CodePackage sets the working directory to be 
        the root of the code package regardless of where the EXE is defined in the code package directory. This is where the processes can write the data. Writing data 
        in the code package or code base is not recommended as those folders could be shared between different application instances and may get deleted.-->
        <WorkingFolder>CodePackage</WorkingFolder>
        <!-- Warning! Do not use console redirection in a production application, only use it for local development and debugging. Redirects console output from the startup
        script to an output file in the application folder called "log" on the cluster node where the application is deployed and run. Also set the number of output files
        to retain and the maximum file size (in KB). -->
        <ConsoleRedirection FileRetentionCount="10" FileMaxSizeInKb="20480"/>
      </ExeHost>
    </SetupEntryPoint>
    <EntryPoint>
      <ExeHost>
        <Program>VotingWeb.exe</Program>
        <!-- The working directory for the process in the code package on the node where the application is deployed. CodePackage sets the working directory to be 
        the root of the code package regardless of where the EXE is defined in the code package directory. This is where the processes can write the data. Writing data 
        in the code package or code base is not recommended as those folders could be shared between different application instances and may get deleted.-->
        <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>
      <!-- Configure a HTTPS endpoint on port 443. 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="https" Name="EndpointHttps" Type="Input" Port="443" />
    </Endpoints>
  </Resources>
</ServiceManifest>

Manifest usługi VotingData

<?xml version="1.0" encoding="utf-8"?>
<ServiceManifest Name="VotingDataPkg"
                 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. -->
    <StatefulServiceType ServiceTypeName="VotingDataType"  HasPersistedState="true" />
  </ServiceTypes>

  <!-- Code package is your service executable. -->
  <CodePackage Name="Code" Version="1.0.0">
    <EntryPoint>
      <ExeHost>
        <Program>VotingData.exe</Program>
        <!-- The working directory for the process in the code package on the node where the application is deployed. CodePackage sets the working directory to be 
        the root of the code package regardless of where the EXE is defined in the code package directory. This is where the processes can write the data. Writing data 
        in the code package or code base is not recommended as those folders could be shared between different application instances and may get deleted.-->
        <WorkingFolder>CodePackage</WorkingFolder>
      </ExeHost>
    </EntryPoint>
  </CodePackage>

  <!-- Declares a folder, named by the Name attribute, under PackageRoot that contains a Settings.xml file. This file contains sections of user-defined, 
  key-value pair settings that the process can read back at run time. During an upgrade, if only the ConfigPackage version has changed, 
  then the running process is not restarted. Instead, a callback notifies the process that configuration settings have changed so they can be reloaded dynamically. -->
  <ConfigPackage Name="Config" Version="1.0.0" />
  
  <!-- Declares a folder, named by the Name attribute, under PackageRoot which contains static data files to be consumed by the process at run time. -->
  <DataPackage Name="Data" Version="1.0.0"/>

  <Resources>
    <Endpoints>
      <!-- Define an internal (used for intra-application communication) TCP endpoint. Since no port is specified, one is created and assigned dynamically
           to the service.-->
      <Endpoint Name="DataEndpoint" Protocol="tcp" Type="Internal" />
    </Endpoints>
  </Resources>

</ServiceManifest>

Elementy manifestu aplikacji

ApplicationManifest element

Deklaratywnie opisuje typ i wersję aplikacji. Do tworzenia typu aplikacji odwołuje się co najmniej jeden manifest usługi składowej. Ustawienia konfiguracji usług składowych można zastąpić przy użyciu sparametryzowanych ustawień aplikacji. Domyślne usługi, szablony usług, jednostki, zasady, konfiguracja diagnostyki i certyfikaty można również zadeklarować na poziomie aplikacji. Aby uzyskać więcej informacji, zobacz ApplicationManifest, element

Element parametrów

Deklaruje parametry używane w tym manifeście aplikacji. Wartość tych parametrów można podać w momencie tworzenia aplikacji i wartości te mogą służyć do zastępowania ustawień konfiguracji aplikacji lub usługi. Aby uzyskać więcej informacji, zobacz Element Parameters

Element parametru

Parametr aplikacji do użycia w tym manifeście. Wartość parametru można zmienić podczas tworzenia wystąpienia aplikacji, a jeśli nie zostanie podana żadna wartość, używana jest wartość domyślna. Aby uzyskać więcej informacji, zobacz Element parametru

ServiceManifestImport, element

Importuje manifest usługi utworzony przez dewelopera usługi. Manifest usługi musi zostać zaimportowany dla każdej usługi składowej w aplikacji. Nadpisania konfiguracji i zasady mogą być zadeklarowane dla manifestu usługi. Aby uzyskać więcej informacji, zobacz ServiceManifestImport, element

ServiceManifestRef, element

Importuje manifest usługi poprzez referencję. Obecnie plik manifestu usługi (ServiceManifest.xml) musi znajdować się w pakiecie kompilacji. Aby uzyskać więcej informacji, zobacz ServiceManifestRef, element

ResourceOverrides, element

Określa nadpisania zasobów dla punktów końcowych zadeklarowanych w zasobach manifestu usługi. Aby uzyskać więcej informacji, zobacz ResourceOverrides, element

Elementy końcowe

Punkt(-y) końcowy(-we) do zastąpienia. Aby uzyskać więcej informacji, zobacz Endpoints, element

Element punktu końcowego

Punkt końcowy zadeklarowany w manifeście usługi, do zastąpienia. Aby uzyskać więcej informacji, zobacz Element punktu końcowego

Element polityk

Opisuje zasady (powiązania punktu końcowego, udostępniania pakietów, uruchamiania w imieniu użytkownika i dostępu do zabezpieczeń) do zastosowania w zaimportowanym manifeście usługi. Aby uzyskać więcej informacji, zobacz Element Polityk

ServicePackageResourceGovernancePolicy Element

Definiuje zasady ładu zasobów, które są stosowane na poziomie całego pakietu usług. Aby uzyskać więcej informacji, zobacz element ServicePackageResourceGovernancePolicy

Element ResourceGovernancePolicy

Określa limity zasobów dla pakietu kodu. Aby uzyskać więcej informacji, zobacz element ResourceGovernancePolicy

PackageSharingPolicy, element

Wskazuje, czy kod, konfiguracja lub pakiet danych powinien być współużytkowany między wystąpieniami usługi tego samego typu usługi. Aby uzyskać więcej informacji, zobacz element PackageSharingPolicy

SecurityAccessPolicy, element

Udziela uprawnień dostępu do podmiotu w zasobie (takim jak punkt końcowy), zdefiniowanym w manifeście usługi. Zazwyczaj bardzo przydatne jest kontrolowanie i ograniczanie dostępu do usług do różnych zasobów w celu zminimalizowania ryzyka bezpieczeństwa. Jest to szczególnie ważne, gdy aplikacja jest tworzona na podstawie kolekcji usług z platformy handlowej, które są opracowywane przez różnych deweloperów. Aby uzyskać więcej informacji, zobacz element SecurityAccessPolicy

RunAsPolicy, element

Określa konto użytkownika lokalnego lub lokalnego systemu, w ramach którego zostanie uruchomiony pakiet kodu usługi. Konta domeny są obsługiwane we wdrożeniach systemu Windows Server, w których jest dostępny identyfikator Entra firmy Microsoft. Domyślnie aplikacje są uruchamiane na koncie, w ramach którego działa proces Fabric.exe. Aplikacje mogą być również uruchamiane jako inne konta, które muszą być zadeklarowane w sekcji Principal. Jeśli zastosujesz politykę RunAs dla usługi, a manifest usługi deklaruje zasoby punktów końcowych przy użyciu protokołu HTTP, musisz również określić SecurityAccessPolicy, aby upewnić się, że porty przydzielone do tych punktów końcowych są prawidłowo kontrolowane pod względem dostępu dla konta użytkownika RunAs, pod którym działa usługa. W przypadku punktu końcowego HTTPS należy również zdefiniować EndpointBindingPolicy, aby określić nazwę certyfikatu, który ma zostać zwrócony do klienta. Aby uzyskać więcej informacji, zobacz element RunAsPolicy

DefaultServices, element

Deklaruje wystąpienia usług, które są tworzone automatycznie za każdym razem, gdy aplikacja jest instancjonowana na podstawie tego typu aplikacji. Aby uzyskać więcej informacji, zobacz DefaultServices, element

Service, element

Deklaruje usługę, która ma zostać utworzona automatycznie po utworzeniu wystąpienia aplikacji. Aby uzyskać więcej informacji, sprawdź Element Usługi

StatefulService, element

Definiuje usługę stanową. Aby uzyskać więcej informacji, zobacz StatefulService, element

StatelessService, element

Definiuje usługę bezstanową. Aby uzyskać więcej informacji, zobacz StatelessService, element

Główne elementy

Opisuje podmioty zabezpieczeń (użytkowników, grupy) wymagane dla tej aplikacji do uruchamiania usług i zabezpieczania zasobów. Dyrektorzy są przywoływani w sekcjach polityk. Aby uzyskać więcej informacji, zapoznaj się z elementem Principals

Element grup

Deklaruje zestaw grup jako podmiotów zabezpieczeń, do których można się odwoływać w zasadach. Grupy są przydatne, jeśli istnieje wielu użytkowników dla różnych punktów wejścia usługi i muszą mieć pewne wspólne uprawnienia, które są dostępne na poziomie grupy. Aby uzyskać więcej informacji, zobacz Groups, element

Element grupy

Deklaruje grupę jako podmiot bezpieczeństwa, do którego można się odwoływać w zasadami. Aby uzyskać więcej informacji, zobacz Element grupy

Element członkostwa

Aby uzyskać więcej informacji, zobacz Element członkostwa

SystemGroup, element

Aby uzyskać więcej informacji, zobacz SystemGroup, element

Użytkownicy, element

Deklaruje zestaw użytkowników jako podmioty zabezpieczeń, do których można się odwoływać w zasadach. Aby uzyskać więcej informacji, zobacz Element użytkowników

Element użytkownika

Określa użytkownika jako podmiot zabezpieczeń, do którego można się odwoływać w politykach. Aby uzyskać więcej informacji, zobacz User, element

MemberOf, element

Użytkownicy mogą być dodawani do dowolnej istniejącej grupy członkostwa, dzięki czemu mogą dziedziczyć wszystkie właściwości i ustawienia zabezpieczeń tej grupy członkostwa. Grupa członkostwa może służyć do zabezpieczania zasobów zewnętrznych, które muszą być dostępne przez różne usługi lub tę samą usługę (na innym komputerze). Aby uzyskać więcej informacji, zobacz MemberOf, element

SystemGroup, element

Grupa systemowa, do których ma zostać dodany użytkownik. Grupa systemowa musi być zdefiniowana w sekcji Grupy. Aby uzyskać więcej informacji, zobacz SystemGroup, element

Element grupy

Grupa, do której należy dodać użytkownika. Grupa musi być zdefiniowana w sekcji Grupy. Aby uzyskać więcej informacji, zobacz Element grupy

Element polityk

Opisuje zasady (zbieranie dzienników, domyślne uruchomienie jako użytkownik, monitorowanie kondycji i dostęp bezpieczeństwa) do zastosowania na poziomie aplikacji. Aby uzyskać więcej informacji, zobacz Element Polityk

Element „DefaultRunAsPolicy”

Określ domyślne konto użytkownika dla wszystkich pakietów kodu usługi, które nie mają określonego elementu RunAsPolicy zdefiniowanego w sekcji ServiceManifestImport. Aby uzyskać więcej informacji, zobacz element DefaultRunAsPolicy

Elementy manifestu usługi VotingWeb

ServiceManifest, element

Deklaratywnie opisuje typ i wersję usługi. Zawiera on listę niezależnie uaktualnianego kodu, konfiguracji i pakietów danych, które razem tworzą pakiet usługi w celu obsługi co najmniej jednego typu usługi. Określono również zasoby, ustawienia diagnostyczne i metadane usługi, takie jak typ usługi, właściwości kondycji i metryki równoważenia obciążenia. Aby uzyskać więcej informacji, zobacz ServiceManifest, element

ServiceTypes, element

Definiuje typy usług obsługiwane przez pakiet CodePackage w tym manifeście. Gdy usługa jest tworzona dla jednego z tych typów usług, wszystkie pakiety kodu zadeklarowane w tym manifeście są aktywowane, uruchamiając ich punkty wejścia. Typy usług są deklarowane na poziomie manifestu, a nie na poziomie pakietu kodu. Aby uzyskać więcej informacji, zobacz ServiceTypes, element

StatelessServiceType, element

Opisuje typ usługi bezstanowej. Aby uzyskać więcej informacji, zobacz StatelessServiceType, element

CodePackage, element

Opisuje pakiet kodu obsługujący zdefiniowany typ usługi. Gdy usługa jest tworzona dla jednego z tych typów usług, wszystkie pakiety kodu zadeklarowane w tym manifeście są aktywowane, uruchamiając ich punkty wejścia. Oczekuje się, że wynikowe procesy będą rejestrować obsługiwane typy usług w czasie wykonywania. Gdy istnieje wiele pakietów kodu, wszystkie są aktywowane za każdym razem, gdy system szuka dowolnego z zadeklarowanych typów usług. Aby uzyskać więcej informacji, zobacz CodePackage, element

"SetupEntryPoint" jako element

Uprzywilejowany punkt wejścia, który domyślnie jest uruchamiany z tymi samymi poświadczeniami co Service Fabric (zazwyczaj konto NETWORKSERVICE) i ma pierwszeństwo przed innymi punktami wejścia. Plik wykonywalny określony przez program EntryPoint jest zazwyczaj długotrwałym hostem usługi. Obecność oddzielnego punktu wejścia konfiguracji pozwala uniknąć konieczności uruchamiania hosta usługi z wysokimi uprawnieniami przez dłuższy czas. Aby uzyskać więcej informacji, zobacz SetupEntryPoint, element

ExeHost, element

Aby uzyskać więcej informacji, zobacz ExeHost, element

Element programu

Nazwa pliku wykonywalnego. Na przykład "MySetup.bat" lub "MyServiceHost.exe". Aby uzyskać więcej informacji, zobacz Element programu

Argumenty-element

Aby uzyskać więcej informacji, zobacz Arguments, element

WorkingFolder, element

Katalog roboczy procesu w pakiecie kodu w węźle klastra, w którym jest wdrażana aplikacja. Można określić trzy wartości: Work (wartość domyślna), CodePackage lub CodeBase. CodeBase określa, że katalog roboczy jest ustawiony na katalog, w którym plik EXE jest zdefiniowany w pakiecie kodu. Pakiet CodePackage ustawia katalog roboczy jako katalog główny pakietu kodu niezależnie od tego, gdzie plik EXE jest zdefiniowany w katalogu pakietu kodu. Funkcja ustawia katalog pracy na unikatowy folder utworzony w węźle. Ten folder jest taki sam dla całego wystąpienia aplikacji. Domyślnie katalog roboczy wszystkich procesów w aplikacji jest ustawiony na folder roboczy aplikacji. W tym miejscu procesy mogą zapisywać dane. Zapisywanie danych w pakiecie kodu lub bazie kodu nie jest zalecane, ponieważ te foldery mogą być współużytkowane między różnymi wystąpieniami aplikacji i mogą zostać usunięte. Aby uzyskać więcej informacji, zobacz WorkingFolder, element

ConsoleRedirection, element

Ostrzeżenie

Nie używaj przekierowania konsoli w aplikacji produkcyjnej, używaj jej tylko do lokalnego programowania i debugowania. Przekierowuje dane wyjściowe konsoli ze skryptu uruchamiania do pliku wyjściowego w folderze aplikacji o nazwie "log" w węźle klastra, w którym aplikacja jest wdrażana i uruchamiana. Aby uzyskać więcej informacji, zobacz ConsoleRedirection, element

EntryPoint, element

Plik wykonywalny określony przez program EntryPoint jest zazwyczaj długotrwałym hostem usługi. Obecność oddzielnego punktu wejścia konfiguracji pozwala uniknąć konieczności uruchamiania hosta usługi z wysokimi uprawnieniami przez dłuższy czas. Plik wykonywalny określony przez EntryPoint jest uruchamiany po pomyślnym zakończeniu działania SetupEntryPoint. Wynikowy proces jest monitorowany i uruchamiany ponownie (począwszy od SetupEntryPoint), jeśli kiedykolwiek się zakończy lub ulegnie awarii. Aby uzyskać więcej informacji, zobacz EntryPoint, element

ExeHost, element

Aby uzyskać więcej informacji, zobacz ExeHost, element

ConfigPackage, element

Deklaruje folder o nazwie określonej atrybutem Name w obszarze PackageRoot, który zawiera plik Settings.xml. Ten plik zawiera sekcje ustawień pary klucz-wartość zdefiniowanych przez użytkownika, które proces może odczytywać w czasie wykonywania. Jeśli podczas uaktualniania zmieniono tylko wersję pakietu ConfigPackage, uruchomiony proces nie zostanie uruchomiony ponownie. Zamiast tego wywołanie zwrotne powiadamia proces, że ustawienia konfiguracji zostały zmienione, aby można było je ponownie załadować dynamicznie. Aby uzyskać więcej informacji, zobacz ConfigPackage, element

Element zasobów

Opisuje zasoby używane przez tę usługę, które można zadeklarować bez modyfikowania skompilowanego kodu i zmieniane podczas wdrażania usługi. Dostęp do tych zasobów jest kontrolowany za pomocą sekcji Podmioty i Zasady w manifeście aplikacji. Aby uzyskać więcej informacji, zobacz Resources, element

Elementy końcowe

Definiuje punkty końcowe dla usługi. Aby uzyskać więcej informacji, zobacz Endpoints, element

Element punktu końcowego

Punkt końcowy zadeklarowany w manifeście usługi, do zastąpienia. Aby uzyskać więcej informacji, zobacz Element punktu końcowego

Elementy manifestu usługi VotingData

ServiceManifest, element

Deklaratywnie opisuje typ i wersję usługi. Zawiera on listę niezależnie uaktualnianego kodu, konfiguracji i pakietów danych, które razem tworzą pakiet usługi w celu obsługi co najmniej jednego typu usługi. Określono również zasoby, ustawienia diagnostyczne i metadane usługi, takie jak typ usługi, właściwości kondycji i metryki równoważenia obciążenia. Aby uzyskać więcej informacji, zobacz ServiceManifest, element

TypyUsług, element

Definiuje typy usług obsługiwane przez pakiet CodePackage w tym manifeście. Gdy usługa jest tworzona dla jednego z tych typów usług, wszystkie pakiety kodu zadeklarowane w tym manifeście są aktywowane, uruchamiając ich punkty wejścia. Typy usług są deklarowane na poziomie manifestu, a nie na poziomie pakietu kodu. Aby uzyskać więcej informacji, zobacz ServiceTypes, element

StatefulServiceType, element

Opisuje stanowy typ usługi. Aby uzyskać więcej informacji, zobacz StatefulServiceType, element

CodePackage, element

Opisuje pakiet kodu obsługujący zdefiniowany typ usługi. Gdy usługa jest tworzona dla jednego z tych typów usług, wszystkie pakiety kodu zadeklarowane w tym manifeście są aktywowane, uruchamiając ich punkty wejścia. Oczekuje się, że wynikowe procesy będą rejestrować obsługiwane typy usług w czasie wykonywania. Gdy istnieje wiele pakietów kodu, wszystkie są aktywowane za każdym razem, gdy system szuka dowolnego z zadeklarowanych typów usług. Aby uzyskać więcej informacji, zobacz CodePackage, element

EntryPoint, element

Plik wykonywalny określony przez program EntryPoint jest zazwyczaj długotrwałym hostem usługi. Obecność oddzielnego punktu wejścia konfiguracji pozwala uniknąć konieczności uruchamiania hosta usługi z wysokimi uprawnieniami przez dłuższy czas. Plik wykonywalny określony przez EntryPoint jest uruchamiany po pomyślnym zakończeniu działania SetupEntryPoint. Wynikowy proces jest monitorowany i uruchamiany ponownie (począwszy od SetupEntryPoint), jeśli kiedykolwiek się zakończy lub ulegnie awarii. Aby uzyskać więcej informacji, zobacz EntryPoint, element

ExeHost, element

Aby uzyskać więcej informacji, zobacz ExeHost, element

Element programu

Nazwa pliku wykonywalnego. Na przykład "MySetup.bat" lub "MyServiceHost.exe". Aby uzyskać więcej informacji, zobacz Element programu

WorkingFolder, element

Katalog roboczy procesu w pakiecie kodu w węźle klastra, w którym jest wdrażana aplikacja. Można określić trzy wartości: Work (wartość domyślna), CodePackage lub CodeBase. CodeBase określa, że katalog roboczy jest ustawiony na katalog, w którym plik EXE jest zdefiniowany w pakiecie kodu. Pakiet CodePackage ustawia katalog roboczy jako katalog główny pakietu kodu niezależnie od tego, gdzie plik EXE jest zdefiniowany w katalogu pakietu kodu. Funkcja ustawia katalog pracy na unikatowy folder utworzony w węźle. Ten folder jest taki sam dla całego wystąpienia aplikacji. Domyślnie katalog roboczy wszystkich procesów w aplikacji jest ustawiony na folder roboczy aplikacji. W tym miejscu procesy mogą zapisywać dane. Zapisywanie danych w pakiecie kodu lub bazie kodu nie jest zalecane, ponieważ te foldery mogą być współużytkowane między różnymi wystąpieniami aplikacji i mogą zostać usunięte. Aby uzyskać więcej informacji, zobacz WorkingFolder, element

ConfigPackage, element

Deklaruje folder o nazwie określonej atrybutem Name w obszarze PackageRoot, który zawiera plik Settings.xml. Ten plik zawiera sekcje ustawień pary klucz-wartość zdefiniowanych przez użytkownika, które proces może odczytywać w czasie wykonywania. Jeśli podczas uaktualniania zmieniono tylko wersję pakietu ConfigPackage, uruchomiony proces nie zostanie uruchomiony ponownie. Zamiast tego wywołanie zwrotne powiadamia proces, że ustawienia konfiguracji zostały zmienione, aby można było je ponownie załadować dynamicznie. Aby uzyskać więcej informacji, zobacz ConfigPackage, element

DataPackage, element

Deklaruje folder o nazwie według atrybutu Name w obszarze PackageRoot, który zawiera pliki danych statycznych, które mają być używane przez proces w czasie wykonywania. Usługa Service Fabric zresetuje wszystkie pliki EXE i DLLHOST określone w hostach i pakietach wsparcia, gdy którykolwiek z pakietów danych wymienionych w manifeście usługi zostanie uaktualniony. Aby uzyskać więcej informacji, zobacz DataPackage, element

Element zasobów

Opisuje zasoby używane przez tę usługę, które można zadeklarować bez modyfikowania skompilowanego kodu i zmieniane podczas wdrażania usługi. Dostęp do tych zasobów jest kontrolowany za pomocą sekcji Podmioty i Zasady w manifeście aplikacji. Aby uzyskać więcej informacji, zobacz Resources, element

Elementy końcowe

Definiuje punkty końcowe dla usługi. Aby uzyskać więcej informacji, zobacz Endpoints, element

Element punktu końcowego

Punkt końcowy zadeklarowany w manifeście usługi, do zastąpienia. Aby uzyskać więcej informacji, zobacz Element punktu końcowego