tarefa AzureWebApp@1 – Aplicativo Web v1 do Azure

Syntax

# Azure Web App v1
# Deploy an Azure Web App for Linux or Windows.
- task: AzureWebApp@1
  inputs:
    azureSubscription: # string. Required. Azure subscription. 
    appType: # 'webApp' | 'webAppLinux'. Required. App type. 
    appName: # string. Required. App name. 
    #deployToSlotOrASE: false # boolean. Optional. Use when appType != "". Deploy to Slot or App Service Environment. Default: false.
    #resourceGroupName: # string. Required when deployToSlotOrASE = true. Resource group. 
    #slotName: 'production' # string. Required when deployToSlotOrASE = true. Slot. Default: production.
    package: '$(System.DefaultWorkingDirectory)/**/*.zip' # string. Required. Package or folder. Default: $(System.DefaultWorkingDirectory)/**/*.zip.
    #customDeployFolder: # string. Optional. Use when package EndsWith .war. Custom Deploy Folder. 
    #runtimeStack: # string. Optional. Use when appType = webAppLinux. Runtime stack. 
    #startUpCommand: # string. Optional. Use when appType = webAppLinux. Startup command. 
  # Application and Configuration Settings
    #customWebConfig: # string. Optional. Use when appType != webAppLinux && package NotEndsWith .war. Generate web.config parameters for Python, Node.js, Go and Java apps. 
    #appSettings: # string. App settings. 
    #configurationStrings: # string. Configuration settings. 
  # Additional Deployment Options
    #deploymentMethod: 'auto' # 'auto' | 'zipDeploy' | 'runFromPackage'. Required when appType != webAppLinux && appType != "" && package NotEndsWith .war && package NotEndsWith .jar. Deployment method. Default: auto.

# Azure Web App v1
# Deploy an Azure Web App for Linux or Windows.
- task: AzureWebApp@1
  inputs:
    azureSubscription: # string. Required. Azure subscription. 
    appType: # 'webApp' | 'webAppLinux'. Required. App type. 
    appName: # string. Required. App name. 
    #deployToSlotOrASE: false # boolean. Optional. Use when appType != "". Deploy to Slot or App Service Environment. Default: false.
    #resourceGroupName: # string. Required when deployToSlotOrASE = true. Resource group. 
    #slotName: 'production' # string. Required when deployToSlotOrASE = true. Slot. Default: production.
    package: '$(System.DefaultWorkingDirectory)/**/*.zip' # string. Required. Package or folder. Default: $(System.DefaultWorkingDirectory)/**/*.zip.
    #runtimeStack: # string. Optional. Use when appType = webAppLinux. Runtime stack. 
    #startUpCommand: # string. Optional. Use when appType = webAppLinux. Startup command. 
  # Application and Configuration Settings
    #customWebConfig: # string. Optional. Use when appType != webAppLinux && package NotEndsWith .war. Generate web.config parameters for Python, Node.js, Go and Java apps. 
    #appSettings: # string. App settings. 
    #configurationStrings: # string. Configuration settings. 
  # Additional Deployment Options
    #deploymentMethod: 'auto' # 'auto' | 'zipDeploy' | 'runFromPackage'. Required when appType != webAppLinux && appType != "" && package NotEndsWith .war && package NotEndsWith .jar. Deployment method. Default: auto.

Entradas

Opções de controle da tarefa

Todas as tarefas têm opções de controle além de suas entradas de tarefa. Para obter mais informações, consulte Opções de controle e propriedades comuns da tarefa.

Variáveis de saída

Comentários

Use esta tarefa para implantar aplicativos Web em Serviço de Aplicativo do Azure.

Métodos de implantação

Vários métodos de implantação estão disponíveis nesta tarefa. Auto é a opção padrão.

Para alterar a opção de implantação baseada em pacote na tarefa de designer, expanda Opções adicionais de implantação e habilite Selecionar Método de Implantação.

Com base no tipo de Serviço de Aplicativo do Azure e de agente do Azure Pipelines, a tarefa escolhe uma tecnologia de implantação adequada. As diferentes tecnologias de implantação usadas pela tarefa são:

• APIs REST do Kudu
• Implantação de zip
• RunFromPackage

Por padrão, a tarefa tenta selecionar a tecnologia de implantação apropriada, considerando o pacote de entrada, o tipo de serviço de aplicativo e o sistema operacional do agente.

• Quando o tipo de serviço de aplicativo for Aplicativo Web no Aplicativo Linux, use Zip Deploy
• Se um arquivo war for fornecido, use War Deploy
• Se um arquivo Jar for fornecido, use Executar do Pacote
• Para todos os outros, use Executar do Zip (via Implantação zip)

Em um agente não Windows (para qualquer tipo de serviço de aplicativo), a tarefa depende das APIs REST do Kudu para implantar o aplicativo Web.

APIs REST do Kudu

As APIs REST do Kudu funcionam em agentes de automação do Windows ou linux quando o destino é Aplicativo Web no Windows, Aplicativo Web no Linux (origem interna) ou Aplicativo de Funções. A tarefa usa o Kudu para copiar arquivos para o Serviço de Aplicativo do Azure.

Implantação de zip

Cria um pacote de implantação .zip do pacote ou pasta escolhido. Em seguida, o conteúdo do arquivo é implantado na pasta wwwroot do aplicativo de funções no Serviço de Aplicativo do Azure. Essa opção substitui todo o conteúdo existente na pasta wwwroot. Para obter mais informações, confira Implantação de zip para o Azure Functions.

RunFromPackage

Cria o mesmo pacote de implantação que o Zip Deploy. No entanto, em vez de implantar arquivos na pasta wwwroot, todo o pacote é montado pelo runtime Azure Functions. Com essa opção, os arquivos na pasta wwwroot tornam-se somente leitura. Para obter mais informações, consulte Executar o Azure Functions de um arquivo de pacote.

Erro: não foi possível buscar o token de acesso para o Azure. Verifique se a entidade de serviço usada é válida e não expirou.

A tarefa usa a entidade de serviço na conexão de serviço para autenticar com o Azure. Se a entidade de serviço tiver expirado ou não tiver permissões para o Serviço de Aplicativo, a tarefa falhará com esse erro. Verifique a validade da entidade de serviço usada e se ela está presente no registro do aplicativo. Para obter mais informações, confira Usar o controle de acesso baseado em função para gerenciar o acesso aos recursos da sua assinatura do Azure. Esta postagem no blog também contém mais informações sobre como usar a autenticação da entidade de serviço.

Erro de SSL

Se você quiser usar um certificado no Serviço de Aplicativo, o certificado precisará ser assinado por uma autoridade de certificação confiável. Se o seu aplicativo Web retorna erros de validação de certificado, você provavelmente está usando um certificado autoassinado. Defina uma variável chamada VSTS_ARM_REST_IGNORE_SSL_ERRORS para o valor true no pipeline de build ou lançamento para resolver o erro.

Uma versão fica parada por muito tempo e depois falha

Esse problema pode ser resultado de capacidade insuficiente em seu plano de Serviço de Aplicativo. Para resolver esse problema, você pode escalar verticalmente a instância do Serviço de Aplicativo para aumentar a CPU, a RAM e o espaço em disco disponíveis ou pode tentar um plano diferente do Serviço de Aplicativo.

Códigos de erro 5xx

Se você estiver vendo um erro 5xx, verifique o status do serviço do Azure.

O Azure Function parou de funcionar repentinamente

Azure Functions poderá parar de funcionar repentinamente se mais de um ano tiver passado desde a última implantação. Se você implantar com "RunFromPackage" em "deploymentMethod", uma SAS com uma data de validade de 1 ano será gerada e definida como o valor de "WEBSITE_RUN_FROM_PACKAGE" na configuração do aplicativo. Azure Functions usa essa SAS para fazer referência ao arquivo de pacote para execução da função, portanto, se a SAS tiver expirado, a função não será executada. Para resolve esse problema, implante novamente para gerar uma SAS com uma data de validade de um ano.

Erro: nenhum pacote encontrado com o padrão especificado

Verifique se o pacote mencionado na tarefa está publicado como um artefato na build ou em um estágio anterior e baixado no trabalho atual.

Erro: não há suporte para publicar usando a opção de implantação zip para o tipo de pacote msBuild

Os pacotes da Web criados com a tarefa MSBuild (com argumentos padrão) têm uma estrutura de pastas aninhada que só pode ser implantada corretamente pela Implantação da Web. A opção de implantação de publicação em zip não pode ser usada para implantar esses pacotes. Para converter a estrutura de empacotamento, siga estas etapas:

1. Na tarefa Solução de build, altere MSBuild Arguments para /p:DeployOnBuild=true /p:DeployDefaultTarget=WebPublish /p:WebPublishMethod=FileSystem /p:DeleteExistingFiles=True /p:publishUrl="$(System.DefaultWorkingDirectory)\\WebAppContent":

   

2. Adicione uma tarefa Arquivar e altere os valores da seguinte maneira:

   1. Altere Pasta raiz ou documento para arquivar para $(System.DefaultWorkingDirectory)\\WebAppContent.

   2. Desmarque a caixa de seleção Prefixar nome da pasta raiz para caminhos de arquivo:

      

Perguntas frequentes

Qual é a diferença entre as AzureWebApp tarefas e AzureRmWebAppDeployment ?

A tarefa aplicativo Web do Azure (AzureWebApp) é a maneira mais simples de implantar em um Aplicativo Web do Azure. Por padrão, sua implantação ocorre com o aplicativo raiz no Aplicativo Web do Azure.

A tarefa implantar Serviço de Aplicativo do Azure (AzureRmWebAppDeployment) pode lidar com mais cenários personalizados, como:

• Modifique as configurações dentro de pacotes Web e arquivos de parâmetros XML.
• Implante com a Implantação da Web, se você estiver acostumado com o processo de implantação do IIS.
• Implantar em aplicativos virtuais.
• Implante em outros tipos de aplicativo, como aplicativos de contêiner, aplicativos de funções, WebJobs ou aplicativos de API e Móvel.

A implantação do aplicativo Web foi concluída no Windows, mas o aplicativo não está funcionando

Isso pode ocorrer porque o web.config não está presente no seu aplicativo. Você pode adicionar um arquivo web.config à origem ou gerar automaticamente um usando Configurações de Aplicativo e Configuração.

• Clique na tarefa e vá para Gerar parâmetros web.config para aplicativos Python, Node.js, Go e Java.

  

• Clique no botão ... mais para editar os parâmetros.

  

• Selecione o tipo de aplicativo na lista suspensa.

• Clique em OK. Isso preencherá os parâmetros de web.config necessários para gerar web.config.

A implantação do aplicativo Web no Ambiente do Serviço de Aplicativo (ASE) não está funcionando

• Verifique se o agente de build do Azure DevOps está na mesma VNET (a sub-rede pode ser diferente) que o ILB (Load Balancer Interno) do ASE. Isso permitirá que o agente efetue pull de código do Azure DevOps e implante no ASE.
• Se você estiver usando o Azure DevOps, o agente não precisará estar acessível pela Internet, mas só precisará de acesso de saída para se conectar ao Serviço do Azure DevOps.
• Se você estiver usando o TFS/Azure DevOps Server implantado em uma Rede Virtual, o agente poderá ser completamente isolado.
• O agente de build deve ser configurado com a configuração DNS do Aplicativo Web no qual ele precisa implantar. Os recursos privados no Rede Virtual não têm entradas no DNS do Azure, portanto, isso precisa ser adicionado ao arquivo do host no computador do agente.
• Se um certificado autoassinado for usado para a configuração do ASE, a opção -allowUntrusted precisará ser definida na tarefa de implantação para MSDeploy. Também é recomendável definir a variável VSTS_ARM_REST_IGNORE_SSL_ERRORS como true. Isso não deverá ser necessário se um certificado de uma autoridade de certificação for usado para a configuração do ASE.

Como devo configurar minha conexão de serviço?

Essa tarefa exige uma conexão de serviço do Azure Resource Manager.

Como devo configurar a implantação de trabalho Web com o Application Insights?

Ao implantar em um Serviço de Aplicativo, se você tiver o Application Insights configurado e tiver habilitado Remove additional files at destination, também precisará habilitar Exclude files from the App_Data folder. Habilitar essa opção mantém a extensão do Application Insights em um estado seguro. Essa etapa é necessária porque o WebJob contínuo do Application Insights está instalado na pasta App_Data.

Como devo configurar meu agente se ele estiver por trás de um proxy enquanto estou implantando no Serviço de Aplicativo?

Se o agente auto-hospedado exigir um proxy Web, você poderá informar o agente sobre o proxy durante a configuração. Fazer isso possibilita que seu agente se conecte ao Azure Pipelines ou Azure DevOps Server por meio do proxy. Saiba mais sobre como executar um agente auto-hospedado por trás de um proxy Web.

Exemplos

Veja a seguir um exemplo de snippet de código YAML para implantar o aplicativo Web no Azure Web Serviço de Aplicativo em execução no Windows.

variables:
  azureSubscription: Contoso
  # To ignore SSL error uncomment the below variable
  # VSTS_ARM_REST_IGNORE_SSL_ERRORS: true

steps:

- task: AzureWebApp@1
  displayName: Azure Web App Deploy
  inputs:
    azureSubscription: $(azureSubscription)
    appName: samplewebapp
    package: $(System.DefaultWorkingDirectory)/**/*.zip

Para implantar o Aplicativo Web no Linux, adicione o parâmetro e defina-o appType como appType: webAppLinux.

Para especificar o método de implantação como Zip Deploy, adicione o parâmetro deploymentMethod: zipDeploy. Outro valor com suporte para esse parâmetro é runFromPackage.

Se não for especificado, auto será o valor padrão.

Requisitos