Implantar arquivos no Serviço de Aplicativo
Observação
A partir de 1º de junho de 2024, todos os aplicativos recém-criados do Serviço de Aplicativo terão a opção de gerar um nome do host padrão exclusivo usando a convenção de nomenclatura <app-name>-<random-hash>.<region>.azurewebsites.net
. Os nomes de aplicativos existentes permanecerão inalterados.
Exemplo: myapp-ds27dh7271aah175.westus-01.azurewebsites.net
Para obter mais detalhes, consulte Nome do Host Padrão Exclusivo para o Recurso Serviço de Aplicativo.
Este artigo mostra como implantar seu código como um pacote ZIP, WAR, JAR ou EAR para o Serviço de Aplicativo do Azure. Ele também mostra como implantar arquivos individuais no Serviço de Aplicativo, separados do seu pacote de aplicativos.
Pré-requisitos
Para concluir as etapas neste artigo, crie um aplicativo do Serviço de Aplicativo ou use um aplicativo criado para outro tutorial.
Caso você não tenha uma assinatura do Azure, crie uma conta gratuita do Azure antes de começar.
Criar um projeto de pacote ZIP
Importante
Ao criar o pacote ZIP para implantação, não inclua o diretório raiz, mas apenas os arquivos e diretórios nele contidos. Se você fizer download de um repositório do GitHub como um arquivo ZIP, não poderá implantar esse arquivo no estado em que se encontra 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 do terminal local, navegue até o diretório raiz do projeto do aplicativo.
Esse diretório deve conter o arquivo de entrada no seu aplicativo Web, como index.html, index.php e app.js. Além disso, é possível conter arquivos de gerenciamento de pacotes como project.json, composer.json, package.json, bower.json e requirements.txt.
A menos que deseje que o Serviço de Aplicativo execute a automação de implantação para você, execute todas as tarefas de compilação (por exemplo, npm
, bower
, gulp
, composer
e pip
) e certifique-se de que tenha todos os arquivos necessários para executar o aplicativo. Esta etapa será necessária se desejar executar o pacote diretamente.
Criar um arquivo zip de tudo em seu projeto. Para projetos dotnet
, isso é tudo no diretório de saída do comando dotnet publish
(excluindo o próprio diretório de 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
Implantar um pacote ZIP
Ao implantar um pacote ZIP, o Serviço de Aplicativo descompactará o conteúdo no caminho padrão para seu aplicativo (D:\home\site\wwwroot
para Windows, /home/site/wwwroot
para Linux).
Essa implantação do pacote ZIP usa o mesmo serviço Kudu que alimenta implementações baseadas em integração contínua. O Kudu dá suporte para a seguinte funcionalidade para a implantação de um pacote ZIP:
- Exclusão de arquivos remanescentes de uma implantação anterior.
- Opção para ativar o processo de compilação padrão que inclui a restauração do pacote.
- Personalização da implantação, incluindo execução de scripts de implantação.
- Logs de implantação.
- Um limite de tamanho de pacote de 2048 MB.
Observação
Os arquivos no pacote ZIP só serão copiados se seus carimbos de data/hora não corresponderem ao que já está implantado.
Com a interface do usuário de implantação de zip no Kudu
No navegador, navegue até https://<app_name>.scm.azurewebsites.net/ZipDeployUI
(veja nota no topo).
Carregue o pacote ZIP que você criou em Criar um pacote ZIP de projeto arrastando-o para a área do gerenciador de arquivos na página da Web.
Quando a implantação está em andamento, um ícone no canto superior direito mostra o progresso em porcentagem. A página também mostra as mensagens detalhadas para a operação abaixo da área do explorer. Quando a implantação for concluída, a última mensagem deverá dizer Deployment successful
.
O ponto de extremidade acima não está funcionando para os Serviços de Aplicativos do Linux no momento. Considere usar o FTP ou a API de implantação de ZIP em vez disso.
Sem a interface do usuário de implantação de zip no Kudu
Implante um pacote ZIP em seu aplicativo Web usando o comando az webapp deploy. O comando da CLI usa a API de publicação do Kudu para implantar os arquivos e pode ser totalmente personalizado.
O exemplo a seguir envia um pacote ZIP por push para seu site. Especifique o caminho para seu pacote ZIP local para --src-path
.
az webapp deploy --resource-group <group-name> --name <app-name> --src-path <zip-package-path>
Esse comando reinicia o aplicativo depois de implantar o pacote ZIP.
Habilitar a automação de compilar para a implantação de zip
Por padrão, o mecanismo de implantação assume que um pacote ZIP está pronto para ser executado no estado em que se encontra e não executa nenhuma automação de compilação. Para habilitar a mesma automação de compilação que em uma implantação do Git, defina a configuração do aplicativo SCM_DO_BUILD_DURING_DEPLOYMENT
executando o seguinte comando no Cloud Shell:
az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings SCM_DO_BUILD_DURING_DEPLOYMENT=true
Para obter mais informações, consulte Documentação do Kudu.
Implantar pacotes WAR/JAR/EAR
Você pode implantar o pacote WAR, JAR ou EAR no Serviço de Aplicativo para executar seu aplicativo Web Java usando a CLI do Azure, o PowerShell ou a API de publicação do Kudu.
O processo de implantação mostrado aqui coloca o pacote no compartilhamento de conteúdo do aplicativo com a convenção de nomenclatura e a estrutura de diretório corretas (confira Referência da API de publicação do Kudu), e essa é a abordagem recomendada. Se você implantar pacotes WAR/JAR/EAR usando FTP ou WebDeploy, poderá conferir falhas desconhecidas devido a erros na nomenclatura ou na estrutura.
Implante um pacote WAR no Tomcat ou JBoss EAP usando o comando az webapp deploy. Especifique o caminho para seu pacote Java local como --src-path
.
az webapp deploy --resource-group <group-name> --name <app-name> --src-path ./<package-name>.war
O comando da CLI usa a API de publicação do Kudu para implantar o pacote e pode ser totalmente personalizado.
Implantar arquivos individuais
Implante um script de inicialização, uma biblioteca e um arquivo estático em seu aplicativo Web usando o comando az webapp deploy com o parâmetro --type
.
Se você implantar um script de inicialização dessa forma, o Serviço de Aplicativo usará automaticamente seu script para iniciar o aplicativo.
O comando da CLI usa a API de publicação do Kudu para implantar os arquivos e pode ser totalmente personalizado.
Implantar um script de inicialização
az webapp deploy --resource-group <group-name> --name <app-name> --src-path scripts/startup.sh --type=startup
Implantar um arquivo de biblioteca
az webapp deploy --resource-group <group-name> --name <app-name> --src-path driver.jar --type=lib
Implantar um arquivo estático
az webapp deploy --resource-group <group-name> --name <app-name> --src-path config.json --type=static
Implantar em aplicativos protegidos pela rede
Dependendo da configuração de rede do aplicativo Web, o acesso direto ao aplicativo do seu ambiente de desenvolvimento pode ser bloqueado (consulte Implantando em sites protegidos pela rede e Implantando em sites protegidos pela rede, parte 2). Em vez de enviar o pacote ou arquivo diretamente para o aplicativo Web, você pode publicá-lo em um sistema de armazenamento acessível pelo aplicativo Web e disparar o aplicativo para efetuar pull do ZIP do local de armazenamento.
A URL remota pode ser qualquer local acessível publicamente, mas é melhor usar um contêiner de armazenamento de blobs com uma chave SAS para protegê-la.
Use o comando az webapp deploy
como faria nas outras seções, mas use --src-url
em vez de --src-path
. O exemplo a seguir usa o parâmetro --src-url
para especificar a URL de um arquivo ZIP hospedado em uma conta de Armazenamento do Microsoft Azure.
az webapp deploy --resource-group <group-name> --name <app-name> --src-url "https://storagesample.blob.core.windows.net/sample-container/myapp.zip?sv=2021-10-01&sb&sig=slk22f3UrS823n4kSh8Skjpa7Naj4CG3 --type zip
Referência da API de publicação do Kudu
A API do Kudu publish
permite que você especifique os mesmos parâmetros do comando da CLI que os parâmetros de consulta de URL. Para autenticar com a API REST do Kudu, é melhor usar a autenticação de token, mas você também pode usar a autenticação básica com as credenciais de implantação do aplicativo.
A tabela a seguir mostra os parâmetros de consulta disponíveis, os valores permitidos e as descrições.
Chave | Valores permitidos | Descrição | Obrigatório | Type |
---|---|---|---|---|
type |
war |jar |ear |lib |startup |static |zip |
O tipo do artefato que está sendo implantado; isso define o caminho de destino padrão e informa ao aplicativo Web como a implantação deve ser tratada. - type=zip : implante um pacote ZIP descompactando o conteúdo para /home/site/wwwroot . O parâmetro target-path é opcional. - type=war : implante um pacote WAR. Por padrão, o pacote WAR é implantado em /home/site/wwwroot/app.war . O caminho de destino pode ser especificado com target-path . - type=jar : implante um pacote JAR em /home/site/wwwroot/app.jar . O parâmetro target-path é ignorado - type=ear : implante um pacote EAR em /home/site/wwwroot/app.ear . O parâmetro target-path é ignorado - type=lib : implante um arquivo de biblioteca JAR. Por padrão, o arquivo é implantado em /home/site/libs . O caminho de destino pode ser especificado com target-path . - type=static : implante um arquivo estático (como um script). Por padrão, o arquivo é implantado em /home/site/wwwroot . - type=startup : implante um script que o serviço de aplicativo usa automaticamente como o script de inicialização do seu aplicativo. Por padrão, o script é implantado no D:\home\site\scripts\<name-of-source> para o Windows e no home/site/wwwroot/startup.sh para o Linux. O caminho de destino pode ser especificado com target-path . |
Sim | String |
restart |
true |false |
Por padrão, a API reinicia o aplicativo após a operação de implantação (restart=true ). Para implantar vários artefatos, evite reinicializações em todas as implantações, exceto na final, definindo como restart=false . |
Não | Boolean |
clean |
true |false |
Especifica se a implantação de destino deve ser limpa (excluída) antes de implantar o artefato. | Não | Boolean |
ignorestack |
true |false |
A API de publicação usa a variável de ambiente WEBSITE_STACK para escolher os padrões seguros, dependendo da pilha de linguagens do site. Definir esse parâmetro como false desabilita qualquer padrão específico de linguagem. |
Não | Booliano |
target-path |
Um caminho absoluto | O caminho absoluto ao qual implantar o artefato. Por exemplo, "/home/site/deployments/tools/driver.jar" , "/home/site/scripts/helper.sh" . |
Não | String |
Próximas etapas
Para cenários mais avançados de implantação, tente implantação no Azure com Git. Implantação baseada em Git no Azure permite o controle de versão, restauração do pacote, MSBuild e muito mais.