Упаковка и развертывание существующего исполняемого файла в Service Fabric

2025-04-04

При упаковке существующего исполняемого файла в качестве гостевого исполняемого файла можно выбрать шаблон проекта Visual Studio или создать пакет приложения вручную. С помощью Visual Studio структура пакета приложения и файлы манифеста создаются новым шаблоном проекта.

Подсказка

Самый простой способ упаковать существующий исполняемый файл Windows в службу — использовать Visual Studio и Linux для использования Yeoman

Использование Visual Studio для упаковки и развертывания существующего исполняемого файла

Visual Studio предоставляет шаблон службы Service Fabric для развертывания гостевого исполняемого файла в кластере Service Fabric.

Выберите файл>нового проекта и создайте приложение Service Fabric.
Выберите Guest Executable в качестве шаблона службы.
Нажмите кнопку "Обзор" , чтобы выбрать папку с исполняемым файлом и заполнить остальные параметры, чтобы создать службу.
- Поведение пакета кода. Можно настроить, чтобы все содержимое вашей папки копировалось в проект Visual Studio, что полезно, если исполняемый файл не изменяется. Если вы ожидаете изменения исполняемого файла и хотите иметь возможность динамически получать новые сборки, можно выбрать ссылку на папку вместо этого. При создании проекта приложения в Visual Studio можно использовать связанные папки. Это связывает с исходным местоположением внутри проекта, что позволяет обновить гостевой исполняемый файл непосредственно в его исходном местоположении. Эти обновления становятся частью пакета приложения при сборке.
- Программа указывает исполняемый файл, который должен запускаться для запуска службы.
- Аргументы указывают аргументы, которые должны передаваться исполняемому файлу. Это может быть список параметров с аргументами.
- WorkingFolder указывает рабочий каталог для процесса, который будет запущен. Можно указать три значения:
  - CodeBase указывает, что рабочий каталог будет задан в каталог кода в пакете приложения (Code каталог, показанный в предыдущей структуре файла).
  - CodePackage указывает, что рабочий каталог будет установлен в корневой каталог пакета приложения (GuestService1Pkg показан в предыдущей структуре файла).
  - Work указывает, что файлы помещаются в подкаталог, называемый работой.
Присвойте службе имя и нажмите кнопку "ОК".
Если вашей службе требуется конечная точка для обмена данными, вы теперь можете добавить в файл ServiceManifest.xml протокол, порт и тип. Например: <Endpoint Name="NodeAppTypeEndpoint" Protocol="http" Port="3000" UriScheme="http" PathSuffix="myapp/" Type="Input" />.
Теперь вы можете использовать пакет и опубликовать действие в локальном кластере, отладив решение в Visual Studio. Когда вы будете готовы, вы можете опубликовать приложение в удаленном кластере или зафиксировать решение в системе контроля версий.
Ознакомьтесь с проверкой запускаемого приложения , чтобы узнать, как просмотреть гостевую исполняемую службу, запущенную в Service Fabric Explorer.

Пример пошагового руководства см. в статье "Создание первого гостевого исполняемого приложения с помощью Visual Studio".

Упаковка нескольких исполняемых файлов с помощью Visual Studio

Visual Studio можно использовать для создания пакета приложения, содержащего несколько гостевых исполняемых файлов. После добавления первого гостевого исполняемого файла щелкните правой кнопкой мыши на проекте приложения и выберите Добавить новую службу Service Fabric>, чтобы добавить второй проект с гостевым исполняемым файлом в решение.

Примечание.

Если вы решите связать исходный код в проекте Visual Studio и собрать решение Visual Studio, это обеспечит актуальность вашего пакета приложения в соответствии с изменениями в исходнике.

Использование Yeoman для упаковки и развертывания существующего исполняемого файла в Linux

Процедура создания и развертывания гостевого исполняемого файла в Linux аналогична развертыванию приложения C# или Java.

В терминале введите yo azuresfguest.
Присвойте имя приложению.
Присвойте службе имя и укажите сведения, включая путь к исполняемому файлу и параметры, с которыми он должен вызываться.

Yeoman создает пакет приложения с соответствующими файлами приложения и манифеста, а также скриптами установки и удаления.

Упаковка нескольких исполняемых файлов с помощью Yeoman в Linux

Чтобы добавить службу в приложение, созданное с использованием yo, сделайте следующее:

Перейдите в корневой каталог существующего приложения. Например, cd ~/YeomanSamples/MyApplication, если MyApplication является приложением, созданным с помощью Yeoman.
Запустите yo azuresfguest:AddService и укажите необходимые сведения.

Ручная подготовка и развертывание существующего исполняемого файла.

Процесс упаковки гостевого исполняемого файла вручную основан на следующих общих шагах:

Создайте структуру каталога пакетов.
Добавьте файлы кода и конфигурации приложения.
Измените файл манифеста службы.
Измените файл манифеста приложения.

Создание структуры каталогов пакетов

Для начала создайте структуру каталогов, как описано в разделе "Упаковка приложения Azure Service Fabric".

Добавление файлов кода и конфигурации приложения

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

Service Fabric выполняет xcopy содержимого корневого каталога приложения, поэтому нет предопределённой структуры, кроме необходимости создания двух верхних каталогов: код и настройки. (Вы можете выбрать разные имена, если вы хотите. Дополнительные сведения см. в следующем разделе.)

Примечание.

Убедитесь, что вы включаете все файлы и зависимости, необходимые приложению. Service Fabric копирует содержимое пакета приложения на всех узлах в кластере, где будут развернуты службы приложения. Пакет должен содержать весь код, который требуется запустить приложению. Не предполагайте, что зависимости уже установлены.

Изменение файла манифеста службы

Следующий шаг — изменить файл манифеста службы, чтобы включить следующие сведения:

Имя типа службы. Это идентификатор, который Service Fabric использует для идентификации службы.
Команда, используемая для запуска приложения (ExeHost).
Любой скрипт, который необходимо запустить для настройки приложения (SetupEntrypoint).

Ниже приведен пример файла ServiceManifest.xml .

<?xml version="1.0" encoding="utf-8"?>
<ServiceManifest xmlns:xsd="https://www.w3.org/2001/XMLSchema" xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance" Name="NodeApp" Version="1.0.0.0" xmlns="http://schemas.microsoft.com/2011/01/fabric">
   <ServiceTypes>
      <StatelessServiceType ServiceTypeName="NodeApp" UseImplicitHost="true"/>
   </ServiceTypes>
   <CodePackage Name="code" Version="1.0.0.0">
      <SetupEntryPoint>
         <ExeHost>
             <Program>scripts\launchConfig.cmd</Program>
         </ExeHost>
      </SetupEntryPoint>
      <EntryPoint>
         <ExeHost>
            <Program>node.exe</Program>
            <Arguments>bin/www</Arguments>
            <WorkingFolder>CodePackage</WorkingFolder>
         </ExeHost>
      </EntryPoint>
   </CodePackage>
   <Resources>
      <Endpoints>
         <Endpoint Name="NodeAppTypeEndpoint" Protocol="http" Port="3000" Type="Input" />
      </Endpoints>
   </Resources>
</ServiceManifest>

В следующих разделах описаны различные части файла, которые необходимо обновить.

Обновление типов услуг

<ServiceTypes>
  <StatelessServiceType ServiceTypeName="NodeApp" UseImplicitHost="true" />
</ServiceTypes>

Вы можете выбрать любое имя для ServiceTypeName, какое хотите. Значение используется в ApplicationManifest.xml файле для идентификации службы.
Укажите UseImplicitHost="true". Этот атрибут сообщает Service Fabric, что служба основана на автономном приложении, поэтому все, что нужно сделать Service Fabric, это запустить его в качестве процесса и следить за его работоспособностью.

Обновление пакета кода

Элемент CodePackage указывает расположение кода службы (и версия).

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

Элемент Name используется для указания имени каталога в пакете приложения, содержащего код службы. CodePackage также имеет version атрибут. Это можно использовать для указания версии кода, а также может использоваться для обновления кода службы с помощью инфраструктуры управления жизненным циклом приложений в Service Fabric.

Необязательно: обновить SetupEntrypoint

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

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

Существует только один SetupEntryPoint, поэтому скрипты установки необходимо сгруппировать в один пакетный файл, если для установки приложения требуется несколько сценариев. SetupEntryPoint может выполнять любой тип файла: исполняемые файлы, пакетные файлы и командлеты PowerShell. Дополнительные сведения см. в разделе "Настройка SetupEntryPoint".

В предыдущем примере SetupEntryPoint запускает пакетный файл LaunchConfig.cmd , который находится в scripts подкаталоге каталога кода (если для элемента WorkingFolder задано значение CodeBase).

Обновление EntryPoint

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

Элемент EntryPoint в файле манифеста службы используется для указания способа запуска службы.

Элемент ExeHost указывает исполняемый файл (и аргументы), которые следует использовать для запуска службы. При необходимости можно добавить атрибут IsExternalExecutable="true", чтобы указать ExeHost, что программа является внешним исполняемым файлом за пределами пакета кода. Например, <ExeHost IsExternalExecutable="true">.

Program указывает имя исполняемого файла, который должен запустить службу.
Arguments указывает аргументы, которые должны передаваться исполняемому файлу. Это может быть список параметров с аргументами.
WorkingFolder указывает рабочий каталог для процесса, который будет запущен. Можно указать три значения:
- CodeBase указывает, что рабочий каталог будет установлен в каталог кода в пакете приложения (Code каталог в предыдущей структуре файла).
- CodePackage указывает, что рабочий каталог будет иметь корневой каталог пакета приложения (GuestService1Pkg в предыдущей структуре файла).
  - Work указывает, что файлы помещаются в подкаталог, называемый работой.

Функция WorkingFolder полезна, чтобы задать правильный рабочий каталог, чтобы относительные пути могли использоваться приложениями или скриптами инициализации.

Обновление конечных точек и регистрация в службе именования для обмена данными

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

В предыдущем примере элемент указывает конечные точки, Endpoint которые приложение может прослушивать. В этом примере приложение Node.js прослушивает http через порт 3000.

Кроме того, можно попросить Service Fabric опубликовать эту конечную точку в службе именования, чтобы другие службы могли обнаружить адрес конечной точки этой службы. Это позволяет взаимодействовать между службами, которые являются гостевыми исполняемыми файлами. Адрес опубликованной конечной точки имеет форму UriScheme://IPAddressOrFQDN:Port/PathSuffix. UriScheme и PathSuffix являются необязательными атрибутами. IPAddressOrFQDN — это IP-адрес или полное доменное имя узла, на который помещается исполняемый файл, и вычисляется для вас.

В следующем примере после развертывания службы в Service Fabric Explorer отображается конечная точка, аналогичная http://10.1.4.92:3000/myapp/ публикации для экземпляра службы. Или если это локальный компьютер, вы видите http://localhost:3000/myapp/.

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

Эти адреса можно использовать с обратным прокси-сервером для обмена данными между службами.

Изменение файла манифеста приложения

После настройки Servicemanifest.xml файла необходимо внести некоторые изменения в 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="NodeAppType" ApplicationTypeVersion="1.0" xmlns="http://schemas.microsoft.com/2011/01/fabric">
   <ServiceManifestImport>
      <ServiceManifestRef ServiceManifestName="NodeApp" ServiceManifestVersion="1.0.0.0" />
   </ServiceManifestImport>
</ApplicationManifest>

ServiceManifestImport

В элементе ServiceManifestImport можно указать одну или несколько служб, которые необходимо включить в приложение. Службы ссылаются с ServiceManifestNameуказанием имени каталога, на который ServiceManifest.xml находится файл.

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

Настройка ведения журнала

Для гостевых исполняемых файлов полезно просмотреть журналы консоли, чтобы узнать, отображаются ли в скриптах приложения и конфигурации какие-либо ошибки. Перенаправление консоли можно настроить в ServiceManifest.xml файле с помощью ConsoleRedirection элемента.

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

Никогда не используйте политику перенаправления консоли в приложении, развернутом в рабочей среде, так как это может повлиять на отработку отказа приложения. Это используется только для локальных целей разработки и отладки.

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

ConsoleRedirection можно использовать для перенаправления выходных данных консоли (stdout и stderr) в рабочий каталог. Это позволяет убедиться, что во время установки или выполнения приложения в кластере Service Fabric отсутствуют ошибки.

FileRetentionCount определяет, сколько файлов сохраняется в рабочем каталоге. Значение 5, например, означает, что файлы журнала для предыдущих пяти выполнений хранятся в рабочем каталоге.

FileMaxSizeInKb указывает максимальный размер файлов журнала.

Файлы журналов сохраняются в одном из рабочих каталогов службы. Чтобы определить расположение файлов, используйте Service Fabric Explorer, чтобы определить узел, на котором работает служба, и какой рабочий каталог используется. Этот процесс рассматривается далее в этой статье.

Развертывание

Последним шагом является развертывание приложения. В следующем скрипте PowerShell показано, как развернуть приложение в локальном кластере разработки и запустить новую службу Service Fabric.


Connect-ServiceFabricCluster localhost:19000

Write-Host 'Copying application package...'
Copy-ServiceFabricApplicationPackage -ApplicationPackagePath 'C:\Dev\MultipleApplications' -ImageStoreConnectionString 'file:C:\SfDevCluster\Data\ImageStoreShare' -ApplicationPackagePathInImageStore 'nodeapp'

Write-Host 'Registering application type...'
Register-ServiceFabricApplicationType -ApplicationPathInImageStore 'nodeapp'

New-ServiceFabricApplication -ApplicationName 'fabric:/nodeapp' -ApplicationTypeName 'NodeAppType' -ApplicationTypeVersion 1.0

New-ServiceFabricService -ApplicationName 'fabric:/nodeapp' -ServiceName 'fabric:/nodeapp/nodeappservice' -ServiceTypeName 'NodeApp' -Stateless -PartitionSchemeSingleton -InstanceCount 1

Подсказка

Сжать пакет перед копированием в хранилище образов, если пакет большой или имеет много файлов. Дополнительные сведения см. здесь.

Службу Service Fabric можно развернуть в различных конфигурациях. Например, его можно развернуть как один или несколько экземпляров или развернуть таким образом, чтобы на каждом узле кластера Service Fabric существовал один экземпляр службы.

Параметр InstanceCount командлета New-ServiceFabricService используется для указания количества экземпляров службы, которые должны быть запущены в кластере Service Fabric. Значение можно задать InstanceCount в зависимости от типа развертываемого приложения. Ниже приведены два наиболее распространенных сценария:

InstanceCount = "1". В этом случае в кластере развертывается только один экземпляр службы. Планировщик Service Fabric определяет, на каком узле будет развернута служба.
InstanceCount ="-1". В этом случае на каждом узле в кластере Service Fabric развертывается один экземпляр службы. Результатом является один (и только один) экземпляр службы для каждого узла в кластере.

Это полезная конфигурация для интерфейсных приложений (например, конечной точки REST), так как клиентские приложения должны подключаться к любому из узлов в кластере для использования конечной точки. Эту конфигурацию также можно использовать, если, например, все узлы кластера Service Fabric подключены к подсистеме балансировки нагрузки. Затем трафик клиента можно распределить по службе, работающей на всех узлах кластера.

Проверка запущенного приложения

В Service Fabric Explorer определите узел, в котором выполняется служба. В этом примере он выполняется в Node1:

Узел, где выполняется служба

Если перейти к узлу и перейти к приложению, вы увидите необходимые сведения о узле, включая его расположение на диске.

Расположение на диске

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

Расположение журнала

Дальнейшие действия

Из этой статьи вы узнали, как упаковать гостевой исполняемый файл и развернуть его в Service Fabric. Дополнительные сведения и задачи см. в следующих статьях.

Пример упаковки и развертывания гостевого исполняемого файла, включая ссылку на предварительную версию средства упаковки
Пример двух гостевых исполняемых файлов (C# и nodejs), взаимодействующих через службу именования с помощью REST
Создание первого приложения Service Fabric с помощью Visual Studio