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

Artykuł
08/25/2024

Podczas pakowania 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.

Napiwek

Najprostszym sposobem spakowania istniejącego pliku wykonywalnego systemu Windows do usługi jest użycie programu Visual Studio i w systemie 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 za pomocą pliku wykonywalnego i wypełnić pozostałe parametry, aby utworzyć usługę.
- Zachowanie pakietu kodu. Można ustawić opcję kopiowania całej zawartości 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 dynamicznie pobierać nowe kompilacje, 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 poziomu 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 w kompilacji.
- Program określa plik wykonywalny, który ma zostać uruchomiony, aby uruchomić usługę.
- Argumenty określają argumenty, które powinny być przekazywane do pliku wykonywalnego. Może to być lista parametrów z argumentami.
- Folder roboczy 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 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 o nazwie work.
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 sprawdzanie uruchomionej aplikacji , aby zobaczyć, jak wyświetlić usługę wykonywalną gościa uruchomioną w narzędziu Service Fabric Explorer.

Aby zapoznać się z przykładowym przewodnikiem, zobacz Tworzenie pierwszej aplikacji wykonywalnego gościa przy użyciu programu Visual Studio.

Tworzenie pakietów 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, kompilowanie rozwiązania 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 oraz 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.

Tworzenie pakietów 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 kod i pliki 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ć kod i pliki konfiguracji aplikacji w ramach kodu i katalogów konfiguracji. Możesz również utworzyć dodatkowe katalogi lub podkatalogi w kodzie lub katalogach konfiguracji.

Usługa Service Fabric wykonuje xcopy zawartość katalogu głównego aplikacji, dlatego nie ma wstępnie zdefiniowanej struktury do użycia innej niż tworzenie dwóch najważniejszych katalogów, kodu i ustawień. (Jeśli chcesz, możesz wybrać różne nazwy. Więcej szczegółów znajduje się w następnej sekcji).

Uwaga

Upewnij się, że wszystkie pliki i zależności są uwzględniane 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).

Oto 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 opisano 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 ApplicationManifest.xml pliku do identyfikowania usługi.
Podaj wartość UseImplicitHost="true". Ten atrybut informuje usługę Service Fabric, że usługa jest oparta na aplikacji samodzielnej, więc wszystkie usługi Service Fabric muszą być uruchamiane jako proces i monitorować jego 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 potencjalnie 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 dowolnego pliku wykonywalnego lub wsadowego, który ma zostać wykonany przed uruchomieniem kodu usługi. Jest to krok opcjonalny, więc nie trzeba go uwzględniać, jeśli nie jest wymagana inicjalizacja. InstalatorEntryPoint jest wykonywany za każdym razem, gdy usługa jest ponownie uruchamiana.

Istnieje tylko jeden program SetupEntryPoint, dlatego skrypty konfiguracji należy zgrupować 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órego należy użyć do uruchomienia usługi. Opcjonalnie możesz dodać IsExternalExecutable="true" atrybut , aby ExeHost wskazać, ż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 mają być przekazywane 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 zostanie 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 prawidłowego katalogu roboczego, aby ścieżki względne mogły być używane przez skrypty aplikacji lub inicjowania.

Aktualizowanie punktów końcowych i rejestrowanie 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 porcie http na porcie 3000.

Ponadto możesz poprosić usługę Service Fabric o opublikowanie tego punktu końcowego w usłudze Nazewnictwa, aby inne usługi mogły odnaleźć adres punktu końcowego dla 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 zostaje umieszczony ten plik wykonywalny, i jest obliczany dla Ciebie.

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

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

Tych adresów można używać 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 poprawny 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 warto zobaczyć dzienniki konsoli, aby dowiedzieć się, 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 narzędzia 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

Napiwek

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

Usługę Service Fabric można wdrożyć w różnych "konfiguracjach". Można go na przykład wdrożyć jako pojedyncze lub wiele wystąpień albo 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 InstanceCount New-ServiceFabricService polecenia cmdlet służy do określania, ile wystąpień usługi należy uruchomić 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 w 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 dowolnymi węzłami w klastrze w celu korzystania z punktu końcowego. Ta konfiguracja może być również używana, 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żna następnie dystrybuować między usługę uruchomioną we wszystkich węzłach w klastrze.

Sprawdzanie uruchomionej aplikacji

W narzędziu Service Fabric Explorer zidentyfikuj węzeł, w którym jest uruchomiona usługa. W tym przykładzie jest uruchamiany 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 przeglądasz katalog 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

Udostępnij za pośrednictwem