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

Artigo
11/11/2023

Mostrar versão do PHP

Aviso

O PHP no Windows chegou ao fim da vida útil em novembro de 2022 e só é suportado no 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.

Este guia fornece conceitos-chave e instruções para desenvolvedores PHP que implantam aplicativos no Serviço de Aplicativo. Se você nunca usou o Serviço de Aplicativo do Azure, siga o tutorial de início rápido do PHP e do PHP com MySQL primeiro.

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

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

Nota

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 no Cloud Shell:

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.

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

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

Nota

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 no Cloud Shell:

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

Definir versão do PHP

Execute o seguinte comando no Cloud Shell para definir a versão do PHP como 8.1:

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

Execute o seguinte comando no Cloud Shell para definir a versão do PHP como 8.1:

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

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

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

Execute os seguintes comandos (você precisa do npm instalado):

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

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

# 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 implante Zip com a automação de compilação habilitada. O Composer agora deve ser executado como parte da automação de implantação.

Executar Grunt/Bower/Gulp

Se quiser que o Serviço de Aplicativo execute ferramentas de automação populares no momento da implantação, como Grunt, Bower ou Gulp, você precisará fornecer um script de implantação personalizado. O Serviço de Aplicativo executa esse script quando você implanta com o Git ou com a implantação Zip com a automação de compilação habilitada.

Para permitir que seu repositório execute essas ferramentas, você precisa adicioná-las às dependências em 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 (você precisa do npm instalado):

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

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

Bower
Gulp
Grunt

Veja um exemplo no exemplo MEAN.js, onde o script de implantação também executa um comando personalizadonpm 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

Personalizar a automatização de compilação

Se você implantar seu aplicativo usando o Git ou usando pacotes zip com a automação de compilação habilitada, a automação de compilação do Serviço de Aplicativo percorrerá a seguinte sequência:

Execute um script personalizado se especificado pelo PRE_BUILD_SCRIPT_PATH.
Execute o php composer.phar install.
Execute um script personalizado se especificado pelo POST_BUILD_SCRIPT_PATH.

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 obter 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 PHP no Linux, consulte a documentação do Oryx: Como os aplicativos PHP são detetados e criados.

Personalizar o arranque

Se desejar, você pode executar um comando personalizado no momento de inicialização do contêiner, executando o seguinte comando no Cloud Shell:

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 configurar as definições da aplicação fora do código da aplicação. Então você pode acessá-los usando o padrão getenv() padrão. Por exemplo, para aceder a uma definição da aplicação chamada DB_HOST, utilize o seguinte código:

getenv("DB_HOST")

Alterar 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 a raiz do site.

Para personalizar a raiz do site, defina o caminho do aplicativo virtual para o aplicativo usando o az resource update comando. O exemplo a seguir define a raiz do site como o subdiretório public/ 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 predefinição, o Serviço de Aplicações do Azure aponta o caminho de aplicação virtual de raiz (/) para o diretório de raiz dos ficheiros de aplicação implementados (sites\wwwroot).

A estrutura da Web de sua escolha pode usar um subdiretório como a raiz do site. Por exemplo, Laravel, usa o public/ subdiretório como a 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 root diretiva. Este arquivo de configuração de exemplo contém os seguintes trechos que alteram 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 encontrado em /etc/nginx/sites-available/default. Lembre-se de que qualquer edição feita nesse arquivo será apagada quando o aplicativo for reiniciado. Para fazer uma alteração que seja 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 padrão do Nginx por um arquivo chamado padrão na raiz do repositório e reinicia o Nginx.

Detetar 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 da aplicação precisar de verificar se os pedidos do utilizador estão ou não encriptados, 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 da Web populares permitem que você acesse as X-Forwarded-* informações em seu padrão de aplicativo padrão. No CodeIgniter, o is_https() verifica o valor de X_FORWARDED_PROTO por padrão.

Personalizar as configurações .ini php

Se você precisar fazer alterações na sua instalação do PHP, você pode alterar qualquer uma das diretivas php.ini seguindo estas etapas.

Nota

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

Personalizar diretivas não PHP_INI_SYSTEM

Para personalizar diretivas PHP_INI_USER, PHP_INI_PERDIR e PHP_INI_ALL (consulte diretivas php.ini), adicione um .user.ini arquivo 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ê quisesse ativar a configuração e definir upload_max_filesize a display_errors configuração como 10M, seu .user.ini arquivo 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 .user.ini arquivo, você pode usar ini_set() em seu aplicativo para personalizar essas diretivas não PHP_INI_SYSTEM.

Para personalizar diretivas PHP_INI_USER, PHP_INI_PERDIR e PHP_INI_ALL 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.

Vá para o seu site KUDU https://< sitename.scm.azurewebsites.net>.
Selecione Bash ou SSH no menu superior.
Em Bash/SSH, vá para o diretório "/home/site/wwwroot".
Crie um diretório chamado "ini" (por exemplo, mkdir ini).
Altere o diretório de trabalho atual para a pasta "ini" que você acabou de criar.

Você precisa criar um arquivo "ini" para adicionar suas configurações. Neste exemplo, usamos "extensões.ini". Não há editores de arquivos como Vi, Vim ou Nano, então você usará echo para adicionar as configurações ao arquivo. Altere o "upload_max_filesize" de 2M para 50M. Use o comando a seguir 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>

Em seguida, vá para o portal do Azure e 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.

Vá para o portal do Azure e selecione seu aplicativo PHP Linux do Serviço de Aplicativo.
Selecione Configurações do aplicativo para o aplicativo.
Na seção Configurações do aplicativo, selecione + Adicionar nova configuração.
Para o Nome da configuração do aplicativo, digite "PHP_INI_SCAN_DIR" e, para o valor, digite "/home/site/wwwroot/ini".
Selecione o botão Salvar.

Nota

Se você recompilou uma extensão PHP, como GD, siga as etapas em Recompilando extensões PHP no Serviço de Aplicativo do Azure - Adicionando extensões PHP

Personalizar diretivas PHP_INI_SYSTEM

Para personalizar PHP_INI_SYSTEM diretivas (consulte php.ini diretivas), use a configuração do PHP_INI_SCAN_DIR aplicativo.

Primeiro, execute o seguinte comando no Cloud Shell 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"

Navegue até o console do Kudu (https://<app-name>.scm.azurewebsites.net/DebugConsole) e navegue até d:\home\site.

Crie um diretório no chamado inie, em d:\home\site seguida, crie um arquivo .ini no d:\home\site\ini diretório (por exemplo, configurações.ini) com 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 (consulte php.ini diretivas), você não pode usar a abordagem .htaccess . O Serviço de Aplicativo fornece um mecanismo separado usando a configuração do PHP_INI_SCAN_DIR aplicativo.

Primeiro, execute o seguinte comando no Cloud Shell 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"

/usr/local/etc/php/conf.d é o diretório padrão onde o php.ini existe. /home/site/inié o diretório personalizado no qual você adicionará um arquivo de .ini personalizado. Separe os valores com um :arquivo .

Navegue até a sessão SSH da Web com seu contêiner Linux (https://<app-name>.scm.azurewebsites.net/webssh/host).

Crie um diretório no chamado inie, em /home/site seguida, crie um arquivo .ini no /home/site/ini diretório (por exemplo, configurações.ini) com as diretivas que você deseja personalizar. Use a mesma sintaxe que você usaria em um arquivo php.ini .

Gorjeta

Nos contêineres Linux internos no Serviço de Aplicativo, /home é usado 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 habilitar extensões adicionais da mesma forma que personaliza as diretivas php.ini.

Nota

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

Para habilitar extensões adicionais, siga estas etapas:

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

Implante suas alterações.

Siga as etapas em Personalizar diretivas PHP_INI_SYSTEM, adicione as extensões ao arquivo de .ini personalizado com a extensão ou zend_extension diretivas.

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 habilitar extensões adicionais da mesma forma que personaliza as diretivas php.ini.

Nota

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

Para habilitar extensões adicionais, siga estas etapas:

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

Implante suas alterações.

Siga as etapas em Personalizar diretivas PHP_INI_SYSTEM, adicione as extensões ao arquivo de .ini personalizado com a extensão ou zend_extension diretivas.

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 o utilitário 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 registos da consola gerados a partir do código da sua aplicação no Serviço de Aplicações, ative o registo de diagnósticos ao executar 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 subsequente inclui o nível anterior. Por exemplo: Error inclui apenas mensagens de erro e Verbose inclui todas as mensagens.

Depois de ativar o registo de diagnósticos, execute o seguinte comando para ver o fluxo de registos:

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

Se não vir os registos da consola imediatamente, volte a consultar dentro de 30 segundos.

Nota

Também pode inspecionar os ficheiros de registo no browser em https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Para parar a transmissão de registos em qualquer altura, escreva Ctrl+C.

Você pode acessar os logs do console gerados de dentro do contêiner.

Primeiro, ative o log de contêiner executando 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> pelos nomes apropriados para seu aplicativo Web.

Quando o log de contêiner estiver ativado, execute o seguinte comando para ver o fluxo de log:

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

Se não vir os registos da consola imediatamente, volte a consultar dentro de 30 segundos.

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

Você também pode inspecionar os arquivos de log em um navegador em https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Resolução de problemas

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

Acesse o fluxo de log.
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 composer.json, pacotes diferentes podem ser instalados para o modo de produção (require vs. 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, no Laravel, você pode configurar seu aplicativo para gerar mensagens de depuração em produção definindo a configuração do APP_DEBUG aplicativo como true.

robots933456 nos registos

Pode ver a seguinte mensagem nos registos do contentor:

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 simplesmente que o caminho não existe, mas permite que o Serviço de Aplicações saiba que o contentor está em bom estado de funcionamento e pronto para responder aos pedidos.

Próximos passos

Tutorial: Aplicativo PHP com MySQL

FAQ do Serviço de Aplicações no Linux

Ou consulte recursos adicionais:

Referência de variáveis de ambiente e configurações de aplicativo

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

Mostrar versão do PHP

Definir versão do PHP

Executar o Composer

Executar Grunt/Bower/Gulp

Bower

Gulp

Grunt

Personalizar a automatização de compilação

Personalizar o arranque

Aceder a variáveis de ambiente

Alterar raiz do site

Detetar sessão HTTPS

Personalizar as configurações .ini php

Personalizar diretivas não PHP_INI_SYSTEM

Personalizar diretivas PHP_INI_SYSTEM

Ativar extensões PHP

Aceder aos registos de diagnósticos

Resolução de problemas

robots933456 nos registos

Próximos passos

Recursos adicionais