Поделиться через


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

Отображение версии 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 phpVersion

Примечание.

Чтобы обратиться к слоту разработки, включите параметр --slot, за которым следует имя слота.

Чтобы отобразить сведения обо всех поддерживаемых версиях 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

Примечание.

Чтобы обратиться к слоту разработки, включите параметр --slot, за которым следует имя слота.

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

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

как установить версию 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:

См. пример 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>"

Доступ к переменным среды

В Службе приложений можно задать параметры приложения вне кода приложения. Затем вы сможете получать к ним доступ, используя стандартный шаблон getenv(). Например, для доступа к параметру приложения с именем DB_HOST используйте следующий код:

getenv("DB_HOST")

Изменение корня сайта

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

Обнаружение сеанса HTTPS

В Службе приложений завершение TLS/SSL-запросов происходит в подсистеме балансировки нагрузки сети, поэтому все HTTPS-запросы достигают вашего приложения в виде незашифрованных HTTP-запросов. Если логика вашего приложения проверяет, зашифрованы ли пользовательские запросы, проверяйте заголовок X-Forwarded-Proto.

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

Популярные веб-платформы позволяют получить доступ к информации X-Forwarded-* в стандартном шаблоне приложения. В CodeIgniter функция is_https() по умолчанию проверяет значение X_FORWARDED_PROTO.

Настройка параметров php.ini

Если вам необходимо внести изменения в установку PHP, вы можете изменить любые директивы php.ini, выполнив следующие инструкции.

Примечание.

Оптимальный способ для просмотра версии PHP и текущей конфигурации php.ini — это вызов phpinfo() в приложении.

Настройка не относящихся к PHP_INI_SYSTEM директив

Чтобы настроить директивы 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, например GD, выполните действия по перекомпиляции расширений PHP в службе приложение Azure . Добавление расширений PHP

Настройка директив PHP_INI_SYSTEM

Чтобы настроить директивы 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.

Совет

Во встроенных контейнерах Linux в Службе приложений в качестве постоянного общего хранилища используется каталог /home.

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

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

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

Включение расширений PHP

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

Примечание.

Оптимальный способ для просмотра версии PHP и текущей конфигурации php.ini — это вызов phpinfo() в приложении.

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

Добавьте каталог 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.

Примечание.

Оптимальный способ для просмотра версии PHP и текущей конфигурации php.ini — это вызов phpinfo() в приложении.

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

Добавьте каталог 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 секунд.

Примечание.

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

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

Устранение неполадок

Если рабочее приложение PHP в Службе приложений ведет себя иначе или сообщает об ошибках, попробуйте сделать следующее:

  • Получите доступ к потоку журнала.
  • Протестируйте приложение локально в рабочем режиме. Служба приложений запускает ваше приложение в рабочем режиме, поэтому вам необходимо убедиться в том, что проект работает в таком режиме локально надлежащим образом. Пример:
    • В зависимости от содержимого файла composer.json для рабочего режима могут быть установлены разные пакеты (require или require-dev).
    • Некоторые веб-платформы в рабочем режиме могут выполнять другие операции при развертывании статических файлов.
    • Некоторые веб-платформы могут использовать специальные скрипты запуска в рабочем режиме.
  • Выполните свое приложение в Службе приложений в режиме отладки. Например, в Laravel вы можете настроить для приложения вывод сообщений отладки в производственной среде, задав для параметра приложения APP_DEBUG значение true.

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

Следующие шаги

Дополнительные ресурсы:

Справка по переменным среды и параметрам приложений