Манифесты приложений и служб Service Fabric

В этой статье описывается, как с помощью файлов ApplicationManifest.xml и ServiceManifest.xml определяются приложения и службы Service Fabric и выполняется управление их версиями. Более подробные примеры см. здесь. Сведения о схеме XML для этих файлов манифеста см. в статье Документация по схеме ServiceFabricServiceModel.xsd.

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

Схема файла XML обеспечивает правильное упорядочение дочерних элементов. Чтобы частично обойти эту проблему, откройте C:\Program Files\Microsoft SDKs\Service Fabric\schemas\ServiceFabricServiceModel.xsd в Visual Studio во время создания или изменения любого манифеста Service Fabric. Так вы сможете проверить упорядочение дочерних элементов и получить доступ к функции автозавершения.

Описание службы в ServiceManifest.xml

Манифест службы декларативно определяет тип и версию службы. Он задает метаданные службы, такие как тип службы, свойства работоспособности, метрики балансировки нагрузки, двоичные файлы службы и файлы конфигурации. Другими словами, в нем описывается код, конфигурация и пакеты данных, из которых состоит пакет службы, для поддержки одного или нескольких типов служб. Манифест служб может содержать множество пакетов кода, конфигураций и данных, чьи версии устанавливаются независимо. Ниже приведен манифест службы для веб-интерфейсной службы ASP.NET Core примера приложения для голосования (и ниже приведены более подробные примеры):

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

Версия представляют собой неструктурированные строки, которые не обрабатываются системой. Атрибуты версии используются в целях указания версии каждого компонента для последующего обновления.

В атрибуте ServiceTypes указывается, какие типы служб поддерживаются пакетами CodePackages в этом манифесте. При создании экземпляра службы в соответствии с одним из этих типов службы все пакеты кода, объявленные в этом манифесте, активируются путем запуска соответствующих точек входа. Запущенные вследствие этого процессы должны зарегистрировать поддерживаемые типы служб во время выполнения. Типы служб декларируются на уровне манифеста, а не на уровне пакета кода. Поэтому при наличии нескольких пакетов кода они все активируются всякий раз, когда система ищет любой из объявленных типов служб.

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

Типичные сценарии использования SetupEntryPoint относятся к ситуации, когда вы запускаете исполняемый файл перед запуском службы или выполняете операцию с повышенными привилегиями. Например:

  • Настройка и инициализация переменных среды, необходимых исполняемому файлу службы. Это не ограничивается только исполняемыми файлами, написанными с помощью моделей программирования Service Fabric. Например, npm.exe нужны определенные переменные среды, настроенные для развертывания приложения Node.js.
  • Настройка контроля доступа посредством установки сертификатов безопасности.

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

Атрибут EnvironmentVariables (не задан в предыдущем примере) содержит список переменных среды, которые заданы для этого пакета кода. Переменные среды можно переопределить в ApplicationManifest.xml, что позволяет указывать разные значения для различных экземпляров службы.

Атрибут DataPackage (не задан в предыдущем примере) объявляет папку с именем, указанным в атрибуте Name, содержащим произвольные статические данные, которые должны обрабатываться процессом во время выполнения.

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

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

Конечная точка службы Service Fabric является примером ресурса Service Fabric. Ресурс Service Fabric может быть задекларирован/изменен без изменения составленного кода. Доступ к ресурсам Service Fabric, указанным в манифесте служб, можно контролировать в манифесте приложения с помощью элемента SecurityGroup. Если ресурс конечной точки определен в манифесте службы, Service Fabric назначает порты из диапазона зарезервированных портов приложений, если порт не указан явным образом. Дополнительные сведения см. в статье Указание ресурсов в манифесте службы.

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

Используемая архитектура требует, чтобы статические порты не перекрывались с диапазоном портов приложений, указанным в ClusterManifest. Указывая статический порт, не используйте номера из диапазона портов приложения, поскольку это приведет к конфликтам портов. В выпуске 6.5 CU2 мы создаем предупреждение о работоспособности при обнаружении таких конфликтов, но работа развертывания при этом продолжается так же, как в уже выпущенной версии 6.5. Возможно, в одном из следующих основных выпусков развертывание приложения будет в такой ситуации блокироваться.

Описания приложения в файле ApplicationManifest.xml

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

Таким образом, манифест приложения описывает элементы на уровне приложения и ссылается на один или несколько манифестов службы, которые составляют тип приложения. Ниже приведен манифест приложения для примера приложения для голосования (и ниже приведены более подробные примеры):

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

Как и манифесты службы, атрибуты версии являются неструктурированными строками и не анализируются системой. Атрибуты версии также используются в целях указания версии каждого компонента для последующего обновления.

Параметры. Определяет параметры, используемые в манифесте приложения. Значения этих параметров могут быть предоставлены при создании экземпляра приложения. В этом случае они могут переопределять параметры конфигурации приложения или службы. Значение параметра по умолчанию используется, если значение не изменяется во время создания экземпляра приложения. Сведения об использовании разных параметров приложений и служб для отдельных сред см. в статье Управление параметрами приложения для нескольких сред.

ServiceManifestImport содержит ссылки на манифесты служб, из которых состоит этот тип приложения. Манифест приложения может содержать несколько импортируемых манифестов службы, и каждая из них может быть версии независимо. Импортированные манифесты служб определяют, какие типы служб допустимы для применения в приложении этого типа. В ServiceManifestImport можно переопределить значения конфигурации в файле Settings.xml и переменные среды в файле ServiceManifest.xml. Политики (не задано в предыдущем примере). Для привязки конечной точки, обеспечения безопасности и доступа в импортированных манифестах службы можно задать общий доступ к пакетам. Дополнительные сведения см. в статье Configure security policies for your application (Настройка политик безопасности для приложения).

DefaultServices декларируются экземпляры служб, которые создаются автоматически при создании экземпляра приложения в соответствии с его типом. Службы по умолчанию используются только для удобства и после создания во всех отношениях действуют как и обычные службы. Они обновляются вместе с любыми другими службами в экземпляре приложения и также могут быть удалены. Манифест приложения может содержать несколько служб по умолчанию.

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

DefaultServices не рекомендуется использовать в пользу StartupServices.xml. Дополнительные сведения о StartupServices.xml см. в статье "Введение StartupServices.xml в приложении Service Fabric".

Сертификаты (не задано в предыдущем примере). Объявляет сертификаты, используемые для установки конечных точек HTTPS или для шифрования секретов в манифесте приложения.

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

Политики (не заданы в предыдущем примере) описывают сбор журналов, Запуск по умолчанию, работоспособностьи политики безопасности для установки на уровне приложения, включая сведения о том, имеют ли службы доступ к среде выполнения Service Fabric.

Примечание.

Кластер Service Fabric конструктивно представляет собой один клиент, в котором размещенные приложения считаются доверенными. Если вы собираетесь размещать недоверенные приложения, воспользуйтесь инструкцией из статьи Размещение ненадежных приложений в кластере Service Fabric.

Субъекты (не задано в предыдущем примере). Описывает субъекты безопасности (пользователи и группы), необходимые для запуска служб и защиты ресурсов служб. На субъекты можно ссылаться в разделах политики.

Следующие шаги