Typowe zadania uruchamiania usługi Cloud Service (klasyczne)

Artykuł
07/25/2024

Ważne

Usługi Cloud Services (wersja klasyczna) są teraz przestarzałe dla wszystkich klientów od 1 września 2024 r. Wszystkie istniejące uruchomione wdrożenia zostaną zatrzymane i zamknięte przez firmę Microsoft, a dane zostaną przypadkowo utracone od października 2024 r. Nowe wdrożenia powinny używać nowego modelu wdrażania opartego na usłudze Azure Resource Manager w usługach Azure Cloud Services (wsparcie dodatkowe).

Ten artykuł zawiera kilka przykładów typowych zadań uruchamiania, które można wykonać w usłudze w chmurze. Zadania uruchamiania umożliwiają wykonywanie operacji przed rozpoczęciem roli. Operacje, które można wykonać, obejmują instalowanie składnika, rejestrowanie składników modelu obiektów składników (COM), ustawianie kluczy rejestru lub uruchamianie długotrwałego procesu.

Zapoznaj się z tym artykułem , aby dowiedzieć się, jak działają zadania uruchamiania, a w szczególności jak utworzyć wpisy definiujące zadanie uruchamiania.

Uwaga

Zadania uruchamiania nie mają zastosowania do maszyn wirtualnych, tylko dla ról sieci Web i procesu roboczego usługi w chmurze.

Definiowanie zmiennych środowiskowych przed rozpoczęciem roli

Jeśli potrzebujesz zmiennych środowiskowych zdefiniowanych dla określonego zadania, użyj elementu Environment wewnątrz elementu Task .

<ServiceDefinition name="MyService" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
    <WorkerRole name="WorkerRole1">
        ...
        <Startup>
            <Task commandLine="Startup.cmd" executionContext="limited" taskType="simple">
                <Environment>
                    <Variable name="MyEnvironmentVariable" value="MyVariableValue" />
                </Environment>
            </Task>
        </Startup>
    </WorkerRole>
</ServiceDefinition>

Zmienne mogą również używać prawidłowej wartości usługi Azure XPath do odwoływania się do czegoś o wdrożeniu. Zamiast używać atrybutu, zdefiniuj value element podrzędny RoleInstanceValue .

<Variable name="PathToStartupStorage">
    <RoleInstanceValue xpath="/RoleEnvironment/CurrentInstance/LocalResources/LocalResource[@name='StartupLocalStorage']/@path" />
</Variable>

Konfigurowanie uruchamiania usług IIS przy użyciu AppCmd.exe

Narzędzie wiersza polecenia AppCmd.exe może służyć do zarządzania ustawieniami usługi Internet Information Service (IIS) podczas uruchamiania na platformie Azure. AppCmd.exe zapewnia wygodny dostęp wiersza polecenia do ustawień konfiguracji do użycia w zadaniach uruchamiania na platformie Azure. W przypadku korzystania z AppCmd.exe ustawienia witryny sieci Web można dodawać, modyfikować lub usuwać dla aplikacji i witryn.

Istnieje jednak kilka rzeczy, które należy zwrócić uwagę na użycie AppCmd.exe jako zadania uruchamiania:

Zadania uruchamiania można uruchamiać więcej niż raz między ponownym uruchomieniem. Na przykład w przypadku recyklingu roli.
Jeśli akcja AppCmd.exe jest wykonywana więcej niż raz, może to spowodować wygenerowanie błędu. Na przykład próba dodania sekcji do pliku Web.config dwukrotnie może spowodować wystąpienie błędu.
Zadania uruchamiania kończą się niepowodzeniem, jeśli zwracają kod zakończenia niezerowy lub errorlevel. Na przykład gdy AppCmd.exe generuje błąd.

Dobrym rozwiązaniem jest sprawdzenie poziomu błędu po wywołaniu AppCmd.exe, co jest łatwe w przypadku zawijania wywołania w celu AppCmd.exe za pomocą pliku .cmd. Jeśli wykryjesz znaną odpowiedź na poziom błędu, możesz ją zignorować lub przekazać ją z powrotem.

Wartości errorlevel zwracane przez AppCmd.exe są wymienione w pliku winerror.h i można je również zobaczyć w witrynie Microsoft Developer Network (MSDN).

Przykład zarządzania poziomem błędu

W tym przykładzie dodano sekcję kompresji i wpis kompresji dla formatu JSON do pliku Web.config z obsługą błędów i rejestrowaniem.

W tym miejscu przedstawiono odpowiednie sekcje pliku ServiceDefinition.csdef, które obejmują ustawienie atrybutu executionContext w celu elevated nadania AppCmd.exe wystarczających uprawnień do zmiany ustawień w pliku Web.config:

<ServiceDefinition name="MyService" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
    <WorkerRole name="WorkerRole1">
        ...
        <Startup>
            <Task commandLine="Startup.cmd" executionContext="elevated" taskType="simple" />
        </Startup>
    </WorkerRole>
</ServiceDefinition>

Plik wsadowy Startup.cmd używa AppCmd.exe do dodawania sekcji kompresji i wpisu kompresji dla pliku JSON do pliku Web.config . Oczekiwany poziom błędu 183 jest ustawiony na zero przy użyciu programu wiersza polecenia VERIFY.EXE. Nieoczekiwane błędy są rejestrowane w StartupErrorLog.txt.

REM   *** Add a compression section to the Web.config file. ***
%windir%\system32\inetsrv\appcmd set config /section:urlCompression /doDynamicCompression:True /commit:apphost >> "%TEMP%\StartupLog.txt" 2>&1

REM   ERRORLEVEL 183 occurs when trying to add a section that already exists. This error is expected if this
REM   batch file were executed twice. This can occur and must be accounted for in an Azure startup
REM   task. To handle this situation, set the ERRORLEVEL to zero by using the Verify command. The Verify
REM   command will safely set the ERRORLEVEL to zero.
IF %ERRORLEVEL% EQU 183 VERIFY > NUL

REM   If the ERRORLEVEL is not zero at this point, some other error occurred.
IF %ERRORLEVEL% NEQ 0 (
    ECHO Error adding a compression section to the Web.config file. >> "%TEMP%\StartupLog.txt" 2>&1
    GOTO ErrorExit
)

REM   *** Add compression for json. ***
%windir%\system32\inetsrv\appcmd set config  -section:system.webServer/httpCompression /+"dynamicTypes.[mimeType='application/json; charset=utf-8',enabled='True']" /commit:apphost >> "%TEMP%\StartupLog.txt" 2>&1
IF %ERRORLEVEL% EQU 183 VERIFY > NUL
IF %ERRORLEVEL% NEQ 0 (
    ECHO Error adding the JSON compression type to the Web.config file. >> "%TEMP%\StartupLog.txt" 2>&1
    GOTO ErrorExit
)

REM   *** Exit batch file. ***
EXIT /b 0

REM   *** Log error and exit ***
:ErrorExit
REM   Report the date, time, and ERRORLEVEL of the error.
DATE /T >> "%TEMP%\StartupLog.txt" 2>&1
TIME /T >> "%TEMP%\StartupLog.txt" 2>&1
ECHO An error occurred during startup. ERRORLEVEL = %ERRORLEVEL% >> "%TEMP%\StartupLog.txt" 2>&1
EXIT %ERRORLEVEL%

Dodawanie reguł zapory

Na platformie Azure istnieją dwa zapory. Pierwsza zapora kontroluje połączenia między maszyną wirtualną a światem zewnętrznym. Element EndPoints w pliku ServiceDefinition.csdef kontroluje tę zaporę.

Druga zapora kontroluje połączenia między maszyną wirtualną a procesami w ramach tej maszyny wirtualnej. Tę zaporę można kontrolować za pomocą netsh advfirewall firewall narzędzia wiersza polecenia.

Platforma Azure tworzy reguły zapory dla procesów uruchomionych w ramach ról. Na przykład po uruchomieniu usługi lub programu platforma Azure automatycznie tworzy niezbędne reguły zapory, aby umożliwić tej usłudze komunikację z Internetem. Jeśli jednak utworzysz usługę uruchomioną przez proces poza rolą (np. usługę COM+ lub zaplanowane zadanie systemu Windows), musisz ręcznie utworzyć regułę zapory, aby zezwolić na dostęp do tej usługi. Te reguły zapory można utworzyć przy użyciu zadania uruchamiania.

Zadanie uruchamiania, które tworzy regułę zapory, musi mieć wartość executionContext z podwyższonym poziomem uprawnień. Dodaj następujące zadanie uruchamiania do pliku ServiceDefinition.csdef .

<ServiceDefinition name="MyService" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
    <WorkerRole name="WorkerRole1">
        ...
        <Startup>
            <Task commandLine="AddFirewallRules.cmd" executionContext="elevated" taskType="simple" />
        </Startup>
    </WorkerRole>
</ServiceDefinition>

Aby dodać regułę zapory, należy użyć odpowiednich netsh advfirewall firewall poleceń w pliku wsadowym uruchamiania. W tym przykładzie zadanie uruchamiania wymaga zabezpieczeń i szyfrowania portu 80 protokołu Transmission Control Protocol (TCP).

REM   Add a firewall rule in a startup task.

REM   Add an inbound rule requiring security and encryption for TCP port 80 traffic.
netsh advfirewall firewall add rule name="Require Encryption for Inbound TCP/80" protocol=TCP dir=in localport=80 security=authdynenc action=allow >> "%TEMP%\StartupLog.txt" 2>&1

REM   If an error occurred, return the errorlevel.
EXIT /B %errorlevel%

Blokowanie określonego adresu IP

Dostęp roli internetowej platformy Azure można ograniczyć do zestawu określonych adresów IP, modyfikując plik web.config usług IIS. Należy również użyć pliku polecenia, który odblokuje sekcję ipSecurity pliku ApplicationHost.config.

Aby odblokować sekcję ipSecurity pliku ApplicationHost.config, utwórz plik polecenia uruchamiany na początku roli. Utwórz folder na poziomie głównym roli sieci Web o nazwie startup i w tym folderze utwórz plik wsadowy o nazwie startup.cmd. Dodaj ten plik do projektu programu Visual Studio i ustaw właściwości na Kopiuj zawsze , aby upewnić się, że dołączysz go do pakietu.

Dodaj następujące zadanie uruchamiania do pliku ServiceDefinition.csdef .

<ServiceDefinition name="MyService" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
    <WebRole name="WebRole1">
        ...
        <Startup>
            <Task commandLine="startup.cmd" executionContext="elevated" />
        </Startup>
    </WebRole>
</ServiceDefinition>

Dodaj to polecenie do pliku startup.cmd :

@echo off
@echo Installing "IPv4 Address and Domain Restrictions" feature 
powershell -ExecutionPolicy Unrestricted -command "Install-WindowsFeature Web-IP-Security"
@echo Unlocking configuration for "IPv4 Address and Domain Restrictions" feature 
%windir%\system32\inetsrv\AppCmd.exe unlock config -section:system.webServer/security/ipSecurity

To zadanie powoduje uruchamianie pliku wsadowego startup.cmd za każdym razem, gdy rola internetowa jest inicjowana, upewniając się, że wymagana sekcja ipSecurity jest odblokowana.

Na koniec zmodyfikuj sekcję system.webServer pliku web role web.config, aby dodać listę adresów IP, którym udzielono dostępu, jak pokazano w poniższym przykładzie:

Ta przykładowa konfiguracja umożliwia wszystkim adresom IP dostęp do serwera z wyjątkiem dwóch zdefiniowanych

<system.webServer>
    <security>
    <!--Unlisted IP addresses are granted access-->
    <ipSecurity>
        <!--The following IP addresses are denied access-->
        <add allowed="false" ipAddress="192.168.100.1" subnetMask="255.255.0.0" />
        <add allowed="false" ipAddress="192.168.100.2" subnetMask="255.255.0.0" />
    </ipSecurity>
    </security>
</system.webServer>

Ta przykładowa konfiguracja uniemożliwia wszystkim adresom IP uzyskiwanie dostępu do serwera z wyjątkiem dwóch zdefiniowanych.

<system.webServer>
    <security>
    <!--Unlisted IP addresses are denied access-->
    <ipSecurity allowUnlisted="false">
        <!--The following IP addresses are granted access-->
        <add allowed="true" ipAddress="192.168.100.1" subnetMask="255.255.0.0" />
        <add allowed="true" ipAddress="192.168.100.2" subnetMask="255.255.0.0" />
    </ipSecurity>
    </security>
</system.webServer>

Tworzenie zadania uruchamiania programu PowerShell

Skrypty programu Windows PowerShell nie mogą być wywoływane bezpośrednio z pliku ServiceDefinition.csdef , ale można je wywołać z pliku wsadowego uruchamiania.

Program PowerShell (domyślnie) nie uruchamia niepodpisanych skryptów. Jeśli nie podpiszesz skryptu, musisz skonfigurować program PowerShell do uruchamiania niepodpisanych skryptów. Aby uruchomić niepodpisane skrypty, należy ustawić wartość ExecutionPolicy na wartość Unrestricted. Używane ustawienie ExecutionPolicy jest oparte na wersji programu Windows PowerShell.

REM   Run an unsigned PowerShell script and log the output
PowerShell -ExecutionPolicy Unrestricted .\startup.ps1 >> "%TEMP%\StartupLog.txt" 2>&1

REM   If an error occurred, return the errorlevel.
EXIT /B %errorlevel%

Jeśli używasz systemu operacyjnego gościa z uruchomionym programem PowerShell 2.0 lub 1.0, możesz wymusić uruchomienie wersji 2, a jeśli jest niedostępna, użyj wersji 1.

REM   Attempt to set the execution policy by using PowerShell version 2.0 syntax.
PowerShell -Version 2.0 -ExecutionPolicy Unrestricted .\startup.ps1 >> "%TEMP%\StartupLog.txt" 2>&1

REM   If PowerShell version 2.0 isn't available. Set the execution policy by using the PowerShell
IF %ERRORLEVEL% EQU -393216 (
   PowerShell -Command "Set-ExecutionPolicy Unrestricted" >> "%TEMP%\StartupLog.txt" 2>&1
   PowerShell .\startup.ps1 >> "%TEMP%\StartupLog.txt" 2>&1
)

REM   If an error occurred, return the errorlevel.
EXIT /B %errorlevel%

Tworzenie plików w magazynie lokalnym na podstawie zadania uruchamiania

Za pomocą zasobu magazynu lokalnego można przechowywać pliki utworzone przez zadanie uruchamiania, do którego aplikacja uzyskuje później dostęp.

Aby utworzyć zasób magazynu lokalnego, dodaj sekcję LocalResources do pliku ServiceDefinition.csdef, a następnie dodaj element podrzędny LocalStorage. Nadaj zasobowi magazynu lokalnego unikatową nazwę i odpowiedni rozmiar zadania uruchamiania.

Aby użyć zasobu magazynu lokalnego w zadaniu uruchamiania, należy utworzyć zmienną środowiskową, aby odwoływać się do lokalizacji zasobów magazynu lokalnego. Następnie zadanie uruchamiania i aplikacja mogą odczytywać i zapisywać pliki w zasobie magazynu lokalnego.

Poniżej przedstawiono odpowiednie sekcje pliku ServiceDefinition.csdef :

<ServiceDefinition name="MyService" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WorkerRole name="WorkerRole1">
    ...

    <LocalResources>
      <LocalStorage name="StartupLocalStorage" sizeInMB="5"/>
    </LocalResources>

    <Startup>
      <Task commandLine="Startup.cmd" executionContext="limited" taskType="simple">
        <Environment>
          <Variable name="PathToStartupStorage">
            <RoleInstanceValue xpath="/RoleEnvironment/CurrentInstance/LocalResources/LocalResource[@name='StartupLocalStorage']/@path" />
          </Variable>
        </Environment>
      </Task>
    </Startup>
  </WorkerRole>
</ServiceDefinition>

Na przykład ten plik wsadowy Startup.cmd używa zmiennej środowiskowej PathToStartupStorage w celu utworzenia MyTest.txt pliku w lokalnej lokalizacji magazynu.

REM   Create a simple text file.

ECHO This text will go into the MyTest.txt file which will be in the    >  "%PathToStartupStorage%\MyTest.txt"
ECHO path pointed to by the PathToStartupStorage environment variable.  >> "%PathToStartupStorage%\MyTest.txt"
ECHO The contents of the PathToStartupStorage environment variable is   >> "%PathToStartupStorage%\MyTest.txt"
ECHO "%PathToStartupStorage%".                                          >> "%PathToStartupStorage%\MyTest.txt"

REM   Exit the batch file with ERRORLEVEL 0.

EXIT /b 0

Dostęp do folderu magazynu lokalnego można uzyskać z zestawu Azure SDK przy użyciu metody GetLocalResource .

string localStoragePath = Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.GetLocalResource("StartupLocalStorage").RootPath;

string fileContent = System.IO.File.ReadAllText(System.IO.Path.Combine(localStoragePath, "MyTestFile.txt"));

Uruchamianie w emulatorze lub chmurze

Zadanie uruchamiania może wykonywać różne kroki w przypadku działania w chmurze w porównaniu z tym, kiedy znajduje się w emulatorze obliczeniowym. Na przykład możesz chcieć użyć nowej kopii danych SQL tylko podczas uruchamiania w emulatorze. Możesz też chcieć wykonać pewne optymalizacje wydajności dla chmury, które nie muszą być wykonywane podczas uruchamiania w emulatorze.

Tę możliwość wykonywania różnych akcji w emulatorze obliczeniowym i w chmurze można wykonać, tworząc zmienną środowiskową w pliku ServiceDefinition.csdef . Następnie przetestujesz zmienną środowiskową dla wartości w zadaniu uruchamiania.

Aby utworzyć zmienną środowiskową, dodaj element Variable /RoleInstanceValue i utwórz wartość XPath ./RoleEnvironment/Deployment/@emulated Wartość zmiennej środowiskowej %ComputeEmulatorRunning% jest true uruchamiana w emulatorze obliczeniowym i false podczas uruchamiania w chmurze.

<ServiceDefinition name="MyService" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WorkerRole name="WorkerRole1">

    ...

    <Startup>
      <Task commandLine="Startup.cmd" executionContext="limited" taskType="simple">
        <Environment>
          <Variable name="ComputeEmulatorRunning">
            <RoleInstanceValue xpath="/RoleEnvironment/Deployment/@emulated" />
          </Variable>
        </Environment>
      </Task>
    </Startup>

  </WorkerRole>
</ServiceDefinition>

Zadanie może teraz sprawdzić zmienną środowiskową %ComputeEmulatorRunning% , aby wykonywać różne akcje na podstawie tego, czy rola jest uruchomiona w chmurze, czy w emulatorze. Oto skrypt powłoki .cmd, który sprawdza, czy ta zmienna środowiskowa jest sprawdzana.

REM   Check if this task is running on the compute emulator.

IF "%ComputeEmulatorRunning%" == "true" (
    REM   This task is running on the compute emulator. Perform tasks that must be run only in the compute emulator.
) ELSE (
    REM   This task is running on the cloud. Perform tasks that must be run only in the cloud.
)

Wykryj, że zadanie zostało już uruchomione

Rola może być odtwarzana bez ponownego uruchamiania, co powoduje ponowne uruchomienie zadań uruchamiania. Nie ma flagi wskazującej, że zadanie jest już uruchomione na maszynie wirtualnej hosta. Może istnieć kilka zadań, w których nie ma znaczenia, że są uruchamiane wiele razy. Jednak może wystąpić sytuacja, w której trzeba zapobiec uruchomieniu zadania więcej niż raz.

Najprostszym sposobem wykrycia, że zadanie zostało już uruchomione, jest utworzenie pliku w folderze %TEMP% po pomyślnym wykonaniu zadania i wyszukaniu go na początku zadania. Oto przykładowy skrypt powłoki cmd, który wykonuje to za Ciebie.

REM   If Task1_Success.txt exists, then Application 1 is already installed.
IF EXIST "%PathToApp1Install%\Task1_Success.txt" (
  ECHO Application 1 is already installed. Exiting. >> "%TEMP%\StartupLog.txt" 2>&1
  GOTO Finish
)

REM   Run your real exe task
ECHO Running XYZ >> "%TEMP%\StartupLog.txt" 2>&1
"%PathToApp1Install%\setup.exe" >> "%TEMP%\StartupLog.txt" 2>&1

IF %ERRORLEVEL% EQU 0 (
  REM   The application installed without error. Create a file to indicate that the task
  REM   does not need to be run again.

  ECHO This line will create a file to indicate that Application 1 installed correctly. > "%PathToApp1Install%\Task1_Success.txt"

) ELSE (
  REM   An error occurred. Log the error and exit with the error code.

  DATE /T >> "%TEMP%\StartupLog.txt" 2>&1
  TIME /T >> "%TEMP%\StartupLog.txt" 2>&1
  ECHO  An error occurred running task 1. Errorlevel = %ERRORLEVEL%. >> "%TEMP%\StartupLog.txt" 2>&1

  EXIT %ERRORLEVEL%
)

:Finish

REM   Exit normally.
EXIT /B 0

Najlepsze rozwiązania dotyczące zadań

Poniżej przedstawiono kilka najlepszych rozwiązań, które należy stosować podczas konfigurowania zadania dla roli sieci Web lub procesu roboczego.

Zawsze rejestruj działania uruchamiania

Program Visual Studio nie udostępnia debugera do przechodzenia przez pliki wsadowe, dlatego dobrze jest uzyskać jak najwięcej danych dotyczących operacji plików wsadowych. Rejestrowanie danych wyjściowych plików wsadowych, zarówno stdout , jak i stderr, może dostarczyć ważnych informacji podczas próby debugowania i naprawiania plików wsadowych. Aby zarejestrować plik stdout i stderr do pliku StartupLog.txt w katalogu wskazywany przez zmienną środowiskową %TEMP%, dodaj tekst >> "%TEMP%\\StartupLog.txt" 2>&1 na końcu określonych wierszy, które chcesz zarejestrować. Aby na przykład wykonać setup.exe w katalogu %PathToApp1Install% : "%PathToApp1Install%\setup.exe" >> "%TEMP%\StartupLog.txt" 2>&1

Aby uprościć kod XML, można utworzyć plik cmd otoki, który wywołuje wszystkie zadania uruchamiania wraz z rejestrowaniem i zapewnia, że każde zadanie podrzędne współudzieli te same zmienne środowiskowe.

Może to być irytujące, choć do użycia >> "%TEMP%\StartupLog.txt" 2>&1 na końcu każdego zadania uruchamiania. Rejestrowanie zadań można wymusić, tworząc otokę, która obsługuje rejestrowanie. Ta otoka wywołuje rzeczywisty plik wsadowy, który chcesz uruchomić. Wszystkie dane wyjściowe z docelowego pliku wsadowego są przekierowywane do pliku Startuplog.txt .

W poniższym przykładzie pokazano, jak przekierować wszystkie dane wyjściowe z pliku wsadowego uruchamiania. W tym przykładzie plik ServerDefinition.csdef tworzy zadanie uruchamiania, które wywołuje logwrap.cmd. logwrap.cmd wywołuje Startup2.cmd, przekierowując wszystkie dane wyjściowe do folderu %TEMP%\StartupLog.txt.

ServiceDefinition.cmd:

<Startup>
    <Task commandLine="logwrap.cmd startup2.cmd" executionContext="limited" taskType="simple" />
</Startup>

logwrap.cmd:

@ECHO OFF

REM   logwrap.cmd calls passed in batch file, redirecting all output to the StartupLog.txt log file.

ECHO [%date% %time%] == START logwrap.cmd ============================================== >> "%TEMP%\StartupLog.txt" 2>&1
ECHO [%date% %time%] Running %1 >> "%TEMP%\StartupLog.txt" 2>&1

REM   Call the child command batch file, redirecting all output to the StartupLog.txt log file.
START /B /WAIT %1 >> "%TEMP%\StartupLog.txt" 2>&1

REM   Log the completion of child command.
ECHO [%date% %time%] Done >> "%TEMP%\StartupLog.txt" 2>&1

IF %ERRORLEVEL% EQU 0 (

   REM   No errors occurred. Exit logwrap.cmd normally.
   ECHO [%date% %time%] == END logwrap.cmd ================================================ >> "%TEMP%\StartupLog.txt" 2>&1
   ECHO.  >> "%TEMP%\StartupLog.txt" 2>&1
   EXIT /B 0

) ELSE (

   REM   Log the error.
   ECHO [%date% %time%] An error occurred. The ERRORLEVEL = %ERRORLEVEL%.  >> "%TEMP%\StartupLog.txt" 2>&1
   ECHO [%date% %time%] == END logwrap.cmd ================================================ >> "%TEMP%\StartupLog.txt" 2>&1
   ECHO.  >> "%TEMP%\StartupLog.txt" 2>&1
   EXIT /B %ERRORLEVEL%

)

Startup2.cmd:

@ECHO OFF

REM   This is the batch file where the startup steps should be performed. Because of the
REM   way Startup2.cmd was called, all commands and their outputs will be stored in the
REM   StartupLog.txt file in the directory pointed to by the TEMP environment variable.

REM   If an error occurs, the following command will pass the ERRORLEVEL back to the
REM   calling batch file.

ECHO [%date% %time%] Some log information about this task
ECHO [%date% %time%] Some more log information about this task

EXIT %ERRORLEVEL%

Przykładowe dane wyjściowe w pliku StartupLog.txt :

[Mon 10/17/2016 20:24:46.75] == START logwrap.cmd ============================================== 
[Mon 10/17/2016 20:24:46.75] Running command1.cmd 
[Mon 10/17/2016 20:24:46.77] Some log information about this task
[Mon 10/17/2016 20:24:46.77] Some more log information about this task
[Mon 10/17/2016 20:24:46.77] Done 
[Mon 10/17/2016 20:24:46.77] == END logwrap.cmd ================================================

Napiwek

Plik StartupLog.txt znajduje się w folderze C:\Resources\temp\{role identifier}\RoleTemp.

Ustaw właściwość executionContext odpowiednio dla zadań uruchamiania

Ustaw odpowiednie uprawnienia dla zadania uruchamiania. Czasami zadania uruchamiania muszą być uruchamiane z podwyższonym poziomem uprawnień, mimo że rola jest uruchamiana z normalnymi uprawnieniami.

Atrybut executionContext ustawia poziom uprawnień zadania uruchamiania. Użycie executionContext="limited" oznacza, że zadanie uruchamiania ma taki sam poziom uprawnień jak rola. Użycie executionContext="elevated" oznacza, że zadanie uruchamiania ma uprawnienia administratora, co umożliwia zadanie uruchamiania wykonywanie zadań administratora bez nadawania uprawnień administratora roli.

Przykładem zadania uruchamiania wymagającego podwyższonego poziomu uprawnień jest zadanie uruchamiania, które używa AppCmd.exe do konfigurowania usług IIS. AppCmd.exe wymaga .executionContext="elevated"

Użyj odpowiedniego typu zadania

Atrybut taskType określa sposób wykonywania zadania uruchamiania. Istnieją trzy wartości: proste, tło i pierwszy plan. Zadania w tle i na pierwszym planie są uruchamiane asynchronicznie, a następnie proste zadania są wykonywane synchronicznie pojedynczo.

Za pomocą prostych zadań uruchamiania można ustawić kolejność, w jakiej zadania są uruchamiane według kolejności, w której zadania są wymienione w pliku ServiceDefinition.csdef. Jeśli proste zadanie kończy się kodem zakończenia niezerowym, procedura uruchamiania zostanie zatrzymana i rola nie zostanie uruchomiona.

Różnica między zadaniami uruchamiania w tle i zadaniami uruchamiania pierwszego planu polega na tym, że zadania pierwszego planu zachowują rolę uruchomioną do momentu zakończenia zadania pierwszego planu. Ta struktura oznacza, że jeśli zadanie pierwszego planu zawiesza się lub ulega awarii, rola pozostaje nierozpoznana do momentu zamknięcia zadania pierwszego planu . Z tego powodu zadania w tle są zalecane w przypadku zadań asynchronicznych uruchamiania, chyba że potrzebujesz tej funkcji zadania pierwszego planu.

Kończ pliki wsadowe z exit /B 0

Rola jest uruchamiana tylko wtedy, gdy poziom błędu z każdego prostego zadania uruchamiania wynosi zero. Nie wszystkie programy poprawnie ustawiają wartość errorlevel (kod zakończenia), więc plik wsadowy powinien kończyć się wartością EXIT /B 0 , jeśli wszystko działa poprawnie.

Brak EXIT /B 0 na końcu pliku wsadowego uruchamiania jest częstą przyczyną, że role nie są uruchamiane.

Uwaga

Zauważyłem, że zagnieżdżone pliki wsadowe czasami przestają odpowiadać podczas korzystania z parametru /B . Możesz upewnić się, że ten problem nie występuje, jeśli inny plik wsadowy wywołuje bieżący plik wsadowy, na przykład jeśli używasz otoki dziennika. W tym przypadku można pominąć /B parametr.

Oczekiwanie, że zadania uruchamiania będą uruchamiane więcej niż raz

Nie wszystkie recyklingu ról obejmują ponowny rozruch, ale wszystkie recyklingu ról obejmują uruchamianie wszystkich zadań uruchamiania. Ten projekt oznacza, że zadania uruchamiania muszą być uruchamiane wiele razy między ponownymi rozruchami bez żadnych problemów, które zostały omówione w poprzedniej sekcji.

Używanie magazynu lokalnego do przechowywania plików, do których należy uzyskać dostęp w roli

Jeśli chcesz skopiować lub utworzyć plik podczas zadania uruchamiania, który jest dostępny dla twojej roli, ten plik musi zostać umieszczony w magazynie lokalnym. Zobacz poprzednią sekcję.

Następne kroki

Przeglądanie modelu i pakietu usług w chmurze

Dowiedz się więcej o sposobie działania zadań .

Utwórz i wdróż pakiet usługi w chmurze.

Udostępnij za pośrednictwem