Execute seu aplicativo no Serviço de Aplicativo do Azure diretamente de um pacote ZIP

No Serviço de Aplicativo do Azure, você pode executar seus aplicativos diretamente de um arquivo de pacote ZIP de implantação. Este artigo mostra como habilitar essa funcionalidade em seu aplicativo.

Todos os outros métodos de implantação no Serviço de Aplicativo têm algo em comum: seus arquivos são implantados em D:\home\site\wwwroot em seu aplicativo (ou /home/site/wwwroot para aplicativos Linux). Como o mesmo diretório é usado pelo seu aplicativo em tempo de execução, é possível que a implantação falhe devido a conflitos de bloqueio de arquivo e que o aplicativo se comporte de forma imprevisível porque alguns dos arquivos ainda não foram atualizados.

Por outro lado, quando você executa diretamente de um pacote, os arquivos no pacote não são copiados para o diretório wwwroot . Em vez disso, o próprio pacote ZIP é montado diretamente como o diretório wwwroot somente leitura. Há vários benefícios em executar diretamente de um pacote:

  • Elimina conflitos de bloqueio de arquivo entre implantação e tempo de execução.
  • Garante que apenas os aplicativos implantados totalmente sejam executados a qualquer momento.
  • Pode ser implantado em um aplicativo de produção (com reinicialização).
  • Melhora o desempenho das implantações do Azure Resource Manager.
  • Pode reduzir os tempos de arranque a frio, particularmente para funções JavaScript com grandes árvores de pacotes npm.

Nota

Atualmente, apenas arquivos de pacote ZIP são suportados.

Criar um pacote ZIP de projeto

Importante

Ao criar o pacote ZIP para implantação, não inclua o diretório raiz, mas apenas os arquivos e diretórios nele. Se você baixar um repositório GitHub como um arquivo ZIP, não poderá implantar esse arquivo como está no Serviço de Aplicativo. O GitHub adiciona diretórios aninhados adicionais no nível superior, que não funcionam com o Serviço de Aplicativo.

Em uma janela de terminal local, navegue até o diretório raiz do seu projeto de aplicativo.

Esse diretório deve conter o arquivo de entrada para seu aplicativo Web, como index.html, index.php e app.js. Ele também pode conter arquivos de gerenciamento de pacotes como project.json, composer.json, package.json, bower.json e requisitos.txt.

A menos que você queira que o Serviço de Aplicativo execute a automação de implantação para você, execute todas as tarefas de compilação (por exemplo, , , composergulp, npmbowere ) e pipverifique se você tem todos os arquivos necessários para executar o aplicativo. Esta etapa é necessária se você quiser executar o pacote diretamente.

Crie um arquivo ZIP de tudo no seu projeto. Para dotnet projetos, isso é tudo no diretório de saída do comando (excluindo o próprio diretório de dotnet publish saída). Por exemplo, o seguinte comando em seu terminal para criar um pacote ZIP do conteúdo do diretório atual:

# Bash
zip -r <file-name>.zip .

# PowerShell
Compress-Archive -Path * -DestinationPath <file-name>.zip

Ativar a execução a partir do pacote

A WEBSITE_RUN_FROM_PACKAGE configuração do aplicativo permite a execução a partir de um pacote. Para defini-lo, execute o seguinte comando com a CLI do Azure.

az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITE_RUN_FROM_PACKAGE="1"

WEBSITE_RUN_FROM_PACKAGE="1" permite que você execute seu aplicativo de um pacote local para seu aplicativo. Você também pode executar a partir de um pacote remoto.

Executar o pacote

A maneira mais fácil de executar um pacote em seu Serviço de Aplicativo é com o comando config-zip da CLI az webapp deployment source do Azure. Por exemplo:

az webapp deployment source config-zip --resource-group <group-name> --name <app-name> --src <filename>.zip

Como a configuração do aplicativo está definida, esse comando não extrai o conteúdo do pacote para o diretório D:\home\site\wwwroot do WEBSITE_RUN_FROM_PACKAGE seu aplicativo. Em vez disso, ele carrega o arquivo ZIP como está para D:\home\data\SitePackages, e cria um packagename.txt no mesmo diretório, que contém o nome do pacote ZIP para carregar em tempo de execução. Se você carregar seu pacote ZIP de uma maneira diferente (como FTP), precisará criar o diretório D:\home\data\SitePackages e o arquivo packagename.txt manualmente.

O comando também reinicia o aplicativo. Como WEBSITE_RUN_FROM_PACKAGE está definido, o Serviço de Aplicativo monta o pacote carregado como o diretório wwwroot somente leitura e executa o aplicativo diretamente desse diretório montado.

Em vez disso, execute a partir de URL externo

Também pode executar um pacote a partir de um URL externo, como Armazenamento de Blobs do Azure. Você pode usar o Gerenciador de Armazenamento do Azure para carregar arquivos de pacote em sua conta de armazenamento de Blob. Você deve usar um contêiner de armazenamento privado com uma Assinatura de Acesso Compartilhado (SAS) ou usar uma identidade gerenciada para habilitar o tempo de execução do Serviço de Aplicativo para acessar o pacote com segurança.

Depois de carregar o arquivo para o armazenamento de Blob e ter uma URL SAS para o arquivo, defina a configuração do aplicativo para a WEBSITE_RUN_FROM_PACKAGE URL. O exemplo a seguir faz isso usando a CLI do Azure:

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings WEBSITE_RUN_FROM_PACKAGE="https://myblobstorage.blob.core.windows.net/content/SampleCoreMVCApp.zip?st=2018-02-13T09%3A48%3A00Z&se=2044-06-14T09%3A48%3A00Z&sp=rl&sv=2017-04-17&sr=b&sig=bNrVrEFzRHQB17GFJ7boEanetyJ9DGwBSV8OM3Mdh%2FM%3D"

Se você publicar um pacote atualizado com o mesmo nome no armazenamento de Blob, precisará reiniciar seu aplicativo para que o pacote atualizado seja carregado no Serviço de Aplicativo.

Acessar um pacote no Armazenamento de Blobs do Azure usando uma identidade gerenciada

O Armazenamento de Blobs do Azure pode ser configurado para autorizar solicitações com a ID do Microsoft Entra. Isso significa que, em vez de gerar uma chave SAS com uma expiração, você pode confiar na identidade gerenciada do aplicativo. Por predefinição, será utilizada a identidade atribuída pelo sistema da aplicação. Se desejar especificar uma identidade atribuída pelo usuário, você pode definir a configuração do aplicativo para a WEBSITE_RUN_FROM_PACKAGE_BLOB_MI_RESOURCE_ID ID de recurso dessa identidade. A configuração também pode aceitar "SystemAssigned" como um valor, embora isso seja o mesmo que omitir a configuração completamente.

Para permitir que o pacote seja buscado usando a identidade:

  1. Verifique se o blob está configurado para acesso privado.

  2. Conceda à identidade a função Storage Blob Data Reader com escopo sobre o blob do pacote. Consulte Atribuir uma função do Azure para acesso a dados de blob para obter detalhes sobre como criar a atribuição de função.

  3. Defina a configuração do aplicativo para a WEBSITE_RUN_FROM_PACKAGE URL de blob do pacote. Isso provavelmente será do formato "https://{storage-account-name}.blob.core.windows.net/{container-name}/{path-to-package}" ou similar.

Implantar arquivos WebJob ao executar a partir do pacote

Há duas maneiras de implantar arquivos WebJob quando você habilita a execução de um aplicativo a partir do pacote:

  • Implante no mesmo pacote ZIP que seu aplicativo: inclua-os como faria normalmente <project-root>\app_data\jobs\... (que mapeia para o caminho \site\wwwroot\app_data\jobs\... de implantação conforme especificado no início rápido do WebJobs).
  • Implantar separadamente do pacote ZIP do seu aplicativo: Como o caminho \site\wwwroot\app_data\jobs\... de implantação usual agora é somente leitura, não é possível implantar arquivos WebJob lá. Em vez disso, implante arquivos WebJob no \site\jobs\..., que não é somente leitura. WebJobs implantados e \site\wwwroot\app_data\jobs\...\site\jobs\... ambos executados.

Nota

Quando \site\wwwroot se torna somente leitura, operações como a criação do disable.job falharão.

Resolução de Problemas

  • A execução direta de um pacote torna wwwroot somente leitura. Seu aplicativo receberá um erro se tentar gravar arquivos nesse diretório.
  • Os formatos TAR e GZIP não são suportados.
  • O arquivo ZIP pode ter no máximo 1GB
  • Esse recurso não é compatível com o cache local.
  • Para melhorar o desempenho de arranque a frio, utilize a opção Zip local (WEBSITE_RUN_FROM_PACKAGE=1).

Mais recursos