Поделиться через

Примеры приложений Reliable Services и манифестов служб

  • Статья

Ниже приведены примеры манифестов приложения и службы для приложения Service Fabric с веб-интерфейсом ASP.NET Core и серверной частью с сохранением состояния. Цель этих примеров — показать, какие параметры доступны и как их использовать. Эти манифесты приложений и служб основаны на манифестах быстрого запуска Service Fabric .NET .

Показаны следующие функции:

Манифест Функции
Манифест приложения управление ресурсами, запуск службы в качестве учетной записи локального администратора, применение политики по умолчанию ко всем пакетам кода службы, созданиюсубъектов-пользователей и групп, совместному доступу к пакету данных между экземплярами службы, переопределение конечных точек службы
Манифест службы FrontEndService Запуск скрипта при запуске службы, определение конечной точки HTTPS
Манифест службы BackEndService Объявление пакета конфигурации, объявление пакета данных, настройка конечной точки

Дополнительные сведения о конкретных XML-элементах см. в элементах манифеста службы Application, элементах манифеста службы VotingWeb и элементах манифеста службы VotingData .

Манифест приложения

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

Манифест службы 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>

Манифест службы 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>

Элементы манифеста приложения

Элемент ApplicationManifest

Декларативно описывает тип приложения и версию. На один или несколько манифестов служб, входящих в состав приложений, ссылаются для создания типа приложения. Параметры конфигурации составляющих служб можно переопределить с помощью параметризованных параметров приложения. Службы по умолчанию, шаблоны служб, субъекты, политики, настройка диагностики и сертификаты также можно объявить на уровне приложения. Дополнительные подробности см. в разделе «Элемент ApplicationManifest»

Элемент Параметры

Объявляет параметры, используемые в этом манифесте приложения. Значение этих параметров можно указать при создании экземпляра приложения и может использоваться для переопределения параметров конфигурации приложения или службы. Дополнительные сведения см. в разделе "Элемент параметров"

Элемент Параметр

Параметр приложения, используемый в этом манифесте. Значение параметра можно изменить во время создания экземпляра приложения или, если значение не указано, используется значение по умолчанию. Дополнительные сведения см. в разделе "Элемент "Параметр"

Элемент ServiceManifestImport

Импортирует манифест службы, созданный разработчиком службы. Манифест службы должен быть импортирован для каждой из составляющих служб в приложении. Переопределения конфигурации и политики можно объявить для манифеста службы. Дополнительные сведения см. в разделе "Элемент ServiceManifestImport"

Элемент ServiceManifestRef

Импортирует манифест службы по ссылке. В настоящее время файл манифеста службы (ServiceManifest.xml) должен присутствовать в пакете сборки. Дополнительные сведения см. в разделе "Элемент ServiceManifestRef"

Элемент ResourceOverrides

Указывает переопределения ресурсов для конечных точек, объявленных в служебном манифесте. См. раздел "Элемент ResourceOverrides" для получения дополнительной информации.

Элемент Endpoints

Точка подключения(-и) для переопределения. Дополнительные сведения см. в разделе "Элемент Endpoints"

Элемент конечной точки

Конечная точка, объявленная в манифесте службы, переопределяется. Дополнительные сведения см. в разделе "Элемент Endpoint"

Элемент политик

Описывает политики (привязка конечной точки, общий доступ к пакетам, доступ к запуску и безопасности), применяемые к манифесту импортированной службы. Дополнительные сведения см.: Элемент Политики

Элемент политики управления ресурсами пакета услуг

Определяет политику управления ресурсами, применяемую на уровне всего пакета службы. Дополнительные сведения см. в разделе "Элемент ServicePackageResourceGovernancePolicy"

Элемент ResourceGovernancePolicy

Задает ограничения ресурсов для пакета кода. Дополнительные сведения см. в разделе "Элемент ResourceGovernancePolicy"

Элемент PackageSharingPolicy

Указывает, следует ли совместно использовать код, конфигурацию или пакет данных между экземплярами службы одного типа службы. Дополнительные сведения см. в разделе "Элемент PackageSharingPolicy"

Элемент SecurityAccessPolicy

Предоставляет разрешения на доступ субъекту к ресурсу (например, конечной точке), определенному в описании службы. Как правило, очень полезно контролировать и ограничивать доступ к службам различным ресурсам, чтобы свести к минимуму риски безопасности. Это особенно важно, когда приложение создается из коллекции служб из Marketplace, разработанных различными разработчиками. Дополнительные сведения см. в разделе "Элемент SecurityAccessPolicy"

Элемент RunAsPolicy

Указывает локальную учетную запись пользователя или локальной системы, под которой будет выполняться пакет службы. Учетные записи домена поддерживаются в развертываниях Windows Server, где доступен идентификатор Microsoft Entra. По умолчанию приложения выполняются под учетной записью, в которой выполняется процесс Fabric.exe. Приложения также могут запускаться как другие учетные записи, которые должны быть объявлены в разделе "Субъекты". Если вы применяете политику RunAs к службе, а манифест службы объявляет ресурсы конечных точек с протоколом HTTP, необходимо также указать SecurityAccessPolicy, чтобы убедиться, что порты, выделенные этим конечным точкам, правильно настроены на управление доступом для учетной записи пользователя RunAs, под которой выполняется служба. Для конечной точки HTTPS также необходимо определить EndpointBindingPolicy, чтобы указать имя сертификата, возвращаемого клиенту. Дополнительные сведения см. в разделе "Элемент RunAsPolicy"

Элемент DefaultServices

Объявляет экземпляры служб, которые создаются автоматически при создании экземпляра приложения для этого типа приложения. Дополнительные сведения см. Элемент DefaultServices

Элемент обслуживания

Объявляет службу, которая создается автоматически при создании экземпляра приложения. Дополнительные сведения см. в разделе "Элемент службы"

Элемент StatefulService

Определяет состояниясохраняющую службу. Дополнительные сведения см. в разделе "Элемент StatefulService"

Элемент StatelessService

Определяет бестелесную службу. Дополнительные сведения см. в разделе "Элемент StatelessService"

Элемент Руководители

Описывает субъекты безопасности (пользователи, группы), необходимые для запуска служб и обеспечения защиты ресурсов. Ответственные лица упомянуты в разделах политик. Дополнительные сведения см. в разделе "Элементы Principals"

Элемент групп

Объявляет набор групп в качестве субъектов безопасности, на которые можно ссылаться в политиках. Группы полезны, если существует несколько пользователей для разных точек входа службы, и они должны иметь определенные общие привилегии, доступные на уровне группы. Дополнительные сведения см. в разделе "Элементы Groups"

Элемент группы

Объявляет группу как субъект безопасности, на которую можно ссылаться в политиках. Дополнительные сведения см. в разделе "Элемент Группа"

Элемент Членства

Дополнительные сведения см. в разделе "Элемент членства"

Элемент SystemGroup

Дополнительные сведения см. в разделе "Элемент SystemGroup"

Элемент Пользователи

Объявляет набор пользователей в качестве субъектов безопасности, на которые можно ссылаться в политиках. Дополнительные сведения см. в разделе "Пользователи"

Элемент пользователя

Объявляет пользователя в качестве субъекта безопасности, на который можно ссылаться в политиках. Для получения дополнительной информации см. User Element

Элемент MemberOf

Пользователи могут быть добавлены в любую существующую группу членства, поэтому она может наследовать все свойства и параметры безопасности этой группы членства. Группу членства можно использовать для защиты внешних ресурсов, к которым необходимо обращаться различными службами или одной и той же службой (на другом компьютере). Для получения дополнительной информации см. элемент MemberOf

Элемент SystemGroup

Системная группа для добавления пользователя. Системная группа должна быть определена в разделе "Группы". Дополнительные сведения см. в разделе "Элемент SystemGroup"

Элемент группы

Группа, в которую нужно добавить пользователя. Группа должна быть определена в разделе "Группы". Дополнительные сведения см. в разделе "Элемент Group"

Элемент политик

Описывает политики (сбор журналов, запуск от имени по умолчанию, состояние и доступ к безопасности) для применения на уровне приложения. Дополнительные сведения см. в разделе Policies Element

Элемент DefaultRunAsPolicy

Укажите учетную запись пользователя по умолчанию для всех пакетов кода службы, которые не имеют определенного параметра RunAsPolicy, определенного в разделе ServiceManifestImport. Дополнительные сведения см. в разделе "Элемент DefaultRunAsPolicy"

Элементы манифеста службы VotingWeb

Элемент ServiceManifest

Декларативно описывает тип службы и версию. В нем перечислены независимые обновляемые коды, конфигурации и пакеты данных, которые вместе составляют пакет службы для поддержки одного или нескольких типов служб. Также указываются ресурсы, параметры диагностики и метаданные службы, такие как тип службы, свойства работоспособности и метрики балансировки нагрузки. Дополнительные сведения см. в разделе "Элемент ServiceManifest"

Элемент ServiceTypes

Определяет типы служб, поддерживаемые CodePackage в этом манифесте. При создании экземпляра службы в соответствии с одним из этих типов службы все пакеты кода, объявленные в этом манифесте, активируются путем запуска соответствующих точек входа. Типы служб декларируются на уровне манифеста, а не на уровне пакета кода. Дополнительные сведения см. в разделе "Элемент ServiceTypes"

Элемент StatelessServiceType

Описывает тип бесстатусной службы. Дополнительные сведения см. в разделе "Элемент StatelessServiceType"

Элемент CodePackage

Описывает пакет кода, поддерживающий определенный тип службы. При создании экземпляра службы в соответствии с одним из этих типов службы все пакеты кода, объявленные в этом манифесте, активируются путем запуска соответствующих точек входа. Запущенные вследствие этого процессы должны зарегистрировать поддерживаемые типы служб во время выполнения. При наличии нескольких пакетов кода они все активируются всякий раз, когда система ищет любой из объявленных типов служб. Дополнительные сведения см. в разделе "Элемент CodePackage"

Элемент SetupEntryPoint

Привилегированная точка входа, которая по умолчанию запускается с теми же учетными данными, что и Service Fabric (обычно учетная запись NETWORKSERVICE), перед запуском любых других точек входа. Исполняемый файл, указанный в EntryPoint, обычно является долго работающим хостом службы. Наличие отдельной точки входа настройки позволяет избежать необходимости в выполнении узла службы с расширенными правами в течение длительного срока. Дополнительные сведения см. в разделе "Элемент SetupEntryPoint"

Элемент ExeHost

Дополнительные сведения см. в разделе "Элемент ExeHost"

Элемент программы

Имя исполняемого файла. Например, "MySetup.bat" или "MyServiceHost.exe". Дополнительные сведения см. в разделе "Program Element"

Элемент Аргументы

Дополнительные сведения см. в разделе Arguments Element

Элемент WorkingFolder

Рабочий каталог для процесса в пакете кода на узле кластера, где развертывается приложение. Можно указать три значения: Work (по умолчанию), CodePackage или CodeBase. CodeBase указывает, что рабочий каталог задается в каталоге, в котором EXE определяется в пакете кода. CodePackage задает рабочий каталог корнем пакета кода независимо от того, где exe определен в каталоге пакета кода. Команда Work устанавливает рабочий каталог в уникальную директорию, созданную на узле. Эта папка одинакова для всего экземпляра приложения. По умолчанию рабочий каталог всех процессов в приложении устанавливается в рабочую папку приложения. Именно здесь процессы могут записывать данные. Запись данных в пакете кода или базе кода не рекомендуется, так как эти папки могут совместно использоваться между разными экземплярами приложений и могут быть удалены. Дополнительные сведения см. в разделе "Элемент WorkingFolder"

Элемент ConsoleRedirection

Предупреждение

Не используйте перенаправление консоли в рабочем приложении только для локальной разработки и отладки. Перенаправляет выходные данные консоли из скрипта запуска в выходной файл в папке приложения с именем log на узле кластера, где развернуто и запущено приложение. Дополнительные сведения см. в разделе "Элемент ConsoleRedirection"

Элемент EntryPoint

Исполняемый файл, указанный в EntryPoint, обычно является хостом длительно работающих служб. Наличие отдельной точки входа настройки позволяет избежать необходимости в выполнении узла службы с расширенными правами в течение длительного срока. Исполняемый файл, указанный в EntryPoint, запускается после успешного завершения работы SetupEntryPoint. Результирующий процесс отслеживается и перезапускается (начиная с SetupEntryPoint), если он когда-либо завершает работу или аварийно завершается. Дополнительные сведения см. в разделе "Элемент EntryPoint"

Элемент ExeHost

Дополнительные сведения см. в разделе "Элемент ExeHost"

Элемент ConfigPackage

Объявляет папку, названную по атрибуту Name, под PackageRoot, которая содержит файл Settings.xml. Этот файл содержит разделы определяемых пользователем параметров пары "ключ-значение", которые процесс может считывать обратно во время выполнения. При обновлении, если изменена только версия ConfigPackage, запущенный процесс не перезапускается. Вместо этого при помощи обратного вызова в процесс передается уведомление о том, что параметры конфигурации изменились, поэтому они были перезагружены в динамическом режиме. Дополнительные сведения см. в разделе "Элемент ConfigPackage"

Элемент ресурсов

Описывает ресурсы, используемые этой службой, которые могут быть объявлены без изменения скомпилированного кода и могут быть изменены при развертывании службы. Доступ к этим ресурсам контролируется с помощью разделов "Субъекты и политики" манифеста приложения. Для получения дополнительной информации см. раздел Resources.

Элемент Конечные точки

Определяет конечные точки для службы. Дополнительные сведения см. статью Endpoints Element

Элемент конечной точки

Конечная точка, объявленная в манифесте службы, переопределяется. Дополнительные сведения см. в разделе "Элемент Endpoint"

Элементы манифеста службы VotingData

Элемент ServiceManifest

Декларативно описывает тип службы и версию. В нем перечислены независимые обновляемые коды, конфигурации и пакеты данных, которые вместе составляют пакет службы для поддержки одного или нескольких типов служб. Также указываются ресурсы, параметры диагностики и метаданные службы, такие как тип службы, свойства работоспособности и метрики балансировки нагрузки. Дополнительные сведения см. в разделе "Элемент ServiceManifest"

Элемент ServiceTypes

Определяет типы служб, поддерживаемые CodePackage в этом манифесте. При инстанцировании службы для одного из этих типов все кодовые пакеты, декларированные в данном манифесте, активируются запуском их точек входа. Типы служб декларируются на уровне манифеста, а не на уровне пакета кода. Дополнительные сведения см. в разделе "Элемент ServiceTypes"

Элемент StatefulServiceType

Описывает тип службы с сохранением состояния. Дополнительные сведения см. в разделе "Элемент StatefulServiceType"

Элемент CodePackage

Описывает пакет кода, поддерживающий определенный тип службы. При создании экземпляра службы в соответствии с одним из этих типов службы все пакеты кода, объявленные в этом манифесте, активируются путем запуска соответствующих точек входа. Запущенные вследствие этого процессы должны зарегистрировать поддерживаемые типы служб во время выполнения. При наличии нескольких пакетов кода они все активируются всякий раз, когда система ищет любой из объявленных типов служб. Дополнительные сведения см. в разделе "Элемент CodePackage"

Элемент EntryPoint

Исполняемый файл, указанный в EntryPoint, обычно является хостом длительно работающих служб. Наличие отдельной точки ввода позволяет избежать необходимости запуска узла службы с высокими привилегиями на длительное время. Исполняемый файл, указанный в EntryPoint, запускается после успешного завершения работы SetupEntryPoint. Результирующий процесс отслеживается и перезапускается (начиная с SetupEntryPoint), если он когда-либо завершается или аварийно завершает работу. Дополнительные сведения см. в разделе "Элемент EntryPoint"

Элемент ExeHost

Дополнительные сведения см. в разделе "Элемент ExeHost"

Элемент программы

Имя исполняемого файла. Например, "MySetup.bat" или "MyServiceHost.exe". Дополнительные сведения см. в разделе Program Element

Элемент WorkingFolder

Рабочий каталог для процесса в пакете кода на узле кластера, где развертывается приложение. Можно указать три значения: Work (по умолчанию), CodePackage или CodeBase. CodeBase указывает, что рабочий каталог задается в каталоге, в котором EXE определяется в пакете кода. CodePackage задает рабочий каталог корнем пакета кода независимо от того, где exe определен в каталоге пакета кода. Функция устанавливает рабочую директорию в уникальную папку, созданную на узле. Эта папка одинакова для всего экземпляра приложения. По умолчанию рабочий каталог всех процессов в приложении устанавливается в рабочую папку приложения. Именно здесь процессы могут записывать данные. Запись данных в пакете кода или базе кода не рекомендуется, так как эти папки могут совместно использоваться между разными экземплярами приложений и могут быть удалены. Дополнительные сведения см. в разделе "Элемент WorkingFolder"

Элемент ConfigPackage

Объявляет папку с именем, указанным в атрибуте Name, под PackageRoot, которая содержит файл Settings.xml. Этот файл содержит разделы определяемых пользователем параметров пары "ключ-значение", которые процесс может считывать обратно во время выполнения. При обновлении, если изменена только версия ConfigPackage, запущенный процесс не перезапускается. Вместо этого при помощи обратного вызова в процесс передается уведомление о том, что параметры конфигурации изменились, поэтому они были перезагружены в динамическом режиме. Дополнительные сведения см. в разделе "Элемент ConfigPackage"

Элемент DataPackage

Объявляет папку, указанную атрибутом Name, в каталоге PackageRoot, содержащую статические файлы данных для использования процессом во время выполнения. Service Fabric будет перезагружать все EXEs и DLLHOSTs, указанные в хосте, и пакеты поддержки при обновлении любого из пакетов данных, перечисленных в манифесте службы. Дополнительные сведения см. в разделе "Элемент DataPackage"

Элемент ресурсов

Описывает ресурсы, используемые этой службой, которые могут быть объявлены без изменения скомпилированного кода и изменены при развертывании службы. Доступ к этим ресурсам контролируется с помощью разделов "Субъекты и политики" манифеста приложения. Дополнительные сведения см. в ресурсе "Элемент ресурсов"

Элемент Конечные точки

Определяет конечные точки для службы. Дополнительные сведения см. в разделе "Элемент Endpoints"

Элемент конечной точки

Конечная точка, объявленная в манифесте службы, переопределяется. Дополнительные сведения см. в разделе "Элемент Endpoint"