Compartilhar via

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

Aviso

O PHP no Windows chegou ao fim do suporte em novembro de 2022. O PHP tem suporte 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ê é novo no Serviço de Aplicativo, primeiro siga o guia de início rápido Criar um aplicativo web PHP no Azure App Service e o tutorial Implantar um aplicativo PHP, MySQL e Redis no Azure App Service.

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 endereçar um slot de desenvolvimento, inclua o parâmetro --slot seguido pelo nome do slot.

Para mostrar todas as versões do PHP suportadas, 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ê é novo no Serviço de Aplicativo, primeiro siga o guia de início rápido Criar um aplicativo web PHP no Azure App Service e o tutorial Implantar um aplicativo PHP, MySQL e Redis no Azure App Service.

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 endereçar um slot de desenvolvimento, inclua o parâmetro --slot seguido pelo nome do slot.

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

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

Defina a versão do PHP

Para definir a versão do PHP para 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 para 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 ambientes de execução obsoletos no Azure App Service?

Runtimes desatualizados são descontinuados pela entidade mantenedora ou apresentam vulnerabilidades significativas. Assim, eles são removidos da criação e configuração de páginas no portal. Quando um runtime desatualizado está oculto do portal, qualquer aplicativo que ainda esteja usando esse runtime continuará sendo executado.

Se você quiser criar um aplicativo com uma versão de runtime desatualizada que não seja mais mostrada no portal, use a CLI do Azure, o modelo do ARM ou o Bicep. Essas alternativas de implantação permitem que você crie tempos de execução preteridos que foram removidos do portal, mas que ainda têm suporte.

Se um runtime 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 o Composer no momento da implantação, a maneira mais fácil é incluir o Composer em seu repositório.

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

Execute os seguintes comandos. Para executá-los, você precisa do 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 deploy.sh e localize a Deployment seção, que se parece com este exemplo:

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

No final daDeployment seção, adicione a seção de código necessária 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

Registre todas as suas alterações e implante seu código usando Git ou via implantação via ZIP com automação de build habilitada. O Composer agora deve estar em execução como parte da automação de implantação.

Execute 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 Serviço de Aplicativo executa esse script quando você implanta usando o Git ou usando a implantação ZIP com a automação de build habilitada.

Para permitir que seu repositório execute essas ferramentas, você precisa adicioná-las às dependências do 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 comandos a seguir. Para executá-los, você precisa do 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 deploy.sh e localize a Deployment seção, que se parece com este exemplo:

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

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

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

Bower

Esse 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

Gole

Esse 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

Grunhir

Esse 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

Personalizar a automação de compilação

Se você implantar seu aplicativo usando o Git ou usando pacotes ZIP com a automação de build habilitada, a automação de build no Serviço de Aplicativo passará pela seguinte sequência:

  1. Execute um script personalizado se PRE_BUILD_SCRIPT_PATH especificar.
  2. Execute php composer.phar install.
  3. Execute um script personalizado se POST_BUILD_SCRIPT_PATH especificar.

PRE_BUILD_COMMAND e POST_BUILD_COMMAND são variáveis de ambiente vazias por padrão. Para executar comandos pré-build, defina PRE_BUILD_COMMAND. Para executar comandos pós-build, 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 obter outras variáveis de ambiente para personalizar a automação de build, veja Configuração do Oryx.

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

Personalizar a inicialização

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

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

Acessar as variáveis de ambiente

No Serviço de Aplicativo, você pode definir as configurações do aplicativo fora do código do aplicativo. Em seguida, você pode acessar essas configurações usando o padrão padrão getenv() . 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 raiz do site. Por exemplo, o Laravel usa o public/ subdiretório como raiz do site.

Para personalizar a raiz do site, defina o caminho do aplicativo virtual para o aplicativo usando o comando az resource update. O exemplo a seguir define a raiz do site para o public/ subdiretório em seu 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 raiz do aplicativo virtual (/) 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 raiz do site. Por exemplo, o Laravel usa o public/ subdiretório como raiz do site.

A imagem PHP padrão para o Serviço de Aplicativo usa o NGINX e você altera a raiz do site configurando o servidor NGINX com a root diretiva. Este arquivo de configuração de exemplo contém o seguinte snippet 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

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

Detectar uma sessão HTTPS

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

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

Estrutura Web populares permitem que você acesse informações do X-Forwarded-* no seu padrão de aplicativo básico. No CodeIgniter, a função is_https() verifica o valor de X_FORWARDED_PROTO por padrão.

Personalizar configurações do php.ini

Se você precisar fazer alterações na instalação do PHP, poderá alterar qualquer uma das diretivasphp.ini usando as etapas a seguir.

Observação

A melhor maneira de ver a versão do PHP e a configuração atual php.ini é chamar phpinfo() no seu aplicativo.

Personalizar diretivas diferentes de PHP_INI_SYSTEM

Para personalizar as diretivas PHP_INI_USER, PHP_INI_PERDIR e PHP_INI_ALL, adicione um .user.ini ao diretório raiz do seu aplicativo.

Adicione definições de configuração ao .user.ini arquivo usando a mesma sintaxe que você usaria em um php.ini arquivo. Por exemplo, se você quiser ativar a display_errors configuração e defini-la upload_max_filesize como 10M, seu .user.ini arquivo conterá 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, use ini_set() em seu aplicativo para personalizar essas não diretivas PHP_INI_SYSTEM.

Use um arquivo PHP_INI_USER personalizado para personalizar as diretivas PHP_INI_PERDIR, PHP_INI_ALL, e upload_max_filesize nos aplicativos web do Linux, como expose_php e . Você pode criá-lo em uma sessão SSH. Primeiro, configure o diretório:

  1. Acesse seu site Kudu. Para obter os valores aleatórios de hash e região, na Visão geral do aplicativo, copie Domínio padrão.
  2. No menu superior, selecione Console de depuração e, em seguida, Bash ou SSH.
  3. No Bash ou SSH, vá para o seu /home/site/wwwroot diretório.
  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 usa extensions.ini. Não há editores de arquivos como Vi, Vim ou Nano, portanto, use Echo para adicionar as configurações ao arquivo. Altere o valor upload_max_filesize de 2M para 50M. Use o seguinte comando para adicionar a configuração e criar um extensions.ini arquivo, caso ainda não exista:

/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 ini diretório que você acabou de criar para aplicar a alteração para upload_max_filesize:

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

Observação

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

Personalizar as diretivas do PHP_INI_SYSTEM

Para personalizar diretivas PHP_INI_SYSTEM, use a configuração do 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 em d:\home\site chamado ini. Em seguida, crie um arquivo .ini no d:\home\site\ini diretório, por exemplo, settings.ini, com as diretivas que você deseja personalizar. Use a mesma sintaxe que você usaria em um php.ini arquivo.

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 utilizar a abordagem .htaccess. O Serviço de Aplicativo fornece um mecanismo separado que utiliza 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 .ini personalizado. Você separa os valores com dois pontos (:).

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

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

Dica

Os contêineres internos do Linux no Serviço de Aplicativo utilizam /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.

Habilitar extensões PHP

As instalações PHP integradas contêm as extensões mais comumente usadas. Você pode habilitar mais extensões da mesma maneira como você personaliza diretivas php.ini.

Observação

A melhor maneira de ver a versão do PHP e a configuração atual php.ini é chamar phpinfo() no seu aplicativo.

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 .dll arquivos de extensão nele, por exemplo, mongodb.dll. Certifique-se de que as extensões sejam compatíveis com a versão do PHP no Azure e que sejam compatíveis com VC9 e não thread-safe (NTS).

  2. Implante suas alterações.

  3. Siga as etapas em Personalizar as diretivas PHP_INI_SYSTEM e adicione as extensões ao arquivo personalizado .ini com a diretiva extensão 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 integradas contêm as extensões mais comumente usadas. Você pode habilitar mais extensões da mesma maneira como você personaliza diretivas php.ini.

Observação

A melhor maneira de ver a versão do PHP e a configuração atual php.ini é chamar phpinfo() no seu aplicativo.

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 sejam compatíveis com a versão do PHP no Azure e que sejam compatíveis com VC9 e não thread-safe (NTS).

  2. Implante suas alterações.

  3. Siga as etapas em Personalizar as diretivas PHP_INI_SYSTEM e adicione as extensões ao arquivo personalizado .ini com a diretiva extensão 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.

Acessar registros de diagnóstico

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

Para acessar os logs de console gerados de dentro do código do aplicativo no Serviço de Aplicativo, ative o log 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, Info e Verbose. Cada nível seguinte inclui o anterior. Por exemplo, Error inclui apenas as 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 log 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êineres, 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 do 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 log a qualquer momento, selecione Ctrl+C.

Solucionar problemas

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

  • Acesse o 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 arquivo composer.json , pacotes diferentes podem ser instalados para o modo de produção (require versus require-dev).
    • Determinadas estruturas da web talvez implantem arquivos estáticos de maneira diferente no modo de produção.
    • Determinadas estruturas da web podem usar scripts de inicialização personalizados ao serem executadas no modo de produção.
  • Execute seu aplicativo no Serviço de Aplicativo no modo de depuração. Por exemplo, no 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.

Ignore a mensagem robots933456 nos logs

Você poderá ver a seguinte mensagem nos logs de contêiner:

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

Você pode ignorar essa mensagem com segurança. /robots933456.txt é um caminho de URL fictício que o Serviço de Aplicativo usa para verificar se o contêiner é capaz de atender a solicitações. 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