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

В этом руководстве показано, как настроить веб-приложения PHP, мобильные серверные части и приложения API в Службе приложений 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 phpVersion

Замените <resource-group-name> и <app-name> на имена, соответствующие вашему веб-приложению.

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

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

В этом руководстве показано, как настроить веб-приложения PHP, мобильные серверные части и приложения API в Службе приложений 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

Замените <resource-group-name> и <app-name> на имена, соответствующие вашему веб-приложению.

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

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

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

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

Чтобы установить версию 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-развертывания с включенной автоматизацией сборки. Теперь композитор должен работать в рамках автоматизации развертывания.

Запустите Bower, Gulp или Grunt

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

Чтобы позволить вашему репозиторию использовать эти средства, необходимо добавить их в зависимости в 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
# ----------

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

• Шалаш
• Глоток
• Хрюкать

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

Беседка

Этот фрагмент кода выполняется 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 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:

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. Выполните 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".

Чтобы узнать, как App Service запускает и создает приложения PHP в Linux, см. документацию Oryx о том, как обнаруживаются и создаются приложения PHP.

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

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

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

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

Чтобы настроить корневой каталог сайта, задайте путь виртуального приложения для приложения с помощью az resource update команды. В следующем примере корневой каталог сайта устанавливается в качестве подкаталога public/ в репозитории.

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. Зайдите на свой сайт Kudu. Чтобы получить значения случайного хэша и региона, в обзоре приложения скопируйте домен по умолчанию.
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>

На портале Azure добавьте параметр приложения, чтобы проверить ini только что созданный каталог для применения изменения для upload_max_filesize:

1. Перейдите на портал Azure и выберите приложение PHP службы приложений Для Linux.
2. Перейдите в Настройки>Переменные среды.
3. Выберите + Добавить.
4. В поле "Имя" введите PHP_INI_SCAN_DIR, а в поле "Значение" введите :/home/site/wwwroot/ini.
5. Нажмите Применить, а затем снова Применить. Подтвердите изменения.

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

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

На портале Azure выберите приложение. В разделе Средства разработки в меню на боковой панели выберите Дополнительные средства, а затем перейдите к d:\home\site использованию SSH.

Создайте каталог с d:\home\site именем 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 параметр приложения.

Сначала выполните следующую команду, чтобы добавить параметр приложения с именем 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 существует. Значение /home/site/ini — это пользовательский каталог, в который вы добавляете файл .ini. Значения разделяются двоеточием (:).

Перейдите в веб-сеанс SSH с контейнером Linux.

Создайте каталог с /home/site именем ini. Затем создайте файл .ini в каталоге /home/site/ini, например settings.ini, с директивами, которые вы хотите настроить. Используйте тот же синтаксис, который будет использоваться в php.ini файле.

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

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

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

Встроенные установки PHP содержат наиболее часто используемые расширения. Вы можете включить больше расширений таким же образом, как и настроить директивы php.ini.

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

1. Добавьте каталог bin в корневую директорию вашего приложения и поместите в него файлы расширения .dll, например mongodb.dll. Убедитесь, что расширения совместимы с версией PHP в Azure, а также с VC9 и не используют потоковую безопасность (NTS).

2. Разверните изменения.

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 содержат наиболее часто используемые расширения. Вы можете включить больше расширений таким же образом, как и настроить директивы php.ini.

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

1. bin Добавьте каталог в корневой каталог вашего приложения и поместите в него файлы с расширением .so (например, mongodb.so). Убедитесь, что расширения совместимы с версией PHP в Azure, а также с VC9 и не используют потоковую безопасность (NTS).

2. Разверните изменения.

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

Замените <app-name> и <resource-group-name> на имена, соответствующие вашему веб-приложению.

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

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

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

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

Игнорировать сообщение робота933456 в журналах

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

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