Uruchamianie skryptu uruchamiania usługi za pomocą użytkownika lokalnego lub konta systemowego

Przed uruchomieniem pliku wykonywalnego usługi Service Fabric może być konieczne uruchomienie pewnej konfiguracji lub pracy z konfiguracją. Na przykład konfigurowanie zmiennych środowiskowych. Można określić skrypt do uruchomienia przed uruchomieniem pliku wykonywalnego usługi w manifeście usługi dla usługi. Konfigurując zasady Uruchom jako dla punktu wejścia konfiguracji usługi, można zmienić konto, w którym działa plik wykonywalny instalatora. Oddzielny punkt wejścia konfiguracji umożliwia uruchamianie konfiguracji o wysokim poziomie uprawnień przez krótki czas, dzięki czemu plik wykonywalny hosta usługi nie musi działać z wysokimi uprawnieniami przez dłuższy czas.

Punkt wejścia instalacji (SetupEntryPoint w manifeście usługi) jest uprzywilejowanym punktem wejścia, który domyślnie jest uruchamiany z tymi samymi poświadczeniami co usługa Service Fabric (zazwyczaj konto usługi sieciowej ) przed innym punktem wejścia. Plik wykonywalny określony przez program EntryPoint jest zazwyczaj długotrwałym hostem usługi. Plik wykonywalny programu EntryPoint jest uruchamiany po pomyślnym zakończeniu działania pliku wykonywalnego SetupEntryPoint . Wynikowy proces jest monitorowany i uruchamiany ponownie, a następnie rozpoczyna się od setupEntryPoint , jeśli kiedykolwiek zakończy działanie lub ulegnie awarii.

Konfigurowanie punktu wejścia usługi instalatora

Poniżej przedstawiono prosty przykład manifestu usługi dla usługi bezstanowej, która określa skrypt instalacji MySetup.bat w instalacji usługiEntryPoint. Argumenty są używane do przekazywania argumentów do skryptu podczas jego uruchamiania.

<?xml version="1.0" encoding="utf-8"?>
<ServiceManifest Name="MyStatelessServicePkg"
                 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">
  <Description>An example service manifest.</Description>
  <ServiceTypes>
    <StatelessServiceType ServiceTypeName="MyStatelessServiceType" />
  </ServiceTypes>

  <!-- Code package is your service executable. -->
  <CodePackage Name="Code" Version="1.0.0">
    <SetupEntryPoint>
      <ExeHost>
        <Program>MySetup.bat</Program>
        <Arguments>MyValue</Arguments>
        <WorkingFolder>Work</WorkingFolder>        
      </ExeHost>
    </SetupEntryPoint>
    <EntryPoint>
      <ExeHost>
        <Program>MyStatelessService.exe</Program>
      </ExeHost>
    </EntryPoint>
  </CodePackage>

  <ConfigPackage Name="Config" Version="1.0.0" />

  <Resources>
    <Endpoints>
      <Endpoint Name="ServiceEndpoint" />
    </Endpoints>
  </Resources>
</ServiceManifest>

Konfigurowanie zasad dla punktu wejścia konfiguracji usługi

Domyślnie plik wykonywalny punktu wejścia konfiguracji usługi jest uruchamiany w ramach tych samych poświadczeń co usługa Service Fabric (zazwyczaj konto NetworkService ). W manifeście aplikacji można zmienić uprawnienia zabezpieczeń, aby uruchomić skrypt uruchamiania na lokalnym koncie systemowym lub koncie administratora.

Konfigurowanie zasad przy użyciu konta systemu lokalnego

Poniższy przykład manifestu aplikacji pokazuje, jak skonfigurować punkt wejścia konfiguracji usługi do uruchamiania na koncie administratora użytkownika (SetupAdminUser).

<?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="MyApplicationType" ApplicationTypeVersion="1.0.0" xmlns="http://schemas.microsoft.com/2011/01/fabric">
  <Parameters>
    <Parameter Name="MyStatelessService_InstanceCount" DefaultValue="-1" />
  </Parameters>
  <ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName="MyStatelessServicePkg" ServiceManifestVersion="1.0.0" />
    <ConfigOverrides />
    <Policies>
      <RunAsPolicy CodePackageRef="Code" UserRef="SetupAdminUser" EntryPointType="Setup" />
    </Policies>
  </ServiceManifestImport>
  <DefaultServices>
    <Service Name="MyStatelessService" ServicePackageActivationMode="ExclusiveProcess">
      <StatelessService ServiceTypeName="MyStatelessServiceType" InstanceCount="[MyStatelessService_InstanceCount]">
        <SingletonPartition />
      </StatelessService>
    </Service>
  </DefaultServices>
  <Principals>
    <Users>
      <User Name="SetupAdminUser">
        <MemberOf>
          <SystemGroup Name="Administrators" />
        </MemberOf>
      </User>
    </Users>
  </Principals>
</ApplicationManifest>

Najpierw utwórz sekcję Principals (Podmioty zabezpieczeń ) z nazwą użytkownika, taką jak SetupAdminUser. Konto użytkownika SetupAdminUser jest członkiem grupy systemowej Administratorzy.

Następnie w sekcji ServiceManifestImport skonfiguruj zasady, aby zastosować tę jednostkę do setupEntryPoint. Te zasady informują usługę Service Fabric, że po uruchomieniu pliku MySetup.bat powinien on zostać uruchomiony jako SetupAdminUser (z uprawnieniami administratora). Ponieważ zasady nie zostały zastosowane do głównego punktu wejścia, kod w MyServiceHost.exe działa w ramach systemowego konta NetworkService . Jest to domyślne konto, w ramach którego są uruchamiane wszystkie punkty wejścia usługi.

Konfigurowanie zasad przy użyciu lokalnych kont systemowych

Często zaleca się uruchomienie skryptu uruchamiania przy użyciu lokalnego konta systemowego, a nie konta administratora. Uruchamianie zasad Uruchom jako członka grupy Administratorzy zwykle nie działa prawidłowo, ponieważ komputery mają domyślnie włączoną funkcję user Access Control (UAC). W takich przypadkach zaleca się uruchomienie instalatoraEntryPoint jako LocalSystem, a nie jako użytkownika lokalnego dodanego do grupy Administratorzy. W poniższym przykładzie pokazano ustawienie setupEntryPoint do uruchomienia jako LocalSystem:

<?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="MyApplicationType" ApplicationTypeVersion="1.0.0" xmlns="http://schemas.microsoft.com/2011/01/fabric">
  <Parameters>
    <Parameter Name="MyStatelessService_InstanceCount" DefaultValue="-1" />
  </Parameters>
  <ServiceManifestImport>
    <ServiceManifestRef ServiceManifestName="MyStatelessServicePkg" ServiceManifestVersion="1.0.0" />
    <ConfigOverrides />
    <Policies>
         <RunAsPolicy CodePackageRef="Code" UserRef="SetupLocalSystem" EntryPointType="Setup" />
      </Policies>
  </ServiceManifestImport>
  <DefaultServices>
    <Service Name="MyStatelessService" ServicePackageActivationMode="ExclusiveProcess">
      <StatelessService ServiceTypeName="MyStatelessServiceType" InstanceCount="[MyStatelessService_InstanceCount]">
        <SingletonPartition />
      </StatelessService>
    </Service>
  </DefaultServices>
  <Principals>
      <Users>
         <User Name="SetupLocalSystem" AccountType="LocalSystem" />
      </Users>
   </Principals>
</ApplicationManifest>

Uwaga

W przypadku klastrów systemu Linux, aby uruchomić usługę lub punkt wejścia konfiguracji jako główny, można określić typ konta jako LocalSystem.

Uruchamianie skryptu z punktu wejścia konfiguracji

Teraz dodaj skrypt uruchamiania do projektu w celu uruchomienia w ramach uprawnień administratora.

W programie Visual Studio kliknij prawym przyciskiem myszy projekt usługi i dodaj nowy plik o nazwie MySetup.bat.

Następnie upewnij się, że plik MySetup.bat znajduje się w pakiecie usługi. Domyślnie nie jest. Wybierz plik, kliknij prawym przyciskiem myszy, aby pobrać menu kontekstowe, a następnie wybierz polecenie Właściwości. W oknie dialogowym Właściwości upewnij się, że dla opcji Kopiuj do katalogu wyjściowego jest ustawiona wartość Kopiuj, jeśli jest nowsza. Zobacz poniższy zrzut ekranu.

Visual Studio CopyToOutput dla pliku wsadowego SetupEntryPoint

Teraz zmodyfikuj plik MySetup.bat i dodaj następujące polecenia, aby ustawić systemową zmienną środowiskową i wyświetlić plik tekstowy:

REM Set a system environment variable. This requires administrator privilege
setx -m TestVariable %*
echo System TestVariable set to > out.txt
echo %TestVariable% >> out.txt

REM To delete this system variable us
REM REG delete "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment" /v TestVariable /f

Następnie skompiluj i wdróż rozwiązanie w lokalnym klastrze projektowym. Po uruchomieniu usługi, jak pokazano w Service Fabric Explorer, widać, że plik MySetup.bat zakończył się pomyślnie na dwa sposoby. Otwórz wiersz polecenia programu PowerShell i wpisz:

PS C:\ [Environment]::GetEnvironmentVariable("TestVariable","Machine")
MyValue

Następnie zanotuj nazwę węzła, w którym usługa została wdrożona i uruchomiona w Service Fabric Explorer. Na przykład węzeł 2. Następnie przejdź do folderu roboczego wystąpienia aplikacji, aby znaleźć plik out.txt, który pokazuje wartość TestVariable. Jeśli na przykład ta usługa została wdrożona w węźle 2, możesz przejść do tej ścieżki dla elementu MyApplicationType:

C:\SfDevCluster\Data\_App\Node.2\MyApplicationType_App\work\out.txt

Uruchamianie poleceń programu PowerShell z punktu wejścia instalacji

Aby uruchomić program PowerShell z punktu SetupEntryPoint , można uruchomić PowerShell.exe w pliku wsadowym wskazującym plik programu PowerShell. Najpierw dodaj plik programu PowerShell do projektu usługi — na przykład MySetup.ps1. Pamiętaj, aby ustawić właściwość Kopiuj, jeśli jest nowsza , tak aby plik był również uwzględniony w pakiecie usługi. W poniższym przykładzie pokazano przykładowy plik wsadowy, który uruchamia plik programu PowerShell o nazwie MySetup.ps1, który ustawia systemową zmienną środowiskową o nazwie TestVariable.

MySetup.bat, aby uruchomić plik programu PowerShell:

powershell.exe -ExecutionPolicy Bypass -Command ".\MySetup.ps1"

W pliku programu PowerShell dodaj następujące polecenie, aby ustawić zmienną środowiskową systemową:

[Environment]::SetEnvironmentVariable("TestVariable", "MyValue", "Machine")
[Environment]::GetEnvironmentVariable("TestVariable","Machine") > out.txt

Uwaga

Domyślnie po uruchomieniu pliku wsadowego przyjrzy się folderowi aplikacji o nazwie work dla plików. W takim przypadku po uruchomieniu MySetup.bat chcemy znaleźć plik MySetup.ps1 w tym samym folderze, który jest folderem pakietu kodu aplikacji. Aby zmienić ten folder, ustaw folder roboczy:

<SetupEntryPoint>
    <ExeHost>
    <Program>MySetup.bat</Program>
    <WorkingFolder>CodePackage</WorkingFolder>
    </ExeHost>
</SetupEntryPoint>

Lokalne debugowanie skryptu uruchamiania przy użyciu przekierowania konsoli

Czasami przydatne jest debugowanie danych wyjściowych konsoli podczas uruchamiania skryptu konfiguracji. Zasady przekierowania konsoli można ustawić w punkcie wejścia konfiguracji w manifeście usługi, który zapisuje dane wyjściowe w pliku. Dane wyjściowe pliku są zapisywane w folderze aplikacji o nazwie log w węźle klastra, w którym aplikacja jest wdrażana i uruchamiana, w C:\SfDeployCluster\_App\{application-name}\logpliku . Po nazwie aplikacji w ścieżce może zostać wyświetlona liczba. Ta liczba zwiększa się w każdym wdrożeniu. Pliki zapisywane w folderze dziennika obejmują Code_{service-name}Pkg_S_0.err, czyli standardowe dane wyjściowe błędów, a Code_{nazwa_usługi}Pkg_S_0.out, czyli standardowe dane wyjściowe. W zależności od prób aktywacji usługi może być wyświetlanych więcej niż jeden zestaw plików.

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.

Poniższy przykład manifestu usługi pokazuje ustawienie przekierowania konsoli z wartością FileRetentionCount:

<SetupEntryPoint>
    <ExeHost>
    <Program>MySetup.bat</Program>
    <WorkingFolder>CodePackage</WorkingFolder>
    <ConsoleRedirection FileRetentionCount="10"/>
    </ExeHost>
</SetupEntryPoint>

Jeśli teraz zmienisz plik MySetup.ps1 w celu zapisania polecenia Echo , spowoduje to zapisanie w pliku wyjściowym na potrzeby debugowania:

Echo "Test console redirection which writes to the application log folder on the node that the application is deployed to"

Ostrzeżenie

Po debugowania skryptu natychmiast usuń te zasady przekierowania konsoli.

Następne kroki