Tarefas de inicialização do Common Cloud Service (clássico)
Importante
Os Serviços na Nuvem (clássicos) foram preteridos para todos os clientes a partir de 1º de setembro de 2024. Todas as implantações em execução existentes serão interrompidas e encerradas pela Microsoft e os dados serão perdidos permanentemente a partir de outubro de 2024. Novas implantações devem usar o novo modelo de implantação baseado no Azure Resource Manager Serviços de Nuvem do Azure (suporte estendido).
Este artigo fornece alguns exemplos de tarefas de inicialização comuns que você pode querer executar em seu serviço de nuvem. Você pode usar tarefas de inicialização para executar operações antes que uma função seja iniciada. As operações que você pode querer executar incluem a instalação de um componente, o registro de componentes COM (Component Object Model), a definição de chaves do Registro ou o início de um processo de longa execução.
Consulte este artigo para entender como as tarefas de inicialização funcionam e, especificamente, como criar as entradas que definem uma tarefa de inicialização.
Nota
As tarefas de inicialização não são aplicáveis a Máquinas Virtuais, apenas a funções Web e de Trabalho do Serviço de Nuvem.
Definir variáveis de ambiente antes do início de uma função
Se você precisar de variáveis de ambiente definidas para uma tarefa específica, use o elemento Environment dentro do elemento 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>
As variáveis também podem usar um valor XPath do Azure válido para fazer referência a algo sobre a implantação. Em vez de usar o value atributo, defina um elemento filho RoleInstanceValue .
<Variable name="PathToStartupStorage">
<RoleInstanceValue xpath="/RoleEnvironment/CurrentInstance/LocalResources/LocalResource[@name='StartupLocalStorage']/@path" />
</Variable>
Configurar a inicialização do IIS com o AppCmd.exe
A ferramenta de linha de comando AppCmd.exe pode ser usada para gerenciar as configurações do IIS (Serviço de Informações da Internet) na inicialização no Azure. AppCmd.exe fornece acesso conveniente de linha de comando a definições de configuração para uso em tarefas de inicialização no Azure. Quando você usa AppCmd.exe, as configurações do site podem ser adicionadas, modificadas ou removidas para aplicativos e sites.
No entanto, há algumas coisas a observar no uso do AppCmd.exe como uma tarefa de inicialização:
- As tarefas de inicialização podem ser executadas mais de uma vez entre as reinicializações. Por exemplo, quando uma função é reciclada.
- Se uma ação AppCmd.exe for executada mais de uma vez, poderá gerar um erro. Por exemplo, tentar adicionar uma seção ao Web.config duas vezes pode gerar um erro.
- As tarefas de inicialização falham se retornarem um código de saída diferente de zero ou um nível de erro. Por exemplo, quando AppCmd.exe gera um erro.
É uma boa prática verificar o nível de erro depois de chamar AppCmd.exe, o que é fácil de fazer se você envolver a chamada para AppCmd.exe com um arquivo .cmd . Se você detetar uma resposta de nível de erro conhecida, poderá ignorá-la ou passá-la de volta.
Os valores de nível de erro retornados por AppCmd.exe estão listados no arquivo winerror.h e também podem ser vistos no Microsoft Developer Network (MSDN).
Exemplo de gestão do nível de erro
Este exemplo adiciona uma seção de compactação e uma entrada de compactação para JSON ao arquivo Web.config , com tratamento de erros e registro.
As seções relevantes do arquivo ServiceDefinition.csdef são mostradas aqui, que incluem a configuração do atributo executionContext para elevated dar a AppCmd.exe permissões suficientes para alterar as configurações no arquivo 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>
O arquivo em lotes Startup.cmd usa AppCmd.exe para adicionar uma seção de compactação e uma entrada de compactação para JSON ao arquivo Web.config . O nível de erro esperado de 183 é definido como zero usando o programa de linha de comando VERIFY.EXE. Níveis de erro inesperados são registrados em 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%
Adicionar regras de firewall
No Azure, existem efetivamente dois firewalls. O primeiro firewall controla conexões entre a máquina virtual e o mundo exterior. O elemento EndPoints no arquivo ServiceDefinition.csdef controla esse firewall.
O segundo firewall controla as conexões entre a máquina virtual e os processos dentro dessa máquina virtual. Você pode controlar esse firewall a partir da netsh advfirewall firewall ferramenta de linha de comando.
O Azure cria regras de firewall para os processos iniciados em suas funções. Por exemplo, quando você inicia um serviço ou programa, o Azure cria automaticamente as regras de firewall necessárias para permitir que esse serviço se comunique com a Internet. No entanto, se você criar um serviço iniciado por um processo fora de sua função (como um serviço COM+ ou uma Tarefa Agendada do Windows), precisará criar manualmente uma regra de firewall para permitir o acesso a esse serviço. Essas regras de firewall podem ser criadas usando uma tarefa de inicialização.
Uma tarefa de inicialização que cria uma regra de firewall deve ter um executionContext elevado. Adicione a seguinte tarefa de inicialização ao arquivo 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>
Para adicionar a regra de firewall, você deve usar os comandos apropriados netsh advfirewall firewall no arquivo em lote de inicialização. Neste exemplo, a tarefa de inicialização requer segurança e criptografia para a porta TCP (Transmission Control Protocol) 80.
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%
Bloquear um endereço IP específico
Você pode restringir o acesso de uma função Web do Azure a um conjunto de endereços IP especificados modificando seu arquivo web.config do IIS. Você também precisa usar um arquivo de comando que desbloqueia a seção ipSecurity do arquivo ApplicationHost.config .
Para desbloquear a seção ipSecurity do arquivo ApplicationHost.config, crie um arquivo de comando que seja executado no início da função. Crie uma pasta no nível raiz da sua função Web chamada inicialização e, dentro dessa pasta, crie um arquivo em lotes chamado startup.cmd. Adicione esse arquivo ao seu projeto do Visual Studio e defina as propriedades como Copiar sempre para garantir que você o inclua em seu pacote.
Adicione a seguinte tarefa de inicialização ao arquivo 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>
Adicione este comando ao arquivo 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
Essa tarefa faz com que o arquivo em lotes de startup.cmd seja executado sempre que a função Web for inicializada, garantindo que a seção ipSecurity necessária seja desbloqueada.
Por fim, modifique a seção system.webServer do arquivo web.config da sua função Web para adicionar uma lista de endereços IP aos quais é concedido acesso, conforme mostrado no exemplo a seguir:
Esta configuração de exemplo permite que todos os IPs acessem o servidor, exceto os dois definidos
<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>
Esta configuração de exemplo nega que todos os IPs acessem o servidor, exceto os dois definidos.
<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>
Criar uma tarefa de inicialização do PowerShell
Os scripts do Windows PowerShell não podem ser chamados diretamente do arquivo ServiceDefinition.csdef , mas podem ser invocados de dentro de um arquivo em lote de inicialização.
O PowerShell (por padrão) não executa scripts não assinados. A menos que você assine seu script, precisará configurar o PowerShell para executar scripts não assinados. Para executar scripts não assinados, ExecutionPolicy deve ser definido como Unrestricted. A configuração ExecutionPolicy que você usa é baseada na versão do 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%
Se você estiver usando um SO convidado que executa o PowerShell 2.0 ou 1.0, poderá forçar a versão 2 a ser executada e, se não estiver disponível, usar a versão 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%
Criar arquivos no armazenamento local a partir de uma tarefa de inicialização
Você pode usar um recurso de armazenamento local para armazenar arquivos criados pela tarefa de inicialização que seu aplicativo acessa posteriormente.
Para criar o recurso de armazenamento local, adicione uma seção LocalResources ao arquivo ServiceDefinition.csdef e adicione o elemento filho LocalStorage . Dê ao recurso de armazenamento local um nome exclusivo e um tamanho apropriado para sua tarefa de inicialização.
Para usar um recurso de armazenamento local em sua tarefa de inicialização, você precisa criar uma variável de ambiente para fazer referência ao local do recurso de armazenamento local. Em seguida, a tarefa de inicialização e o aplicativo são capazes de ler e gravar arquivos no recurso de armazenamento local.
As seções relevantes do arquivo ServiceDefinition.csdef são mostradas aqui:
<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>
Como exemplo, esse arquivo em lotes Startup.cmd usa a variável de ambiente PathToStartupStorage para criar o arquivo MyTest.txt no local de armazenamento local.
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
Você pode acessar a pasta de armazenamento local do SDK do Azure usando o método GetLocalResource .
string localStoragePath = Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.GetLocalResource("StartupLocalStorage").RootPath;
string fileContent = System.IO.File.ReadAllText(System.IO.Path.Combine(localStoragePath, "MyTestFile.txt"));
Executar no emulador ou na nuvem
Você pode fazer com que sua tarefa de inicialização execute etapas diferentes quando estiver operando na nuvem em comparação com quando estiver no emulador de computação. Por exemplo, você pode querer usar uma nova cópia de seus dados SQL somente quando executado no emulador. Ou você pode querer fazer algumas otimizações de desempenho para a nuvem que você não precisa fazer ao executar no emulador.
Essa capacidade de executar diferentes ações no emulador de computação e na nuvem pode ser realizada criando uma variável de ambiente no arquivo ServiceDefinition.csdef . Em seguida, você testa essa variável de ambiente para obter um valor em sua tarefa de inicialização.
Para criar a variável de ambiente, adicione o elemento Variable/RoleInstanceValue e crie um valor XPath de ./RoleEnvironment/Deployment/@emulated O valor da variável de ambiente %ComputeEmulatorRunning% é true quando executado no emulador de computação e false quando executado na nuvem.
<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>
A tarefa agora pode verificar a variável de ambiente %ComputeEmulatorRunning% para executar ações diferentes com base no fato de a função estar sendo executada na nuvem ou no emulador. Aqui está um shell script .cmd que verifica essa variável de ambiente.
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.
)
Detetar que sua tarefa já foi executada
A função pode ser reciclada sem uma reinicialização, fazendo com que suas tarefas de inicialização sejam executadas novamente. Não há nenhum sinalizador para indicar que uma tarefa já foi executada na máquina virtual (VM) do host. Você pode ter algumas tarefas em que não importa que elas sejam executadas várias vezes. No entanto, você pode se deparar com uma situação em que precisa impedir que uma tarefa seja executada mais de uma vez.
A maneira mais simples de detetar que uma tarefa já foi executada é criar um arquivo na pasta %TEMP% quando a tarefa for bem-sucedida e procurá-lo no início da tarefa. Aqui está um exemplo de script de shell cmd que faz isso para você.
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
Práticas recomendadas para tarefas
Aqui estão algumas práticas recomendadas que você deve seguir ao configurar a tarefa para sua função Web ou de trabalho.
Sempre registre as atividades de inicialização
O Visual Studio não fornece um depurador para percorrer arquivos em lote, por isso é bom obter o máximo possível de dados sobre a operação de arquivos em lote. Registrar a saída de arquivos em lote, tanto stdout quanto stderr, pode fornecer informações importantes ao tentar depurar e corrigir arquivos em lote. Para registrar stdout e stderr no arquivo StartupLog.txt no diretório apontado pela variável de ambiente %TEMP%, adicione o texto >> "%TEMP%\\StartupLog.txt" 2>&1 ao final das linhas específicas que você deseja registrar. Por exemplo, para executar setup.exe no diretório %PathToApp1Install% : "%PathToApp1Install%\setup.exe" >> "%TEMP%\StartupLog.txt" 2>&1
Para simplificar seu xml, você pode criar um arquivo cmd wrapper que chama todas as suas tarefas de inicialização junto com o registro em log e garante que cada tarefa-filho compartilhe as mesmas variáveis de ambiente.
Você pode achar chato usar >> "%TEMP%\StartupLog.txt" 2>&1 no final de cada tarefa de inicialização. Você pode impor o log de tarefas criando um wrapper que lida com o log para você. Este wrapper chama o arquivo em lote real que você deseja executar. Qualquer saída do arquivo em lote de destino redireciona para o arquivo Startuplog.txt .
O exemplo a seguir mostra como redirecionar toda a saída de um arquivo em lote de inicialização. Neste exemplo, o arquivo ServerDefinition.csdef cria uma tarefa de inicialização que chama logwrap.cmd. logwrap.cmd chama Startup2.cmd, redirecionando toda a saída para %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%
Saída de exemplo no arquivo 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 ================================================
Gorjeta
O arquivo StartupLog.txt está localizado na pasta C:\Resources\temp\{role identifier}\RoleTemp .
Definir executionContext adequadamente para tarefas de inicialização
Defina privilégios apropriadamente para a tarefa de inicialização. Às vezes, as tarefas de inicialização devem ser executadas com privilégios elevados, mesmo que a função seja executada com privilégios normais.
O atributo executionContext define o nível de privilégio da tarefa de inicialização. Usar executionContext="limited" significa que a tarefa de inicialização tem o mesmo nível de privilégio que a função. Usar executionContext="elevated" significa que a tarefa de inicialização tem privilégios de administrador, o que permite que a tarefa de inicialização execute tarefas de administrador sem conceder privilégios de administrador à sua função.
Um exemplo de uma tarefa de inicialização que requer privilégios elevados é uma tarefa de inicialização que usa AppCmd.exe para configurar o IIS. AppCmd.exe requer executionContext="elevated".
Use o taskType apropriado
O atributo taskType determina a maneira como a tarefa de inicialização é executada. Existem três valores: simples, plano de fundo e primeiro plano. As tarefas em segundo plano e em primeiro plano são iniciadas de forma assíncrona e, em seguida, as tarefas simples são executadas de forma síncrona, uma de cada vez.
Com tarefas de inicialização simples , você pode definir a ordem em que as tarefas são executadas pela ordem em que as tarefas são listadas no arquivo ServiceDefinition.csdef. Se uma tarefa simples terminar com um código de saída diferente de zero, o procedimento de inicialização será interrompido e a função não será iniciada.
A diferença entre as tarefas de inicialização em segundo plano e as tarefas de inicialização em primeiro plano é que as tarefas em primeiro plano mantêm a função em execução até que a tarefa em primeiro plano termine. Essa estrutura significa que, se a tarefa em primeiro plano travar ou falhar, a função permanecerá não reciclada até que a tarefa em primeiro plano seja fechada forçadamente. Por esse motivo, as tarefas em segundo plano são recomendadas para tarefas de inicialização assíncrona, a menos que você precise desse recurso da tarefa em primeiro plano.
Finalizar arquivos em lote com EXIT /B 0
A função só é iniciada se o nível de erro de cada uma das suas tarefas de inicialização simples for zero. Nem todos os programas definem o nível de erro (código de saída) corretamente, então o arquivo em lote deve terminar com um EXIT /B 0 se tudo funcionou corretamente.
Uma falta EXIT /B 0 no final de um arquivo em lote de inicialização é uma causa comum de funções que não são iniciadas.
Nota
Notei que os arquivos em lote aninhados às vezes param de responder ao usar o /B parâmetro. Você pode querer certificar-se de que esse problema não acontece se outro arquivo em lotes chamar seu arquivo em lotes atual, como se você usar o wrapper de log. Neste caso, é possível omitir o /B parâmetro.
Espere que as tarefas de inicialização sejam executadas mais de uma vez
Nem todas as reciclagens de função incluem uma reinicialização, mas todas as reciclagens de função incluem a execução de todas as tarefas de inicialização. Esse design significa que as tarefas de inicialização devem ser capazes de executar várias vezes entre as reinicializações sem problemas, o que é discutido na seção anterior.
Usar armazenamento local para armazenar arquivos que devem ser acessados na função
Se você quiser copiar ou criar um arquivo durante a tarefa de inicialização que seja acessível à sua função, esse arquivo deverá ser colocado no armazenamento local. Ver secção anterior.
Próximos passos
Revise o modelo e o pacote do serviço de nuvem
Saiba mais sobre como as Tarefas funcionam.
Crie e implante seu pacote de serviço de nuvem.