Partilhar via

Configurar um aplicativo PHP no Serviço de Aplicativo do Azure

Advertência

PHP no Windows chegou ao final do suporte em novembro de 2022. PHP é suportado apenas para o Serviço de Aplicativo no Linux. Este artigo é apenas para referência.

Este guia mostra como configurar seus aplicativos Web PHP, back-ends móveis e aplicativos de API no Serviço de Aplicativo do Azure. As tarefas de configuração mais comuns são abordadas.

Se você for novo no Serviço de Aplicativo, primeiro siga o início rápido Criar um aplicativo Web PHP no Serviço de Aplicativo do Azure e o tutorial Implantar um aplicativo PHP, MySQL e Redis no Serviço de Aplicativo do Azure .

Mostrar a versão do PHP

Para mostrar a versão atual do PHP, execute o seguinte comando. Você pode usar o Azure Cloud Shell:

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

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

Observação

Para abordar um slot de desenvolvimento, inclua o parâmetro --slot seguido pelo nome do slot.

Para mostrar todas as versões suportadas do PHP, execute o seguinte comando:

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

Este guia mostra como configurar seus aplicativos Web PHP, back-ends móveis e aplicativos de API no Serviço de Aplicativo do Azure. As tarefas de configuração mais comuns são abordadas.

Se você for novo no Serviço de Aplicativo, primeiro siga o início rápido Criar um aplicativo Web PHP no Serviço de Aplicativo do Azure e o tutorial Implantar um aplicativo PHP, MySQL e Redis no Serviço de Aplicativo do Azure .

Mostrar a versão do PHP

Para mostrar a versão atual do PHP, execute o seguinte comando. Você pode usar o Azure Cloud Shell.

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

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

Observação

Para abordar um slot de desenvolvimento, inclua o parâmetro --slot seguido pelo nome do slot.

Para mostrar todas as versões suportadas do PHP, execute o seguinte comando:

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

Definir a versão do PHP

Para definir a versão do PHP como 8.1, execute o seguinte comando:

az webapp config set --resource-group <resource-group-name> --name <app-name> --php-version 8.1

Para definir a versão do PHP como 8.1, execute o seguinte comando:

az webapp config set --resource-group <resource-group-name> --name <app-name> --linux-fx-version "PHP|8.1"

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

Tempos de execução desatualizados são descontinuados pela organização responsável pela manutenção ou descobertos com 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, o modelo ARM ou o Bicep. Essas alternativas de implantação permitem criar tempos de execução obsoletos que foram removidos no portal, mas ainda estão a ser 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.

Executar Composer

Se você quiser que o Serviço de Aplicativo execute Composer no momento da implantação, a maneira mais fácil é incluir o Composer em seu repositório.

Em uma janela de terminal local, altere o diretório para o diretório raiz do seu repositório. Em seguida, siga as instruções em Download Composer para baixar composer.phar para a raiz do diretório.

Execute os seguintes comandos. Para executar, precisa ter npm instalado.

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

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

Abra o deploy.sh e localize a seção Deployment, que se parece com este exemplo:

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

No final da seção Deployment, adicione a seção de código que você precisa para executar a ferramenta necessária:

# 4. Use composer
echo "$DEPLOYMENT_TARGET"
if [ -e "$DEPLOYMENT_TARGET/composer.json" ]; then
  echo "Found composer.json"
  pushd "$DEPLOYMENT_TARGET"
  php composer.phar install $COMPOSER_ARGS
  exitWithMessageOnError "Composer install failed"
  popd
fi

Confirme todas as suas alterações e implante seu código usando o Git ou usando o ZIP deploy com automação de compilação habilitada. O Composer agora deve ser executado como parte da automação de implantação.

Executar Bower, Gulp ou Grunt

Se você quiser que o Serviço de Aplicativo execute ferramentas de automação populares no momento da implantação, como Bower, Gulp ou Grunt, precisará fornecer um script de implantação personalizado. O App Service executa este script quando se faz a implementação utilizando o Git ou o ZIP deploy com automação de compilação habilitada.

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. Para executar, precisa ter npm instalado.

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

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

Abra o deploy.sh e localize a seção Deployment, que se parece com este exemplo:

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

Esta seção termina com a execução npm install --production. No final da seção Deployment, adicione a seção de código que você precisa para executar a ferramenta necessária:

Veja um exemplo no exemplo MEAN.js, onde o script de implantação também executa um comando npm install personalizado.

Bower

Este trecho executa 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 executa 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

Grunhido

Este trecho executa grunt:

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

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 no Serviço de Aplicativo percorrerá a seguinte sequência:

  1. Execute um script personalizado caso PRE_BUILD_SCRIPT_PATH o indique.
  2. Execute php composer.phar install.
  3. Execute um script personalizado caso POST_BUILD_SCRIPT_PATH o indique.

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 especifica as duas variáveis para uma série de comandos, 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 outras variáveis de ambiente para personalizar a automação de compilação, consulte Configuração do Oryx.

Para saber como o Serviço de Aplicativo executa e cria aplicativos PHP no Linux, consulte a documentação do Oryx sobre como os aplicativos PHP são detetados e criados.

Personalizar inicialização

Você pode executar um comando personalizado no momento da inicialização do contêiner. Execute o seguinte comando:

az webapp config set --resource-group <resource-group-name> --name <app-name> --startup-file "<custom-command>"

Aceder a variáveis de ambiente

No Serviço de Aplicações, pode definir as definições da aplicação fora do código da aplicação. Em seguida, você pode acessar essas configurações usando o padrão getenv() padrão. Por exemplo, para acessar uma configuração de aplicativo chamada DB_HOST, use o seguinte código:

getenv("DB_HOST")

Alterar a raiz do site

A estrutura da Web de sua escolha pode usar um subdiretório como a raiz do site. Por exemplo, Laravel usa o subdiretório public/ como raiz do site.

Para personalizar a raiz do site, defina o caminho da aplicação virtual usando o comando az resource update. O exemplo a seguir define a raiz do site para o subdiretório public/ no repositório:

az resource update --name web --resource-group <group-name> --namespace Microsoft.Web --resource-type config --parent sites/<app-name> --set properties.virtualApplications[0].physicalPath="site\wwwroot\public" --api-version 2015-06-01

Por padrão, o Serviço de Aplicativo do Azure aponta o caminho do aplicativo virtual raiz (/) para o diretório raiz dos arquivos de aplicativo implantados (sites\wwwroot).

A estrutura da Web de sua escolha pode usar um subdiretório como a raiz do site. Por exemplo, Laravel usa o subdiretório public/ como raiz do site.

A imagem PHP padrão para o Serviço de Aplicativo usa NGINX e você altera a raiz do site configurando o servidor NGINX com a diretiva root. Este arquivo de configuração de exemplo contém o seguinte trecho que altera a root diretiva:

server {
    #proxy_cache cache;
    #proxy_cache_valid 200 1s;
    listen 8080;
    listen [::]:8080;
    root /home/site/wwwroot/public; # Changed for Laravel

    location / {            
        index  index.php index.html index.htm hostingstart.html;
        try_files $uri $uri/ /index.php?$args; # Changed for Laravel
    }
    ...

O contêiner padrão usa o arquivo de configuração em /etc/nginx/sites-available/default. Qualquer edição feita nesse arquivo é apagada quando o aplicativo é reiniciado. Para fazer uma alteração efetiva nas reinicializações do aplicativo, adicione um comando de inicialização personalizado como este exemplo:

cp /home/site/wwwroot/default /etc/nginx/sites-available/default && service nginx reload

Este comando substitui o arquivo de configuração NGINX padrão por um arquivo chamado default na raiz do repositório e reinicia o NGINX.

Detetar uma sessão HTTPS

No Serviço de Aplicativo, a terminação TLS/SSL acontece 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 cabeçalho X-Forwarded-Proto:

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
// Do something when HTTPS is used
}

Estruturas web populares permitem aceder às X-Forwarded-* informações no padrão da tua aplicação habitual. No CodeIgniter, a função is_https() verifica o valor de X_FORWARDED_PROTO por padrão.

Personalizar php.ini configurações

Se você precisar fazer alterações em sua instalação do PHP, você pode alterar qualquer uma das diretivas php.ini usando as etapas a seguir.

Observação

A melhor maneira de ver a versão do PHP e a configuração atual do php.ini é chamar phpinfo() na sua aplicação.

Personalizar diretivas que não sejam PHP_INI_SYSTEM

Para personalizar diretivas PHP_INI_USER, PHP_INI_PERDIRe PHP_INI_ALL, adicione um arquivo .user.ini ao diretório raiz do seu aplicativo.

Adicione definições de configuração ao arquivo .user.ini usando a mesma sintaxe que você usaria em um arquivo php.ini. Por exemplo, se você quisesse ativar a configuração display_errors e definir a configuração upload_max_filesize como 10M, seu arquivo .user.ini conteria este texto:

 ; Example Settings
 display_errors=On
 upload_max_filesize=10M

 ; Write errors to d:\home\LogFiles\php_errors.log
 ; log_errors=On

Reimplante seu aplicativo com as alterações e reinicie-o.

Como alternativa ao uso de um arquivo .user.ini, você pode usar ini_set() em seu aplicativo para personalizar essas diretivas nãoPHP_INI_SYSTEM.

Para personalizar PHP_INI_USER, PHP_INI_PERDIRe PHP_INI_ALL diretivas para aplicativos Web Linux, como upload_max_filesize e expose_php, use um arquivo .ini personalizado. Você pode criá-lo em uma sessão SSH . Primeiro, configure o diretório:

  1. Visite o seu site Kudu. Para obter os valores aleatórios de hash e região, em Visão geral do aplicativo, copie Domínio padrão.
  2. No menu superior, selecione Consola de depuração, depois Bash ou SSH.
  3. Em Bash ou SSH, vá para o diretório /home/site/wwwroot.
  4. Crie um diretório chamado ini (por exemplo, mkdir ini).
  5. Altere o diretório de trabalho atual para a ini pasta que você criou.

Em seguida, crie um arquivo .ini onde você adiciona suas configurações. Este exemplo utiliza extensions.ini. Não há editores de arquivos como Vi, Vim ou Nano, então use Echo para adicionar as configurações ao arquivo. Altere o upload_max_filesize valor de 2M para 50M. Use o seguinte comando para adicionar a configuração e criar um arquivo extensions.ini, se ainda não existir:

/home/site/wwwroot/ini>echo "upload_max_filesize=50M" >> extensions.ini
/home/site/wwwroot/ini>cat extensions.ini

upload_max_filesize=50M

/home/site/wwwroot/ini>

No portal do Azure, adicione uma configuração de aplicativo para verificar o diretório ini que você acabou de criar para aplicar a alteração para upload_max_filesize:

  1. Vá para o portal do Azure e selecione o seu aplicativo PHP Linux no App Service.
  2. Vá para Configurações>Variáveis de ambiente.
  3. Selecione + Adicionar.
  4. Em Nome , insira PHP_INI_SCAN_DIR e em Valor, digite :/home/site/wwwroot/ini.
  5. Selecione Aplicar e, em seguida, Aplicar novamente. Confirme as alterações.

Observação

Se você recompilou uma extensão PHP, como GD, siga as etapas em Recompilando extensões PHP.

Personalizar diretivas PHP_INI_SYSTEM

Para personalizar as diretivas PHP_INI_SYSTEM, use a configuração de aplicativo PHP_INI_SCAN_DIR.

Primeiro, execute o seguinte comando para adicionar uma configuração de aplicativo chamada PHP_INI_SCAN_DIR:

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings PHP_INI_SCAN_DIR="d:\home\site\ini"

No portal do Azure, selecione seu aplicativo. Em Ferramentas de Desenvolvimento no menu da barra lateral, selecione Ferramentas Avançadas e vá para d:\home\site Usando SSH.

Crie um diretório no d:\home\site chamado ini. Em seguida, crie um arquivo .ini no d:\home\site\ini diretório, por exemplo, settings.inicom as diretivas que você deseja personalizar. Use a mesma sintaxe que você usaria em um arquivo php.ini.

Por exemplo, para alterar o valor de expose_php, execute os seguintes comandos:

cd /home/site
mkdir ini
echo "expose_php = Off" >> ini/setting.ini

Para que as alterações entrem em vigor, reinicie o aplicativo.

Para personalizar PHP_INI_SYSTEM diretivas, não é possível usar a abordagem .htaccess . O App Service fornece um mecanismo separado que usa a configuração de aplicativo PHP_INI_SCAN_DIR.

Primeiro, execute o seguinte comando para adicionar uma configuração de aplicativo chamada PHP_INI_SCAN_DIR:

az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings PHP_INI_SCAN_DIR="/usr/local/etc/php/conf.d:/home/site/ini"

O valor /usr/local/etc/php/conf.d é o diretório padrão onde php.ini existe. O valor /home/site/ini é o diretório personalizado no qual você adiciona um arquivo de.ini personalizado. Separe os valores com dois pontos (:).

Vá para a sessão SSH da Web com seu contêiner Linux.

Crie um diretório no /home/site chamado ini. Em seguida, crie um arquivo .ini no /home/site/ini diretório, por exemplo, settings.inicom as diretivas que você deseja personalizar. Use a mesma sintaxe que você usaria em um arquivo php.ini.

Sugestão

Os contêineres Linux internos no Serviço de Aplicativo usam /home como armazenamento compartilhado persistente.

Por exemplo, para alterar o valor de expose_php, execute os seguintes comandos:

cd /home/site
mkdir ini
echo "expose_php = Off" >> ini/setting.ini

Para que as alterações entrem em vigor, reinicie o aplicativo.

Ativar extensões PHP

As instalações PHP incorporadas contêm as extensões mais comumente usadas. Você pode ativar mais extensões da mesma maneira que personaliza php.ini diretivas.

Observação

A melhor maneira de ver a versão do PHP e a configuração atual do php.ini é chamar phpinfo() na sua aplicação.

Para habilitar outras extensões, use as seguintes etapas:

  1. Adicione um bin diretório ao diretório raiz do seu aplicativo e coloque os arquivos de extensão.dll nele, por exemplo, mongodb.dll. Certifique-se de que as extensões são compatíveis com a versão do PHP no Azure e que elas sejam compatíveis com VC9 e não seguras para threads (NTS).

  2. Implante suas alterações.

  3. Siga os passos em Personalizar diretivas PHP_INI_SYSTEM, e adicione as extensões ao arquivo .ini personalizado com a diretiva extension ou zend_extension:

    extension=d:\home\site\wwwroot\bin\mongodb.dll
zend_extension=d:\home\site\wwwroot\bin\xdebug.dll

Para que as alterações entrem em vigor, reinicie o aplicativo.

As instalações PHP incorporadas contêm as extensões mais comumente usadas. Você pode ativar mais extensões da mesma maneira que personaliza php.ini diretivas.

Observação

A melhor maneira de ver a versão do PHP e a configuração atual do php.ini é chamar phpinfo() na sua aplicação.

Para habilitar outras extensões, use as seguintes etapas:

  1. Adicione um bin diretório ao diretório raiz do seu aplicativo e coloque os arquivos de extensão .so nele (por exemplo, mongodb.so). Certifique-se de que as extensões são compatíveis com a versão do PHP no Azure e que elas sejam compatíveis com VC9 e não seguras para threads (NTS).

  2. Implante suas alterações.

  3. Siga os passos em Personalizar diretivas PHP_INI_SYSTEM, e adicione as extensões ao arquivo .ini personalizado com a diretiva extension ou zend_extension:

    extension=/home/site/wwwroot/bin/mongodb.so
zend_extension=/home/site/wwwroot/bin/xdebug.so

Para que as alterações entrem em vigor, reinicie o aplicativo.

Aceder aos registos de diagnósticos

Use a ferramenta de error_log() padrão para fazer com que seus logs de diagnóstico apareçam no Serviço de Aplicativo do Azure.

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 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.

Solucionar problemas

Quando um aplicativo PHP em funcionamento se comportar de forma diferente no Serviço de Aplicativo ou tiver erros, tente as seguintes soluções:

  • Aceda ao fluxo de log de diagnóstico.
  • Teste o aplicativo localmente no modo de produção. O Serviço de Aplicativo executa seu aplicativo no modo de produção, portanto, você precisa garantir que seu projeto funcione conforme o esperado no modo de produção localmente. Por exemplo:
    • Dependendo do seu arquivo composer.json, pacotes diferentes podem ser instalados para o modo de produção (require versus require-dev).
    • 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 depuração. Por exemplo, em Laravel, você pode configurar seu aplicativo para gerar mensagens de depuração em produção definindo a configuração do aplicativo APP_DEBUG como true.

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