Udostępnij za pośrednictwem

Manifesty aplikacji i usługi Service Fabric

  • Artykuł

W tym artykule opisano sposób, w jaki aplikacje i usługi Service Fabric są definiowane i wersjonowane przy użyciu plików ApplicationManifest.xml i ServiceManifest.xml. Aby uzyskać bardziej szczegółowe przykłady, zobacz przykłady manifestu aplikacji i usługi. Schemat XML dla tych plików manifestu jest udokumentowany w dokumentacji schematu ServiceFabricServiceModel.xsd.

Ostrzeżenie

Schemat pliku XML manifestu wymusza prawidłową kolejność elementów podrzędnych. W ramach częściowego obejścia otwórz plik "C:\Program Files\Microsoft SDKs\Service Fabric\schemas\ServiceFabricServiceModel.xsd" w programie Visual Studio podczas tworzenia lub modyfikowania dowolnego manifestu usługi Service Fabric. Pozwoli to sprawdzić kolejność elementów podrzędnych i zapewnić funkcję intelli-sense.

Opisywanie usługi w ServiceManifest.xml

Manifest usługi deklaratywnie definiuje typ i wersję usługi. Określa metadane usługi, takie jak typ usługi, właściwości kondycji, metryki równoważenia obciążenia, pliki binarne usługi i pliki konfiguracji. W inny sposób opisuje on kod, konfigurację i pakiety danych, które tworzą pakiet usługi do obsługi co najmniej jednego typu usługi. Manifest usługi może zawierać wiele pakietów kodu, konfiguracji i danych, które mogą być wersjonowane niezależnie. Oto manifest usługi dla usługi frontonu internetowego platformy ASP.NET Core przykładowej aplikacji do głosowania (a oto kilka bardziej szczegółowych przykładów):

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

Atrybuty wersji są ciągami bez struktury i nie są analizowane przez system. Atrybuty wersji są używane do przechowywania wersji każdego składnika na potrzeby uaktualnień.

ServiceTypes deklaruje, jakie typy usług są obsługiwane przez pakiety CodePackage w tym manifeście. Po utworzeniu wystąpienia usługi względem jednego z tych typów usług wszystkie pakiety kodu zadeklarowane w tym manifeście są aktywowane przez uruchomienie punktów wejścia. Oczekuje się, że wynikowe procesy będą rejestrować obsługiwane typy usług w czasie wykonywania. Typy usług są deklarowane na poziomie manifestu, a nie na poziomie pakietu kodu. Dlatego gdy istnieje wiele pakietów kodu, wszystkie są aktywowane za każdym razem, gdy system szuka dowolnego z zadeklarowanych typów usług.

Plik wykonywalny określony przez program EntryPoint jest zazwyczaj długotrwałym hostem usługi. SetupEntryPoint to uprzywilejowany punkt wejścia, który działa z tymi samymi poświadczeniami co usługa Service Fabric (zazwyczaj konto LocalSystem ) przed innym punktem wejścia. 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 program EntryPoint jest uruchamiany po pomyślnym zakończeniu instalacjiEntryPoint . Jeśli proces kiedykolwiek zakończy się lub ulegnie awarii, wynikowy proces jest monitorowany i uruchamiany ponownie (począwszy od setupEntryPoint).

Typowe scenariusze korzystania z programu SetupEntryPoint są wykonywane podczas uruchamiania pliku wykonywalnego przed uruchomieniem usługi lub wykonanie operacji z podwyższonym poziomem uprawnień. Na przykład:

  • Konfigurowanie i inicjowanie zmiennych środowiskowych, których potrzebuje plik wykonywalny usługi. Nie jest to ograniczone tylko do plików wykonywalnych napisanych za pośrednictwem modeli programowania usługi Service Fabric. Na przykład npm.exe wymaga pewnych zmiennych środowiskowych skonfigurowanych do wdrażania aplikacji Node.js.
  • Konfigurowanie kontroli dostępu przez zainstalowanie certyfikatów zabezpieczeń.

Aby uzyskać więcej informacji na temat konfigurowania programu SetupEntryPoint, zobacz Konfigurowanie zasad punktu wejścia konfiguracji usługi.

Atrybuty EnvironmentVariables (nie ustawiono w poprzednim przykładzie) zawierają listę zmiennych środowiskowych ustawionych dla tego pakietu kodu. Zmienne środowiskowe można przesłonić w pliku , ApplicationManifest.xml aby zapewnić różne wartości dla różnych wystąpień usługi.

Pakiet DataPackage (nie ustawiony w poprzednim przykładzie) deklaruje folder o nazwie według atrybutu Name , który zawiera dowolne dane statyczne, które mają być używane przez proces w czasie wykonywania.

Pakiet ConfigPackage deklaruje folder o nazwie według atrybutu Name , który zawiera plik Settings.xml . Plik ustawień zawiera sekcje ustawień pary klucz-wartość zdefiniowane przez użytkownika, które proces odczytuje z powrotem w czasie wykonywania. Podczas uaktualniania, jeśli tylko wersja pakietu ConfigPackage ulegnie zmianie, 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. Oto przykładowy plik Settings.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>

Punkt końcowy usługi Service Fabric to przykład zasobu usługi Service Fabric. Zasób usługi Service Fabric można zadeklarować/zmienić bez zmiany skompilowanego kodu. Dostęp do zasobów usługi Service Fabric określonych w manifeście usługi można kontrolować za pośrednictwem grupy zabezpieczeń w manifeście aplikacji. Gdy zasób punktu końcowego jest zdefiniowany w manifeście usługi, usługa Service Fabric przypisuje porty z zakresu portów aplikacji zarezerwowanej, gdy port nie jest jawnie określony. Przeczytaj więcej na temat określania lub zastępowania zasobów punktu końcowego.

Ostrzeżenie

Zgodnie z projektem porty statyczne nie powinny nakładać się na zakres portów aplikacji określony w pliku ClusterManifest. Jeśli określisz port statyczny, przypisz go poza zakresem portów aplikacji, w przeciwnym razie spowoduje to konflikty portów. W wersji 6.5CU2 wydamy ostrzeżenie o kondycji, gdy wykryjemy taki konflikt, ale niech wdrożenie będzie nadal synchronizowane z dostarczonym zachowaniem wersji 6.5. Możemy jednak uniemożliwić wdrożenie aplikacji w następnych głównych wersjach.

Opisywanie aplikacji w ApplicationManifest.xml

Manifest aplikacji deklaratywnie opisuje typ i wersję aplikacji. Określa metadane kompozycji usługi, takie jak stabilne nazwy, schemat partycjonowania, liczba wystąpień/współczynnik replikacji, zasady zabezpieczeń/izolacji, ograniczenia umieszczania, przesłonięcia konfiguracji i typy usług składowych. Domeny równoważenia obciążenia, w których jest umieszczona aplikacja, są również opisane.

W związku z tym manifest aplikacji opisuje elementy na poziomie aplikacji i odwołuje się do co najmniej jednego manifestu usługi w celu utworzenia typu aplikacji. Oto manifest aplikacji dla przykładowej aplikacji voting (a oto kilka bardziej szczegółowych przykładów):

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

Podobnie jak manifesty usługi, atrybuty wersji są ciągami bez struktury i nie są analizowane przez system. Atrybuty wersji są również używane do wersji każdego składnika na potrzeby uaktualnień.

Parametry definiują parametry używane w manifeście aplikacji. Wartości tych parametrów można podać po utworzeniu wystąpienia aplikacji i zastąpić ustawienia konfiguracji aplikacji lub usługi. Wartość parametru domyślnego jest używana, jeśli wartość nie zostanie zmieniona podczas tworzenia wystąpienia aplikacji. Aby dowiedzieć się, jak zachować różne parametry aplikacji i usługi dla poszczególnych środowisk, zobacz Zarządzanie parametrami aplikacji dla wielu środowisk.

ServiceManifestImport zawiera odwołania do manifestów usługi tworzących ten typ aplikacji. Manifest aplikacji może zawierać wiele importów manifestu usługi, a każdy z nich może być niezależnie wersjonowany. Zaimportowane manifesty usługi określają, jakie typy usług są prawidłowe w ramach tego typu aplikacji. W pliku ServiceManifestImport wartości konfiguracji są zastępowane w Settings.xml i zmiennych środowiskowych w plikach ServiceManifest.xml. Zasady (nie są ustawione w poprzednim przykładzie) dla powiązania punktu końcowego, zabezpieczeń i dostępu oraz udostępniania pakietów można ustawić dla importowanych manifestów usługi. Aby uzyskać więcej informacji, zobacz Konfigurowanie zasad zabezpieczeń dla aplikacji.

DefaultServices deklaruje wystąpienia usługi, które są tworzone automatycznie za każdym razem, gdy aplikacja jest tworzona na podstawie tego typu aplikacji. Usługi domyślne są po prostu wygodą i zachowują się jak zwykłe usługi pod każdym względem po ich utworzeniu. Są one uaktualniane wraz z innymi usługami w wystąpieniu aplikacji i można je również usunąć. Manifest aplikacji może zawierać wiele usług domyślnych.

Ostrzeżenie

Wartość DefaultServices jest przestarzała na rzecz .StartupServices.xml Więcej informacji na temat StartupServices.xml można przeczytać w temacie Introducing StartupServices.xml in Service Fabric Application (Wprowadzenie do StartupServices.xml w aplikacji usługi Service Fabric).

Certyfikaty (nie są ustawione w poprzednim przykładzie) deklaruje certyfikaty używane do konfigurowania punktów końcowych HTTPS lub szyfrowania wpisów tajnych w manifeście aplikacji.

Ograniczenia umieszczania to instrukcje definiujące, gdzie powinny być uruchamiane usługi. Te instrukcje są dołączane do poszczególnych usług wybranych dla co najmniej jednej właściwości węzła. Aby uzyskać więcej informacji, zobacz Ograniczenia umieszczania i składnia właściwości węzła.

Zasady (nie są ustawione w poprzednim przykładzie) opisują zbieranie dzienników, domyślne zasady uruchamiania jako, kondycji i dostępu zabezpieczeń do ustawiania na poziomie aplikacji, w tym tego, czy usługi mają dostęp do środowiska uruchomieniowego usługi Service Fabric.

Uwaga

Klaster usługi Service Fabric jest jedną dzierżawą zgodnie z projektem, a hostowane aplikacje są uznawane za zaufane. Jeśli rozważasz hostowanie niezaufanych aplikacji, zobacz Hosting niezaufanych aplikacji w klastrze usługi Service Fabric.

Podmioty zabezpieczeń (nie ustawione w poprzednim przykładzie) opisują podmioty zabezpieczeń (użytkowników lub grupy) wymagane do uruchamiania usług i zabezpieczania zasobów usług. Podmioty zabezpieczeń są przywołyne w sekcjach Zasady .

Następne kroki