Настройка приложения PHP для Службы приложений Azure

В этом руководстве показано, как настроить веб-приложения PHP, мобильные серверные части и приложения API в Службе приложений Azure.

В этом руководстве представлены основные понятия и инструкции для разработчиков PHP, которые развертывают приложения в службе приложений. Если вы никогда не использовали службу приложений, сначала следует следовать краткому руководству по созданию веб-приложения PHP в Службе приложений Azureи развертыванию приложения PHP, MySQL и Redis в Службе приложений Azure .

Отображение версии PHP

Чтобы отобразить текущую версию PHP, выполните следующую команду в Azure Cloud Shell:

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

Чтобы отобразить все поддерживаемые версии PHP, выполните следующую команду в Cloud Shell:

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

В этом руководстве показано, как настроить веб-приложения PHP, мобильные серверные части и приложения API в Службе приложений Azure.

В этом руководстве представлены основные понятия и инструкции для разработчиков PHP, которые развертывают приложения в службе приложений. Если вы никогда не использовали Службу приложений Azure, сначала следует следовать краткому руководству по созданию веб-приложения PHP в Службе приложений Azure и развертыванию приложения PHP, MySQL и Redis в Службе приложений Azure .

Отображение версии PHP

Чтобы отобразить текущую версию PHP, выполните следующую команду в Azure Cloud Shell:

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

Чтобы отобразить все поддерживаемые версии PHP, выполните следующую команду в Cloud Shell:

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

Выполните следующую команду в Cloud Shell , чтобы задать для PHP версию 8.1:

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

Выполните следующую команду в Cloud Shell , чтобы задать для PHP версию 8.1:

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

Запустить Composer

Если вы хотите, чтобы служба приложений запускала Composer во время развертывания, проще всего включить Composer в репозиторий.

В окне локального терминала измените каталог на корневой каталог репозитория. Затем следуйте инструкциям в разделе "Скачать composer ", чтобы скачать composer.phar в корневой каталог.

Выполните следующие команды. Чтобы запустить их, необходимо установить npm .

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

Корневой каталог репозитория теперь содержит два дополнительных файла: .deployment и deploy.sh.

Откройте deploy.sh и найдите Deployment раздел, который выглядит следующим образом:

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

В концеDeployment раздела добавьте код, который нужно запустить для необходимого средства.

# 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

Зафиксируйте все изменения и разверните код с помощью Git или с помощью ZIP-развертывания с включенной автоматизацией сборки. Теперь композитор должен работать в рамках автоматизации развертывания.

Run Bower, Gulp, or Grunt

Если вы хотите, чтобы служба приложений выполняла популярные средства автоматизации во время развертывания (например, Bower, Gulp или Grunt), необходимо предоставить настраиваемый сценарий развертывания. Служба приложений запускает этот скрипт при развертывании с помощью Git или с помощью ZIP-развертывания с включенной автоматизацией сборки.

To enable your repository to run these tools, you need to add them to the dependencies in package.json. Рассмотрим пример.

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

В окне локального терминала измените каталог на корневой каталог репозитория и выполните следующие команды. Чтобы запустить их, необходимо установить npm .

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

Корневой каталог репозитория теперь содержит два дополнительных файла: .deployment и deploy.sh.

Откройте deploy.sh и найдите Deployment раздел, который выглядит следующим образом:

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

This section ends with running npm install --production. В концеDeployment раздела добавьте код, который нужно запустить для необходимого средства.

• Bower
• Gulp;
• Grunt

См. пример MEAN.js, где скрипт развертывания также выполняет пользовательскую команду npm install.

Bower

This snippet runs 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

This snippet runs 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

This snippet runs grunt:

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

Настройка автоматизации сборки

При развертывании приложения с помощью Git или с помощью ZIP-пакетов с включенной автоматизацией сборки служба приложений выполняет следующие действия.

1. Запустите пользовательский скрипт, если PRE_BUILD_SCRIPT_PATH указывает его.
2. Run php composer.phar install.
3. Запустите пользовательский скрипт, если POST_BUILD_SCRIPT_PATH указывает его.

PRE_BUILD_COMMAND и POST_BUILD_COMMAND являются переменными среды, которые по умолчанию пустые. Чтобы выполнить команды перед сборкой, определите PRE_BUILD_COMMAND. Чтобы выполнить команды после сборки, определите POST_BUILD_COMMAND.

В следующем примере указываются две переменные в ряд команд, разделенных запятыми:

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"

Дополнительные переменные среды для настройки автоматизации сборки см. в разделе "Конфигурация Oryx".

Дополнительные сведения о том, как служба приложений запускает и создает приложения PHP в Linux, см. в документации по Ориксу о том, как обнаруживаются и создаются приложения PHP.

Настройка запуска

Если вы хотите, можно выполнить настраиваемую команду во время запуска контейнера. Выполните следующую команду в Cloud Shell:

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

Веб-платформа вашего выбора может использовать подкаталог в качестве корневого каталога сайта. Например, Laravel использует public/ подкаталог в качестве корневого каталога сайта.

Чтобы настроить корневой каталог сайта, задайте путь виртуального приложения для приложения с помощью az resource update команды. The following example sets the site root to the public/ subdirectory in your repository:

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

По умолчанию служба приложений Azure указывает корневой путь к виртуальному приложению (/) корневому каталогу развернутых файлов приложений (sites\wwwroot).

Веб-платформа вашего выбора может использовать подкаталог в качестве корневого каталога сайта. Например, Laravel использует public/ подкаталог в качестве корневого каталога сайта.

Образ PHP по умолчанию для службы приложений использует NGINX, и вы изменяете корневой каталог сайта, настроив сервер NGINX с помощью директивыroot. В этом примере файла конфигурации содержится следующий фрагмент кода, который изменяет директиву root :

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

Контейнер по умолчанию использует файл конфигурации по адресу /etc/nginx/sites-available/default. Помните, что при перезапуске приложения все изменения, внесенные в этот файл, удаляются. Чтобы внести изменения, действующие во время перезапуска приложения, добавьте пользовательскую команду запуска , как в следующем примере:

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

Эта команда заменяет файл конфигурации NGINX по умолчанию на файл с именем default в корневом каталоге репозитория и перезапускает NGINX.

Чтобы настроить PHP_INI_USERи PHP_INI_PERDIRPHP_INI_ALL директивы, добавьте .user.ini файл в корневой каталог приложения.

Добавьте параметры конфигурации в .user.ini файл с помощью того же синтаксиса, что и в php.ini файле. Например, если вы хотите включить параметр display_errors и задать параметру upload_max_filesize значение 10M, ваш файл .user.ini будет содержать следующий текст:

 ; Example Settings
 display_errors=On
 upload_max_filesize=10M

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

Повторно разверните приложение с изменениями и перезапустите его.

В качестве альтернативы использованию файла .user.ini, вы можете использовать ini_set() в вашем приложении для настройки этих директив, не относящихся к PHP_INI_SYSTEM.

Чтобы настроить PHP_INI_USER, PHP_INI_PERDIRи PHP_INI_ALL директивы для веб-приложений Linux, например upload_max_filesize и expose_php, используйте пользовательский файл .ini. Его можно создать в сеансе SSH. Сначала настройте каталог:

1. Go to your Kudu site: https://<sitename>.scm.azurewebsites.net.
2. В верхнем меню выберите Bash или SSH.
3. Через Bash или SSH перейдите в ваш /home/site/wwwroot каталог.
4. Создайте каталог с именем ini (например, mkdir ini).
5. Измените текущий рабочий каталог на только что созданную папку ini .

Теперь создайте файл .ini, в котором вы добавите параметры. В этом примере используется extensions.ini. Нет таких редакторов файлов, как Vi, Vim или Nano, поэтому используйте Echo для добавления параметров в файл. Измените значение параметра upload_max_filesize с 2M на 50M. Используйте следующую команду, чтобы добавить параметр и создать extensions.ini файл, если он еще не существует:

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

In the Azure portal, add an application setting to scan the ini directory that you just created to apply the change for upload_max_filesize:

1. Перейдите на портал Azure и выберите ваше приложение PHP на Linux в App Service.
2. В разделе "Параметры приложения" выберите +Добавить новый параметр.
3. Введите имя параметра приложения PHP_INI_SCAN_DIR. Введите значение :/home/site/wwwroot/ini.
4. Выберите Сохранить.

Чтобы настроить PHP_INI_SYSTEM директивы, используйте PHP_INI_SCAN_DIR параметр приложения.

Сначала выполните следующую команду в Cloud Shell, чтобы добавить параметр приложения: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"

Go to the Kudu console (https://<app-name>.scm.azurewebsites.net/DebugConsole), and then go to d:\home\site.

Create a directory in d:\home\site called ini. Затем создайте файл .ini в d:\home\site\ini каталоге (например, settings.iniс директивами, которые требуется настроить). Используйте тот же синтаксис, который будет использоваться в php.ini файле.

Например, чтобы изменить значение expose_php, выполните следующие команды:

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

Чтобы изменения вступили в силу, перезапустите приложение.

Для настройки PHP_INI_SYSTEM директив нельзя использовать .htaccess подход. Служба приложений предоставляет отдельный механизм, использующий PHP_INI_SCAN_DIR параметр приложения.

Сначала выполните следующую команду в Cloud Shell, чтобы добавить параметр приложения: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 является каталог по умолчанию, где php.ini существует. The value /home/site/ini is the custom directory in which you'll add a custom .ini file. Значения разделяются двоеточием (:).

Перейдите к сеансу веб-SSH с контейнером Linux (https://<app-name>.scm.azurewebsites.net/webssh/host).

Create a directory in /home/site called ini. Затем создайте файл .ini в /home/site/ini каталоге (например, settings.iniс директивами, которые требуется настроить). Используйте тот же синтаксис, который будет использоваться в php.ini файле.

Например, чтобы изменить значение expose_php, выполните следующие команды:

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

Чтобы изменения вступили в силу, перезапустите приложение.

Встроенные установки PHP содержат наиболее часто используемые расширения. You can enable additional extensions in the same way that you customize php.ini directives.

Чтобы включить дополнительные расширения, выполните следующие действия.

1. Add a bin directory to the root directory of your app, and put the .dll extension files in it (for example, mongodb.dll). Make sure that the extensions are compatible with the PHP version in Azure, and that they're VC9 and non-thread-safe (NTS) compatible.

2. Deploy your changes.

3. Выполните действия, описанные в разделе "Настройка директив PHP_INI_SYSTEM", и добавьте расширения в пользовательский файл .ini с помощью директивы расширения или zend_extension :

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

Чтобы изменения вступили в силу, перезапустите приложение.

Встроенные установки PHP содержат наиболее часто используемые расширения. You can enable additional extensions in the same way that you customize php.ini directives.

Чтобы включить дополнительные расширения, выполните следующие действия.

1. Add a bin directory to the root directory of your app, and put the .so extension files in it (for example, mongodb.so). Make sure that the extensions are compatible with the PHP version in Azure, and that they're VC9 and non-thread-safe (NTS) compatible.

2. Deploy your changes.

3. Выполните действия, описанные в разделе "Настройка директив PHP_INI_SYSTEM", и добавьте расширения в пользовательский файл .ini с помощью директивы расширения или zend_extension :

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

Чтобы изменения вступили в силу, перезапустите приложение.

Используйте стандартное error_log() средство для отображения журналов диагностики в Службе приложений Azure.

Чтобы получить доступ к журналам консоли, созданным из кода приложения в Службе Приложений, включите ведение журнала диагностики, выполнив следующую команду в Cloud Shell:

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

Возможные значения для --level: Error, Warning, Info и Verbose. Каждый последующий уровень включает предыдущий уровень. Например, Error включает только сообщения об ошибках. Verbose включает все сообщения.

После включения ведения журнала диагностики выполните следующую команду, чтобы просмотреть поток журналов:

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

Если журналы консоли не отображаются немедленно, повторите попытку через 30 секунд.

Чтобы остановить потоковую передачу журналов в любое время, нажмите клавиши CTRL+C.

Вы можете получить доступ к консольным логам, которые генерируются внутри контейнера.

Чтобы включить ведение журнала контейнеров, выполните следующую команду:

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

Замените #D0 и #D1 именами, подходящими для веб-приложения.

После включения ведения журнала контейнеров выполните следующую команду, чтобы просмотреть поток журналов:

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

Если журналы консоли не отображаются немедленно, повторите попытку через 30 секунд.

Чтобы остановить потоковую передачу журналов в любое время, нажмите клавиши CTRL+C.

Вы также можете проверить файлы журнала в браузере на странице https://<app-name>.scm.azurewebsites.net/api/logs/docker.

Ignore the robots933456 message in logs

В журналах контейнеров может появиться следующее сообщение:

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

Это сообщение можно проигнорировать. /robots933456.txt — это фиктивный URL-путь, с помощью которого Служба приложений проверяет, может ли контейнер обслуживать запросы. Ответ 404 указывает, что путь не существует, и он сигнализирует службе приложений о том, что контейнер работоспособен и готов реагировать на запросы.

• Служба приложений Azure на платформе Linux: вопросы и ответы