Pakowanie i wdrażanie istniejącego pliku wykonywalnego w usłudze Service Fabric

Artykuł
06/01/2023

Podczas tworzenia istniejącego pliku wykonywalnego jako pliku wykonywalnego gościa możesz użyć szablonu projektu programu Visual Studio lub ręcznie utworzyć pakiet aplikacji. Za pomocą programu Visual Studio struktura pakietu aplikacji i pliki manifestu są tworzone przez nowy szablon projektu.

Porada

Najprostszym sposobem spakowania istniejącego pliku wykonywalnego systemu Windows do usługi jest użycie programu Visual Studio i systemu Linux do korzystania z narzędzia Yeoman

Tworzenie pakietów i wdrażanie istniejącego pliku wykonywalnego przy użyciu programu Visual Studio

Program Visual Studio udostępnia szablon usługi Service Fabric, który ułatwia wdrażanie pliku wykonywalnego gościa w klastrze usługi Service Fabric.

Wybierz pozycję Plik>nowy projekt i utwórz aplikację usługi Service Fabric.
Wybierz pozycję Plik wykonywalny gościa jako szablon usługi.
Kliknij przycisk Przeglądaj , aby wybrać folder z plikiem wykonywalny i wypełnić pozostałe parametry, aby utworzyć usługę.
- Zachowanie pakietu kodu. Można ustawić, aby skopiować całą zawartość folderu do projektu programu Visual Studio, co jest przydatne, jeśli plik wykonywalny nie ulegnie zmianie. Jeśli oczekujesz, że plik wykonywalny zmieni się i chcesz, aby umożliwić dynamiczne pobieranie nowych kompilacji, możesz zamiast tego połączyć się z folderem. Foldery połączone można używać podczas tworzenia projektu aplikacji w programie Visual Studio. Spowoduje to połączenie z lokalizacją źródłową z projektu, dzięki czemu można zaktualizować plik wykonywalny gościa w jego lokalizacji źródłowej. Te aktualizacje stają się częścią pakietu aplikacji na kompilacji.
- Program określa plik wykonywalny, który należy uruchomić, aby uruchomić usługę.
- Argumenty określają argumenty, które powinny zostać przekazane do pliku wykonywalnego. Może to być lista parametrów z argumentami.
- Folder roboczy określa katalog roboczy procesu, który zostanie uruchomiony. Można określić trzy wartości:
  - CodeBase Określa, że katalog roboczy zostanie ustawiony na katalog kodu w pakiecie aplikacji (Code katalog pokazany w poprzedniej strukturze plików).
  - CodePackage określa, że katalog roboczy zostanie ustawiony na katalog główny pakietu aplikacji (GuestService1Pkg pokazany w poprzedniej strukturze plików).
  - Work określa, że pliki są umieszczane w podkatalogu nazywanym pracą.
Nadaj nazwę usłudze i kliknij przycisk OK.
Jeśli usługa potrzebuje punktu końcowego do komunikacji, możesz teraz dodać protokół, port i typ do pliku ServiceManifest.xml. Na przykład: <Endpoint Name="NodeAppTypeEndpoint" Protocol="http" Port="3000" UriScheme="http" PathSuffix="myapp/" Type="Input" />.
Teraz możesz użyć akcji pakietu i publikowania względem klastra lokalnego, debugując rozwiązanie w programie Visual Studio. Gdy wszystko będzie gotowe, możesz opublikować aplikację w klastrze zdalnym lub zaewidencjonować rozwiązanie w celu kontroli źródła.
Przeczytaj artykuł Sprawdź uruchomioną aplikację, aby zobaczyć, jak wyświetlić usługę wykonywalną gościa uruchomioną w Service Fabric Explorer.

Przykładowy przewodnik można znaleźć w temacie Create your first guest wykonywalny application using Visual Studio (Tworzenie pierwszej aplikacji wykonywalnego gościa przy użyciu programu Visual Studio).

Pakowanie wielu plików wykonywalnych za pomocą programu Visual Studio

Program Visual Studio umożliwia utworzenie pakietu aplikacji zawierającego wiele plików wykonywalnych gościa. Po dodaniu pierwszego pliku wykonywalnego gościa kliknij prawym przyciskiem myszy projekt aplikacji i wybierz usługę Add-New> Service Fabric , aby dodać drugi projekt wykonywalny gościa do rozwiązania.

Uwaga

Jeśli zdecydujesz się połączyć źródło w projekcie programu Visual Studio, sbudować rozwiązanie programu Visual Studio, upewnij się, że pakiet aplikacji jest aktualny ze zmianami w źródle.

Tworzenie pakietów i wdrażanie istniejącego pliku wykonywalnego w systemie Linux przy użyciu narzędzia Yeoman

Procedura tworzenia i wdrażania pliku wykonywalnego gościa w systemie Linux jest taka sama jak wdrażanie aplikacji języka C# lub Java.

Na terminalu wpisz yo azuresfguest.
Nadaj nazwę aplikacji.
Nadaj usłudze nazwę i podaj szczegóły, w tym ścieżkę pliku wykonywalnego i parametry, z których musi być wywoływana.

Narzędzie Yeoman tworzy pakiet aplikacji z odpowiednimi plikami aplikacji i manifestu wraz ze skryptami instalowania i odinstalowywania.

Pakowanie wielu plików wykonywalnych przy użyciu narzędzia Yeoman w systemie Linux

Aby dodać kolejną usługę do aplikacji utworzonej już przy użyciu polecenia yo, wykonaj następujące czynności:

Zmień katalog na katalog główny istniejącej aplikacji. Na przykład wpisz polecenie cd ~/YeomanSamples/MyApplication, jeśli aplikacja MyApplication to aplikacja utworzona przez narzędzie Yeoman.
Uruchom yo azuresfguest:AddService polecenie i podaj niezbędne szczegóły.

Ręczne pakowanie i wdrażanie istniejącego pliku wykonywalnego

Proces ręcznego pakowania pliku wykonywalnego gościa jest oparty na następujących ogólnych krokach:

Utwórz strukturę katalogu pakietów.
Dodaj pliki kodu i konfiguracji aplikacji.
Edytuj plik manifestu usługi.
Edytuj plik manifestu aplikacji.

Tworzenie struktury katalogów pakietów

Możesz zacząć od utworzenia struktury katalogów zgodnie z opisem w temacie Package an Azure Service Fabric App (Tworzenie pakietu aplikacji usługi Azure Service Fabric).

Dodawanie kodu i plików konfiguracji aplikacji

Po utworzeniu struktury katalogów można dodać pliki kodu i konfiguracji aplikacji w katalogach kodu i konfiguracji. Możesz również utworzyć dodatkowe katalogi lub podkatalogi w ramach katalogów kodu lub konfiguracji.

Usługa Service Fabric wykonuje xcopy zawartość katalogu głównego aplikacji, więc nie ma wstępnie zdefiniowanej struktury do użycia poza tworzeniem dwóch głównych katalogów, kodu i ustawień. (Możesz wybrać różne nazwy, jeśli chcesz. Więcej szczegółów znajduje się w następnej sekcji).

Uwaga

Upewnij się, że uwzględnisz wszystkie pliki i zależności wymagane przez aplikację. Usługa Service Fabric kopiuje zawartość pakietu aplikacji na wszystkich węzłach w klastrze, w którym będą wdrażane usługi aplikacji. Pakiet powinien zawierać cały kod, który musi zostać uruchomiony przez aplikację. Nie zakładaj, że zależności są już zainstalowane.

Edytowanie pliku manifestu usługi

Następnym krokiem jest edytowanie pliku manifestu usługi w celu uwzględnienia następujących informacji:

Nazwa typu usługi. Jest to identyfikator używany przez usługę Service Fabric do identyfikowania usługi.
Polecenie do uruchomienia aplikacji (ExeHost).
Każdy skrypt, który należy uruchomić, aby skonfigurować aplikację (SetupEntrypoint).

Poniżej przedstawiono przykład ServiceManifest.xml pliku:

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

W poniższych sekcjach przedstawiono różne części pliku, które należy zaktualizować.

Aktualizowanie typów usługi

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

Możesz wybrać dowolną nazwę dla ServiceTypeNameelementu . Wartość jest używana w pliku do ApplicationManifest.xml identyfikowania usługi.
Podaj wartość UseImplicitHost="true". Ten atrybut informuje usługę Service Fabric, że usługa jest oparta na samodzielnej aplikacji, dlatego należy uruchomić ją jako proces i monitorować jej kondycję.

Aktualizowanie pakietu CodePackage

Element CodePackage określa lokalizację (i wersję) kodu usługi.

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

Element Name służy do określania nazwy katalogu w pakiecie aplikacji, który zawiera kod usługi. CodePackage ma version również atrybut . Może to służyć do określania wersji kodu, a także może służyć do uaktualniania kodu usługi przy użyciu infrastruktury zarządzania cyklem życia aplikacji w usłudze Service Fabric.

Opcjonalnie: Aktualizacja SetupEntrypoint

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

Element SetupEntryPoint służy do określania pliku wykonywalnego lub wsadowego, który powinien zostać wykonany przed uruchomieniem kodu usługi. Jest to opcjonalny krok, więc nie trzeba go uwzględniać, jeśli nie jest wymagana inicjacja. InstalatorEntryPoint jest wykonywany za każdym razem, gdy usługa jest ponownie uruchamiana.

Istnieje tylko jeden program SetupEntryPoint, dlatego skrypty konfiguracji muszą być pogrupowane w jednym pliku wsadowym, jeśli konfiguracja aplikacji wymaga wielu skryptów. InstalatorEntryPoint może wykonywać dowolny typ pliku: pliki wykonywalne, pliki wsadowe i polecenia cmdlet programu PowerShell. Aby uzyskać więcej informacji, zobacz Konfigurowanie instalatoraEntryPoint.

W poprzednim przykładzie instalatorEntryPoint uruchamia plik wsadowy o nazwie LaunchConfig.cmd , który znajduje się w scripts podkatalogu katalogu kodu (przy założeniu, że element WorkingFolder jest ustawiony na CodeBase).

Aktualizowanie programu EntryPoint

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

Element EntryPoint w pliku manifestu usługi służy do określania sposobu uruchamiania usługi.

Element ExeHost określa plik wykonywalny (i argumenty), który powinien służyć do uruchamiania usługi. Opcjonalnie można dodać IsExternalExecutable="true" atrybut , aby wskazać ExeHost , że program jest zewnętrznym plikiem wykonywalnym poza pakietem kodu. Na przykład <ExeHost IsExternalExecutable="true">.

Program określa nazwę pliku wykonywalnego, który powinien uruchomić usługę.
Arguments określa argumenty, które powinny zostać przekazane do pliku wykonywalnego. Może to być lista parametrów z argumentami.
WorkingFolder określa katalog roboczy procesu, który ma zostać uruchomiony. Można określić trzy wartości:
- CodeBase określa, że katalog roboczy zostanie ustawiony na katalog kodu w pakiecie aplikacji (Code katalog w poprzedniej strukturze plików).
- CodePackage Określa, że katalog roboczy ma zostać ustawiony na katalog główny pakietu aplikacji (GuestService1Pkg w poprzedniej strukturze plików).
  - Work określa, że pliki są umieszczane w podkatalogu o nazwie work.

Folder Roboczy jest przydatny do ustawiania poprawnego katalogu roboczego, dzięki czemu ścieżki względne mogą być używane przez aplikację lub skrypty inicjowania.

Aktualizowanie punktów końcowych i rejestrowanie się w usłudze Naming Service na potrzeby komunikacji

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

W poprzednim przykładzie element określa punkty końcowe, Endpoint na których aplikacja może nasłuchiwać. W tym przykładzie aplikacja Node.js nasłuchuje na http na porcie 3000.

Ponadto możesz poprosić usługę Service Fabric o opublikowanie tego punktu końcowego w usłudze Naming Service, aby inne usługi mogły odnaleźć adres punktu końcowego tej usługi. Dzięki temu można komunikować się między usługami, które są plikami wykonywalnych gościa. Opublikowany adres punktu końcowego ma postać UriScheme://IPAddressOrFQDN:Port/PathSuffix. UriScheme i PathSuffix są atrybutami opcjonalnymi. IPAddressOrFQDN to adres IP lub w pełni kwalifikowana nazwa domeny węzła, na którym jest umieszczany ten plik wykonywalny i jest obliczany dla Ciebie.

W poniższym przykładzie po wdrożeniu usługi w Service Fabric Explorer zobaczysz punkt końcowy podobny do http://10.1.4.92:3000/myapp/ opublikowanego dla wystąpienia usługi. Jeśli jest to komputer lokalny, zostanie wyświetlony komunikat http://localhost:3000/myapp/.

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

Możesz użyć tych adresów z zwrotnym serwerem proxy do komunikacji między usługami.

Edytowanie pliku manifestu aplikacji

Po skonfigurowaniu Servicemanifest.xml pliku należy wprowadzić pewne zmiany w ApplicationManifest.xml pliku, aby upewnić się, że używany jest prawidłowy typ usługi i nazwa.

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

W elemecie ServiceManifestImport możesz określić co najmniej jedną usługę, którą chcesz uwzględnić w aplikacji. Do usług odwołuje się ServiceManifestNameelement , który określa nazwę katalogu, w ServiceManifest.xml którym znajduje się plik.

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

Konfigurowanie rejestrowania

W przypadku plików wykonywalnych gościa przydatne jest wyświetlanie dzienników konsoli w celu sprawdzenia, czy w skryptach aplikacji i konfiguracji są wyświetlane błędy. Przekierowanie konsoli można skonfigurować w ServiceManifest.xml pliku przy użyciu ConsoleRedirection elementu .

Ostrzeżenie

Nigdy nie używaj zasad przekierowania konsoli w aplikacji wdrożonej w środowisku produkcyjnym, ponieważ może to mieć wpływ na tryb failover aplikacji. Tej opcji należy używać tylko do celów programowania lokalnego i debugowania.

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

ConsoleRedirection Może służyć do przekierowywania danych wyjściowych konsoli (stdout i stderr) do katalogu roboczego. Dzięki temu można sprawdzić, czy podczas instalacji lub wykonywania aplikacji w klastrze usługi Service Fabric nie występują żadne błędy.

FileRetentionCount określa, ile plików jest zapisywanych w katalogu roboczym. Wartość 5 oznacza na przykład, że pliki dziennika dla poprzednich pięciu wykonań są przechowywane w katalogu roboczym.

FileMaxSizeInKb określa maksymalny rozmiar plików dziennika.

Pliki dziennika są zapisywane w jednym z katalogów roboczych usługi. Aby określić, gdzie znajdują się pliki, użyj Service Fabric Explorer, aby określić węzeł, w którym jest uruchomiona usługa, i który katalog roboczy jest używany. Ten proces został omówiony w dalszej części tego artykułu.

Wdrożenie

Ostatnim krokiem jest wdrożenie aplikacji. Poniższy skrypt programu PowerShell pokazuje, jak wdrożyć aplikację w lokalnym klastrze programistycznym i uruchomić nową usługę 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

Porada

Skompresuj pakiet przed skopiowaniem do magazynu obrazów, jeśli pakiet jest duży lub ma wiele plików. Przeczytaj więcej tutaj.

Usługę Service Fabric można wdrożyć w różnych "konfiguracjach". Na przykład można go wdrożyć jako pojedyncze lub wiele wystąpień lub można go wdrożyć w taki sposób, aby w każdym węźle klastra usługi Service Fabric istniało jedno wystąpienie usługi.

Parametr InstanceCountNew-ServiceFabricService polecenia cmdlet służy do określania, ile wystąpień usługi ma zostać uruchomionych w klastrze usługi Service Fabric. Możesz ustawić InstanceCount wartość w zależności od typu wdrażanej aplikacji. Dwa najbardziej typowe scenariusze to:

InstanceCount = "1". W takim przypadku w klastrze jest wdrażane tylko jedno wystąpienie usługi. Harmonogram usługi Service Fabric określa węzeł, w którym ma zostać wdrożona usługa.
InstanceCount ="-1". W takim przypadku jedno wystąpienie usługi jest wdrażane na każdym węźle w klastrze usługi Service Fabric. Wynik ma jedno (i tylko jedno) wystąpienie usługi dla każdego węzła w klastrze.

Jest to przydatna konfiguracja dla aplikacji frontonu (na przykład punktu końcowego REST), ponieważ aplikacje klienckie muszą "łączyć się" z dowolnym węzłem w klastrze w celu korzystania z punktu końcowego. Tej konfiguracji można również użyć, gdy na przykład wszystkie węzły klastra usługi Service Fabric są połączone z modułem równoważenia obciążenia. Ruch klienta może być następnie dystrybuowany przez usługę uruchomioną we wszystkich węzłach w klastrze.

Sprawdzanie uruchomionej aplikacji

W Service Fabric Explorer zidentyfikuj węzeł, w którym jest uruchomiona usługa. W tym przykładzie działa on w środowisku Node1:

Węzeł, w którym jest uruchomiona usługa

Jeśli przejdziesz do węzła i przejdziesz do aplikacji, zobaczysz podstawowe informacje o węźle, w tym jego lokalizację na dysku.

Lokalizacja na dysku

Jeśli przechodzisz do katalogu przy użyciu Eksploratora serwera, możesz znaleźć katalog roboczy i folder dziennika usługi, jak pokazano na poniższym zrzucie ekranu:

Lokalizacja dziennika

Następne kroki

W tym artykule przedstawiono sposób tworzenia pakietu pliku wykonywalnego gościa i wdrażania go w usłudze Service Fabric. Zapoznaj się z następującymi artykułami, aby uzyskać powiązane informacje i zadania.

Przykład tworzenia pakietów i wdrażania pliku wykonywalnego gościa, w tym linku do wersji wstępnej narzędzia do tworzenia pakietów
Przykład dwóch plików wykonywalnych gościa (C# i nodejs) komunikujących się za pośrednictwem usługi Naming przy użyciu interfejsu REST
Tworzenie pierwszej aplikacji usługi Service Fabric przy użyciu programu Visual Studio