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

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

Это руководство содержит основные понятия и инструкции для разработчиков для PHP, использующих Службу приложений. Если вы раньше не использовали Службу приложений Azure, сначала ознакомьтесь с кратким руководством по PHP и руководством по использованию PHP с MySQL.

Чтобы отобразить сведения о текущей версии PHP, выполните следующую команду в 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 и руководством по использованию PHP с MySQL.

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

Запуск Grunt/Bower/Gulp

Если вы хотите, чтобы Служба приложений запускала во время развертывания такие популярные средства автоматизации, как, например Grunt, Bower или Gulp, вам потребуется добавить собственный скрипт развертывания. Служба приложений запускает этот скрипт при развертывании с помощью 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:

• Bower
• Gulp;
• Grunt

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

Bower

Этот фрагмент кода отвечает за запуск 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

Этот фрагмент кода отвечает за запуск 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

Этот фрагмент кода отвечает за запуск 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.

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

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

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

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 по умолчанию на файл с именем по умолчанию в корневом каталоге репозитория и перезапускает Nginx.

Чтобы настроить директивы PHP_INI_USER, PHP_INI_PERDIR и PHP_INI_ALL (см. дополнительные сведения о директивах php.ini), добавьте файл .user.ini в корневой каталог приложения.

Добавьте параметры конфигурации в файл .user.ini, используя тот же синтаксис, что и для файла php.ini. Например, чтобы включить параметр display_errors и установить для параметра upload_max_filesize значение 10 МБ, в файле .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 https://< sitename.scm.azurewebsites.net>.
2. Выберите Bash или SSH в верхнем меню.
3. В Bash/SSH перейдите в каталог "/home/site/wwwroot".
4. Создайте каталог с именем ini (например, mkdir ini).
5. Измените текущий рабочий каталог на только что созданную папку ini.

Чтобы добавить параметры в файл ini, необходимо создать файл ini. В этом примере используется extensions.ini. Нет редакторов файлов, таких как Vi, Vim или Nano, поэтому вы будете использовать эхо для добавления параметров в файл. Измените значение "upload_max_filesize" с 2М на 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), используйте 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"

Откройте консоль KUDU (https://<app-name>.scm.azurewebsites.net/DebugConsole) и перейдите к d:\home\site.

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

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

Создайте каталог по пути /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.

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

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

Примените изменения.

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

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

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

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

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

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

Примените изменения.

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

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

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

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

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

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

robots933456 в журналах

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

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 означает, что путь не существует. При этом он информирует Службу приложений о том, что контейнер работоспособен и готов отвечать на запросы.