Partilhar via

Configurar uma aplicação Node.js para o Serviço de Aplicações do Azure

Node.js aplicativos devem ser implantados com todas as dependências npm necessárias. O mecanismo de implantação do Serviço de Aplicativo é executado npm install --production automaticamente quando você implanta um repositório Git ou quando implanta um pacote Zipcom a automação de compilação habilitada. Se você implantar seus arquivos usando FTP/S, no entanto, você precisará carregar os pacotes necessários manualmente.

Este artigo descreve os principais conceitos e fornece instruções para Node.js desenvolvedores que implantam no Serviço de Aplicativo. Se você nunca usou o Serviço de Aplicativo do Azure, conclua primeiro o Node.js início rápido e o tutorialNode.js com o MongoDB .

Mostrar a versão Node.js

Para mostrar a versão atual do Node.js, execute o seguinte comando no Cloud Shell:

az webapp config appsettings list --name <app-name> --resource-group <resource-group-name> --query "[?name=='WEBSITE_NODE_DEFAULT_VERSION'].value"

Para mostrar todas as versões de Node.js suportadas, execute o seguinte comando no Cloud Shell:

az webapp list-runtimes --os windows | grep NODE

Para mostrar a versão atual do Node.js, execute o seguinte comando no Cloud Shell:

az webapp config show --resource-group <resource-group-name> --name <app-name> --query linuxFxVersion

Para mostrar todas as versões de Node.js suportadas, execute o seguinte comando no Cloud Shell:

az webapp list-runtimes --os linux | grep NODE

Definir a versão Node.js

Para definir seu aplicativo para uma versão de Node.js suportada, execute o seguinte comando no Cloud Shell para definir WEBSITE_NODE_DEFAULT_VERSION como uma versão compatível:

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings WEBSITE_NODE_DEFAULT_VERSION="~16"

Nota

Este exemplo usa a sintaxe til recomendada para direcionar a versão mais recente disponível do tempo de execução do Node.js 16 no Serviço de Aplicativo.

Como o tempo de execução é regularmente corrigido e atualizado pela plataforma, não recomendamos que você direcione uma versão/patch secundária específica. Devido a potenciais riscos de segurança, não é garantido que essas versões estejam disponíveis.

Nota

Você deve definir a versão Node.js no package.json. O mecanismo de implantação é executado em um processo separado que contém todas as versões de Node.js suportadas.

Para definir seu aplicativo para uma versão Node.js suportada, execute o seguinte comando no Cloud Shell:

az webapp config set --resource-group <resource-group-name> --name <app-name> --linux-fx-version "NODE|14-lts"

Essa configuração especifica a versão Node.js a ser usada, tanto em tempo de execução quanto durante a restauração automatizada de pacotes no Kudu.

Nota

Você deve definir a versão Node.js no package.json. O mecanismo de implantação é executado em um contêiner separado que contém todas as versões de Node.js suportadas.

O que acontece com tempos de execução desatualizados no Serviço de Aplicativo?

Tempos de execução desatualizados são preteridos pela organização mantenedora ou têm vulnerabilidades significativas. Assim, eles são removidos das páginas de criação e configuração no portal. Quando um tempo de execução desatualizado é oculto do portal, qualquer aplicativo que ainda esteja usando esse tempo de execução continua a ser executado.

Se você quiser criar um aplicativo com uma versão de tempo de execução desatualizada que não é mais mostrada no portal, use a CLI do Azure, um modelo ARM ou Bicep. Essas alternativas de implantação permitem criar tempos de execução preteridos que são removidos do portal, mas ainda estão sendo suportados.

Se um tempo de execução for totalmente removido da plataforma do Serviço de Aplicativo, o proprietário da assinatura do Azure receberá um aviso por email antes da remoção.

Definir o número da porta

Seu aplicativo Node.js precisa ouvir a porta certa para receber solicitações de entrada.

No App Service no Windows, as aplicações Node.js são hospedadas com IISNode, e o seu aplicativo Node.js deve escutar na porta especificada na variável process.env.PORT. O exemplo a seguir mostra como definir a porta em um aplicativo Express simples:

O Serviço de Aplicativo define a variável PORT de ambiente no contêiner Node.js e encaminha as solicitações de entrada para o contêiner nesse número de porta. Para receber as solicitações, seu aplicativo deve ouvir a porta especificada na process.env.PORT variável. O exemplo a seguir mostra como definir a porta em um aplicativo Express simples:

const express = require('express')
const app = express()
const port = process.env.PORT || 3000

app.get('/', (req, res) => {
  res.send('Hello World!')
})

app.listen(port, () => {
  console.log(`Example app listening at http://localhost:${port}`)
})

Personalizar a automatização de compilação

Se você implantar seu aplicativo usando o Git ou pacotes zip com a automação de compilação habilitada, a automação de compilação do Serviço de Aplicativo concluirá as seguintes etapas:

  1. Execute um script personalizado, se um for especificado pelo PRE_BUILD_SCRIPT_PATH.
  2. Corra npm install sem bandeiras. Esta etapa inclui npm preinstall e postinstall scripts e também instala devDependencieso .
  3. Execute npm run build se um script de construção for especificado no arquivo package.json .
  4. Execute npm run build:azure se um build:azure script for especificado no arquivo package.json .
  5. Execute um script personalizado, se um for especificado pelo POST_BUILD_SCRIPT_PATH.

Nota

Como é observado na documentação npm, scripts nomeados prebuild e postbuild são executados antes e depois de build, respectivamente, se especificados. Scripts nomeados preinstall e postinstall executados antes e depois install, respectivamente.

PRE_BUILD_COMMAND e POST_BUILD_COMMAND são variáveis de ambiente que estão vazias por padrão. Para executar comandos de pré-compilação, defina PRE_BUILD_COMMAND. Para executar comandos pós-compilação, defina POST_BUILD_COMMAND.

O exemplo a seguir usa as duas variáveis para especificar uma série de comandos, que são separados por vírgulas.

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings PRE_BUILD_COMMAND="echo foo, scripts/prebuild.sh"
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings POST_BUILD_COMMAND="echo foo, scripts/postbuild.sh"

Para obter informações sobre variáveis de ambiente adicionais para personalizar a automação de compilação, consulte Configuração do Oryx.

Para obter mais informações sobre como o Serviço de Aplicativo executa e cria aplicativos Node.js no Linux, consulte a documentação do Oryx: Como Node.js aplicativos são detetados e criados.

Configurar Node.js servidor

Os contentores Node.js vêm com PM2, um gestor do processo de produção. Você pode configurar seu aplicativo para começar com PM2, com npm start, ou com um comando personalizado.

Ferramenta Propósito
Executar com PM2 Recomendado. Produção ou uso de preparação. O PM2 fornece uma plataforma de gerenciamento de aplicativos de serviço completo.
Execute com o comando npm start Apenas para uso de desenvolvimento.
Executar com um comando personalizado Desenvolvimento ou teste.

Executar com PM2

O contêiner inicia automaticamente seu aplicativo com PM2 quando um dos arquivos de Node.js comuns é encontrado em seu projeto:

  • BIN/WWW
  • server.js
  • app.js
  • index.js
  • hostingstart.js
  • Um dos seguintes ficheiros PM2: process.json ou ecosystem.config.js

Você também pode configurar um arquivo de início personalizado com as seguintes extensões:

  • Um arquivo .js
  • Um arquivo PM2 com a extensão .json, .config.js, .yaml ou .yml

Nota

A partir do Nó 14 LTS, o contêiner não inicia automaticamente seu aplicativo com PM2. Para iniciar seu aplicativo com PM2, defina o comando de inicialização como pm2 start <.js-file-or-PM2-file> --no-daemon. Certifique-se de usar o --no-daemon argumento porque o PM2 precisa ser executado em primeiro plano para que o contêiner funcione corretamente.

Para adicionar um arquivo de início personalizado, execute o seguinte comando no Cloud Shell:

az webapp config set --resource-group <resource-group-name> --name <app-name> --startup-file "<filename-with-extension>"

Executar com um comando personalizado

O Serviço de Aplicativo pode iniciar seu aplicativo usando um comando personalizado, como um executável como run.sh. Por exemplo, para executar npm run start:prodo , execute o seguinte comando no Cloud Shell:

az webapp config set --resource-group <resource-group-name> --name <app-name> --startup-file "npm run start:prod"

Executar com início npm

Para iniciar seu aplicativo com npm starto , basta verificar se um start script está no arquivo package.json . Por exemplo:

{
  ...
  "scripts": {
    "start": "gulp",
    ...
  },
  ...
}

Para usar um package.json personalizado em seu projeto, execute o seguinte comando no Cloud Shell:

az webapp config set --resource-group <resource-group-name> --name <app-name> --startup-file "<filename>.json"

Depurar remotamente

Você pode depurar seu aplicativo Node.js remotamente no Visual Studio Code se configurá-lo para ser executado com PM2, exceto quando executá-lo usando um arquivo.config.js, .yml ou .yaml .

Na maioria dos casos, nenhuma configuração extra é necessária para seu aplicativo. Se seu aplicativo for executado com um arquivo process.json (padrão ou personalizado), ele deverá ter uma script propriedade na raiz JSON. Por exemplo:

{
  "name"        : "worker",
  "script"      : "./index.js",
  ...
}

Para configurar o Visual Studio Code para depuração remota, instale a App Service extension. Siga as instruções na página de extensão e entre no Azure no Visual Studio Code.

No explorador do Azure, localize a aplicação que pretende depurar, clique com o botão direito do rato na mesma e selecione Iniciar Depuração Remota. Selecione Sim para habilitar a depuração remota para seu aplicativo. O Serviço de Aplicativo inicia um proxy de túnel e anexa o depurador. Em seguida, você pode fazer solicitações para o aplicativo e ver o depurador pausando nos pontos de interrupção.

Quando terminar a depuração, pare o depurador selecionando Desconectar. Quando solicitado, você deve selecionar Sim para desativar a depuração remota. Para desativá-lo mais tarde, clique com o botão direito do mouse novamente no seu aplicativo no Azure explorer e selecione Desativar Depuração Remota.

Aceder a variáveis de ambiente

No Serviço de Aplicações, pode configurar as definições da aplicação fora do código da aplicação. Em seguida, você pode acessá-los usando o padrão Node.js padrão. Por exemplo, para aceder a uma definição da aplicação chamada NODE_ENV, utilize o seguinte código:

process.env.NODE_ENV

Executar Grunt/Bower/Gulp

Por padrão, a automação de compilação do Serviço de Aplicativo é executada npm install --production quando reconhece que um aplicativo Node.js é implantado via Git ou por meio da implantação Zip com a automação de compilação habilitada. Se seu aplicativo requer qualquer uma das ferramentas de automação populares, como Grunt, Bower ou Gulp, você precisa fornecer um script de implantação personalizado para executá-lo.

Para permitir que seu repositório execute essas ferramentas, você precisa adicioná-las às dependências no package.json. Por exemplo:

"dependencies": {
  "bower": "^1.7.9",
  "grunt": "^1.0.1",
  "gulp": "^3.9.1",
  ...
}

Em uma janela de terminal local, altere o diretório para a raiz do repositório e execute os seguintes comandos:

npm install kuduscript -g
kuduscript --node --scriptType bash --suppressPrompt

A raiz do repositório agora tem dois arquivos adicionais: .deployment e deploy.sh.

Abra deploy.sh e localize a seção, que tem esta Deployment aparência:

#############################################################
# Deployment
# ----------

No final desta seção, npm install --production é executado. Adicione a seção de código que você precisa para executar a ferramenta necessária no final da Deployment seção:

Para obter um exemplo, consulte o exemplo deMEAN.js. Neste exemplo, o script de implantação também executa um comando personalizado npm install .

Bower

Este trecho é executado bower install.

if [ -e "$DEPLOYMENT_TARGET/bower.json" ]; then
  cd "$DEPLOYMENT_TARGET"
  eval ./node_modules/.bin/bower install
  exitWithMessageOnError "bower failed"
  cd - > /dev/null
fi

Gulp

Este trecho é executado gulp imagemin.

if [ -e "$DEPLOYMENT_TARGET/gulpfile.js" ]; then
  cd "$DEPLOYMENT_TARGET"
  eval ./node_modules/.bin/gulp imagemin
  exitWithMessageOnError "gulp failed"
  cd - > /dev/null
fi

Grunt

Este trecho é executado grunt.

if [ -e "$DEPLOYMENT_TARGET/Gruntfile.js" ]; then
  cd "$DEPLOYMENT_TARGET"
  eval ./node_modules/.bin/grunt
  exitWithMessageOnError "Grunt failed"
  cd - > /dev/null
fi

Detetar sessão HTTPS

No Serviço de Aplicativo, a terminação TLS/SSL ocorre nos balanceadores de carga de rede, portanto, todas as solicitações HTTPS chegam ao seu aplicativo como solicitações HTTP não criptografadas. Se a lógica do seu aplicativo precisar verificar se as solicitações do usuário estão criptografadas, inspecione o X-Forwarded-Proto cabeçalho.

Frameworks da Web populares permitem-lhe aceder às X-Forwarded-* informações no seu padrão habitual de aplicações. No Express, você pode usar proxies de confiança. Por exemplo:

app.set('trust proxy', 1)
...
if (req.secure) {
  // Do something when HTTPS is used
}

Aceder aos registos de diagnósticos

Para aceder aos logs do console gerados a partir do código da sua aplicação no App Service, ative o registo de diagnóstico executando o seguinte comando no Cloud Shell:

az webapp log config --resource-group <resource-group-name> --name <app-name> --docker-container-logging filesystem --level Verbose

Os valores possíveis para --level são Error, Warning, Infoe Verbose. Cada nível subsequente inclui o nível anterior. Por exemplo, Error inclui apenas mensagens de erro. Verbose inclui todas as mensagens.

Depois de ativar o log de diagnóstico, execute o seguinte comando para ver o fluxo de log:

az webapp log tail --resource-group <resource-group-name> --name <app-name>

Se os logs do console não aparecerem imediatamente, verifique novamente em 30 segundos.

Para interromper o streaming de logs a qualquer momento, selecione Ctrl+C.

Você pode acessar os logs do console que são gerados de dentro do contêiner.

Para ativar o log de contêiner, execute o seguinte comando:

az webapp log config --name <app-name> --resource-group <resource-group-name> --docker-container-logging filesystem

Substitua <app-name> e <resource-group-name> por nomes apropriados para seu aplicativo Web.

Depois de ativar o log de contêiner, execute o seguinte comando para ver o fluxo de log:

az webapp log tail --name <app-name> --resource-group <resource-group-name>

Se os logs do console não aparecerem imediatamente, verifique novamente em 30 segundos.

Para interromper o streaming de logs a qualquer momento, selecione Ctrl+C.

Reescrita de URL

Ao implantar aplicativos Node.js no Serviço de Aplicativo do Azure para Linux, talvez seja necessário lidar com regravações de URL diretamente em seu aplicativo. Essa configuração é particularmente útil para garantir que padrões de URL específicos sejam redirecionados para os pontos de extremidade corretos sem depender das configurações do servidor Web. Há várias maneiras de realizar regravações de URL no Node.js. Um exemplo é usando o pacote express-urlrewrite .

Monitorar seu aplicativo usando o Application Insights

O Application Insights permite que você monitore o desempenho, as exceções e o uso do seu aplicativo sem fazer alterações no código. Para anexar o agente do Application Insights, vá para seu aplicativo Web no portal, selecione Application Insights em Monitoramento e selecione Ativar Application Insights. Em seguida, selecione um recurso existente do Application Insights ou crie um novo. Por fim, selecione Aplicar na parte inferior da página. Para instrumentar seu aplicativo Web usando o PowerShell, consulte estas instruções.

Esse agente monitorará seu aplicativo Node.js do lado do servidor. Para monitorar seu JavaScript do lado do cliente, adicione o SDK JavaScript ao seu projeto.

Para obter mais informações, consulte Habilitar o monitoramento de aplicativos no Serviço de Aplicativo do Azure para aplicativos .NET, Node.js, Python e Java.

Resolução de Problemas

Quando um aplicativo de Node.js em funcionamento se comportar de forma diferente no Serviço de Aplicativo ou tiver erros, tente o seguinte:

  • Acesse o fluxo de registo.
  • Teste o aplicativo localmente no modo de produção. O Serviço de Aplicativo executa seus aplicativos Node.js no modo de produção, portanto, você precisa garantir que seu projeto funcione como esperado no modo de produção localmente. Por exemplo:
    • Dependendo do seu package.json, pacotes diferentes podem ser instalados para o modo de produção (dependencies vs. devDependencies).
    • Certas estruturas da Web podem implantar arquivos estáticos de forma diferente no modo de produção.
    • Certas estruturas da Web podem usar scripts de inicialização personalizados quando executados no modo de produção.
  • Execute seu aplicativo no Serviço de Aplicativo no modo de desenvolvimento. Por exemplo, no MEAN.js, você pode definir seu aplicativo para o modo de desenvolvimento em tempo de execução NODE_ENV do aplicativo.

Você não tem permissão para visualizar este diretório ou página

Depois de implantar seu código Node.js em um aplicativo nativo do Windows no Serviço de Aplicativo, você poderá ver a mensagem You do not have permission to view this directory or page no navegador quando acessar a URL do aplicativo. Esse erro provavelmente está ocorrendo porque você não tem um arquivo web.config . (Veja o modelo e um exemplo.)

Se você implantar seus arquivos usando o Git ou usando a implantação ZIP com a automação de compilação habilitada, o mecanismo de implantação gerará um arquivo web.config na raiz da Web do seu aplicativo (%HOME%\site\wwwroot) automaticamente se uma das seguintes condições for verdadeira:

  • A raiz do projeto contém um arquivo package.json que define um start script que contém o caminho de um arquivo JavaScript.
  • A raiz do projeto contém um arquivoserver.js ou app.js .

O arquivo web.config gerado é adaptado ao script de início detetado. Para outros métodos de implantação, adicione o arquivo web.config manualmente. Verifique se o arquivo está formatado corretamente.

Se você usar a implantação ZIP (por meio do Visual Studio Code, por exemplo), certifique-se de habilitar a automação de compilação. Não está ativado por predefinição. az webapp up usa a implantação ZIP com a automação de compilação estando habilitada.

Ignorar a mensagem robots933456 nos logs

Poderá ver a seguinte mensagem nos registos de contentores:

2019-04-08T14:07:56.641002476Z "-" - - [08/Apr/2019:14:07:56 +0000] "GET /robots933456.txt HTTP/1.1" 404 415 "-" "-"

Pode ignorar esta mensagem. /robots933456.txt é um caminho de URL fictício que o Serviço de Aplicações utiliza para verificar se o contentor consegue satisfazer pedidos. Uma resposta 404 indica que o caminho não existe e sinaliza ao Serviço de Aplicativo que o contêiner está íntegro e pronto para responder às solicitações.

Conteúdo relacionado