Udostępnij przez


Konfigurowanie aplikacji PHP w Azure App Service

Ostrzeżenie

Język PHP w systemie Windows osiągnął koniec wsparcia w listopadzie 2022 r. Język PHP jest obsługiwany tylko w przypadku usługi App Service w systemie Linux. Ten artykuł dotyczy tylko informacji referencyjnych.

W tym przewodniku przedstawiono sposób konfigurowania aplikacji internetowych w języku PHP, zapleczy mobilnych i aplikacji interfejsu API w usłudze Azure App Service. Omówiono najczęstsze zadania konfiguracyjne.

Jeśli dopiero zaczynasz korzystać z usługi App Service, najpierw postępuj zgodnie z samouczkiem Tworzenie aplikacji internetowej w języku PHP w usłudze Azure App Service oraz samouczkiem Wdrażanie aplikacji PHP, MySQL i Redis w usłudze Azure App Service .

Pokaż wersję języka PHP

Aby wyświetlić aktualną wersję PHP, uruchom następujące polecenie. Możesz użyć usługi Azure Cloud Shell:

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

Zastąp <resource-group-name> i <app-name> nazwami odpowiednimi dla swojej aplikacji internetowej.

Uwaga

Aby odnieść się do slotu programistycznego, dołącz parametr --slot, po którym następuje nazwa slotu.

Aby wyświetlić wszystkie obsługiwane wersje PHP, uruchom następujące polecenie:

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

W tym przewodniku przedstawiono sposób konfigurowania aplikacji internetowych w języku PHP, zapleczy mobilnych i aplikacji interfejsu API w usłudze Azure App Service. Omówiono najczęstsze zadania konfiguracyjne.

Jeśli dopiero zaczynasz korzystać z usługi App Service, najpierw postępuj zgodnie z samouczkiem Tworzenie aplikacji internetowej w języku PHP w usłudze Azure App Service oraz samouczkiem Wdrażanie aplikacji PHP, MySQL i Redis w usłudze Azure App Service .

Pokaż wersję języka PHP

Aby wyświetlić aktualną wersję PHP, uruchom następujące polecenie. Możesz użyć usługi Azure Cloud Shell.

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

Zastąp <resource-group-name> i <app-name> nazwami odpowiednimi dla swojej aplikacji internetowej.

Uwaga

Aby odnieść się do slotu programistycznego, dołącz parametr --slot, po którym następuje nazwa slotu.

Aby wyświetlić wszystkie obsługiwane wersje PHP, uruchom następujące polecenie:

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

Ustawianie wersji języka PHP

Aby ustawić wersję PHP na 8.1, uruchom następujące polecenie:

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

Aby ustawić wersję PHP na 8.1, uruchom następujące polecenie:

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

Co się stanie z nieaktualnymi środowiskami uruchomieniowymi w usłudze App Service?

Nieaktualne środowiska uruchomieniowe są przestarzałe przez utrzymanie organizacji lub mają znaczące luki w zabezpieczeniach. W związku z tym są one usuwane z tworzenia i konfigurowania stron w portalu. Gdy nieaktualne środowisko uruchomieniowe jest ukryte w portalu, każda aplikacja, która nadal korzysta z tego środowiska uruchomieniowego, będzie nadal działać.

Jeśli chcesz utworzyć aplikację z nieaktualną wersją środowiska uruchomieniowego, która nie jest już wyświetlana w portalu, użyj interfejsu wiersza polecenia platformy Azure, szablonu usługi ARM lub Bicep. Te alternatywy wdrażania umożliwiają tworzenie przestarzałych środowisk uruchomieniowych, które są usuwane z portalu, ale nadal są obsługiwane.

Jeśli środowisko uruchomieniowe zostanie w pełni usunięte z platformy App Service, właściciel subskrypcji platformy Azure otrzyma powiadomienie e-mail przed usunięciem.

Uruchamianie kompozytora

Jeśli chcesz, aby usługa App Service uruchamiała program Composer w czasie wdrażania, najprostszym sposobem jest dołączenie narzędzia Composer do repozytorium.

W lokalnym oknie terminalu zmień katalog na katalog główny repozytorium. Następnie postępuj zgodnie z instrukcjami w temacie Download Composer, aby pobrać composer.phar do katalogu głównego.

Uruchom następujące polecenia. Aby je uruchomić, musisz zainstalować narzędzie npm .

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

Katalog główny repozytorium ma teraz dwa nowe pliki: .deployment i deploy.sh.

Otwórz deploy.sh i znajdź sekcję Deployment , która wygląda następująco:

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

Na końcuDeployment sekcji dodaj sekcję kodu, którą musisz dodać, aby uruchomić wymagane narzędzie:

# 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

Zatwierdź wszystkie zmiany i wdróż kod przy użyciu narzędzia Git lub za pomocą narzędzia ZIP deploy z włączoną automatyzacją kompilacji. Kompozytor powinien teraz działać w ramach automatyzacji wdrażania.

Uruchom Bower, Gulp lub Grunt

Jeśli chcesz, aby usługa App Service uruchamiała popularne narzędzia automatyzacji w czasie wdrażania, takie jak Bower, Gulp lub Grunt, musisz podać niestandardowy skrypt wdrażania. Usługa App Service uruchamia ten skrypt podczas wdrażania przy użyciu narzędzia Git lub przy użyciu narzędzia ZIP deploy z włączoną automatyzacją kompilacji.

Aby umożliwić repozytorium uruchamianie tych narzędzi, należy dodać je do zależności w programie package.json. Na przykład:

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

W lokalnym oknie terminalu zmień katalog na katalog główny repozytorium i uruchom następujące polecenia. Aby je uruchomić, musisz zainstalować narzędzie npm .

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

Katalog główny repozytorium ma teraz dwa nowe pliki: .deployment i deploy.sh.

Otwórz deploy.sh i znajdź sekcję Deployment , która wygląda następująco:

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

Ta sekcja kończy się uruchomieniem polecenia npm install --production. Na końcuDeployment sekcji dodaj sekcję kodu, którą musisz dodać, aby uruchomić wymagane narzędzie:

Zobacz przykład w próbce MEAN.js, w którym skrypt wdrażania uruchamia również niestandardowe polecenie npm install.

Bower

Ten fragment kodu jest uruchamiany 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

Łyk

Ten fragment kodu jest uruchamiany 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

Ten fragment kodu jest uruchamiany grunt:

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

Dostosowywanie automatyzacji kompilacji

Jeśli wdrażasz aplikację przy użyciu usługi Git lub przy użyciu pakietów ZIP z włączoną automatyzacją kompilacji, automatyzacja kompilacji w usłudze App Service zostanie wykonana przez następującą sekwencję:

  1. Uruchom skrypt niestandardowy, jeśli PRE_BUILD_SCRIPT_PATH go określa.
  2. Uruchom program php composer.phar install.
  3. Uruchom skrypt niestandardowy, jeśli POST_BUILD_SCRIPT_PATH go określa.

PRE_BUILD_COMMAND i POST_BUILD_COMMAND są zmiennymi środowiskowymi, które są domyślnie puste. Aby uruchomić polecenia przed kompilacją, zdefiniuj polecenie PRE_BUILD_COMMAND. Aby uruchomić polecenia po kompilacji, zdefiniuj polecenie POST_BUILD_COMMAND.

Poniższy przykład określa dwie zmienne do serii poleceń rozdzielonych przecinkami:

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"

Aby uzyskać informacje o innych zmiennych środowiskowych w celu dostosowania automatyzacji kompilacji, zobacz Konfiguracja Oryx.

Aby dowiedzieć się, jak App Service uruchamia i kompiluje aplikacje PHP w systemie Linux, zapoznaj się z dokumentacją Oryx dotyczącą sposobu wykrywania i kompilowania aplikacji PHP.

Dostosowywanie uruchamiania

Polecenie niestandardowe można uruchomić w czasie uruchamiania kontenera. Uruchom następujące polecenie:

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

Uzyskiwanie dostępu do zmiennych środowiskowych

W usłudze App Service można ustawić ustawienia aplikacji poza kodem aplikacji. Następnie możesz uzyskać dostęp do tych ustawień przy użyciu standardowego getenv() wzorca. Aby na przykład uzyskać dostęp do ustawienia aplikacji o nazwie DB_HOST, użyj następującego kodu:

getenv("DB_HOST")

Zmień katalog główny witryny

Wybrana struktura sieci Web może używać podkatalogu jako katalogu głównego witryny. Na przykład usługa Laravel używa podkatalogu public/ jako katalogu głównego witryny.

Aby dostosować katalog główny witryny, skonfiguruj ścieżkę aplikacji wirtualnej dla aplikacji za pomocą polecenia az resource update. Poniższy przykład ustawia katalog główny witryny na podkatalog public/ w Twoim repozytorium:

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

Domyślnie usługa Azure App Service wskazuje główną ścieżkę aplikacji wirtualnej (/) do katalogu głównego wdrożonych plików aplikacji (sites\wwwroot).

Wybrana struktura sieci Web może używać podkatalogu jako katalogu głównego witryny. Na przykład usługa Laravel używa podkatalogu public/ jako katalogu głównego witryny.

Domyślny obraz PHP dla usługi App Service używa serwera NGINX, a ty zmieniasz główną lokalizację strony, konfigurując serwer NGINX za root pomocą dyrektywy. Ten przykładowy plik konfiguracji zawiera następujący fragment kodu, który zmienia dyrektywę 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
    }
    ...

Domyślny kontener używa pliku konfiguracji pod adresem /etc/nginx/sites-available/default. Każda edycja wprowadzana w tym pliku zostanie wymazana po ponownym uruchomieniu aplikacji. Aby wprowadzić zmianę, która będzie skuteczna przy ponownym uruchamianiu aplikacji, dodaj niestandardowe polecenie uruchamiania za pomocą takiego przykładu:

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

To polecenie zastępuje domyślny plik konfiguracji NGINX plikiem o nazwie default w katalogu głównym repozytorium i uruchamia ponownie serwer NGINX.

Wykrywanie sesji HTTPS

W usłudze App Service kończenie żądań PROTOKOŁU TLS/SSL odbywa się w modułach równoważenia obciążenia sieciowego, więc wszystkie żądania HTTPS docierają do aplikacji jako niezaszyfrowane żądania HTTP. Jeśli logika aplikacji musi sprawdzić, czy żądania użytkownika są szyfrowane, sprawdź X-Forwarded-Proto nagłówek:

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

Popularne platformy internetowe umożliwiają dostęp do informacji X-Forwarded-* w standardowym wzorcu aplikacji. W funkcji CodeIgniter funkcja is_https() sprawdza wartość domyślną X_FORWARDED_PROTO .

Dostosuj ustawienia php.ini

Jeśli musisz wprowadzić zmiany w instalacji języka PHP, możesz zmienić dowolne dyrektywyphp.ini , wykonując następujące kroki.

Uwaga

Najlepszym sposobem wyświetlenia wersji php i bieżącej php.ini konfiguracji jest wywołanie phpinfo() w aplikacji.

Dostosowywanie dyrektyw innych niż PHP_INI_SYSTEM

Aby dostosować dyrektywy PHP_INI_USER, PHP_INI_PERDIR, i PHP_INI_ALL, dodaj plik .user.ini do katalogu głównego aplikacji.

Dodaj ustawienia konfiguracji do .user.ini pliku przy użyciu tej samej składni, która będzie używana w php.ini pliku. Jeśli na przykład chciałbyś włączyć ustawienie display_errors i ustawić upload_max_filesize na 10M, plik .user.ini będzie miał następującą zawartość:

 ; Example Settings
 display_errors=On
 upload_max_filesize=10M

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

Ponownie wdróż aplikację przy użyciu zmian i uruchom ją ponownie.

Jako alternatywę dla używania pliku .user.ini, możesz użyć ini_set() w swojej aplikacji, aby dostosować te dyrektywy inne niż PHP_INI_SYSTEM.

Aby dostosować dyrektywy PHP_INI_USER, PHP_INI_PERDIR i PHP_INI_ALL dla aplikacji internetowych systemu Linux, takich jak upload_max_filesize i expose_php, użyj niestandardowego pliku .ini. Można go utworzyć w sesji SSH. Najpierw skonfiguruj katalog:

  1. Przejdź do witryny Kudu. Aby uzyskać losowe wartości skrótów i regionów, w obszarze Przegląd aplikacji skopiuj domenę domyślną.
  2. W górnym menu wybierz Konsola debugowania, następnie Bash lub SSH.
  3. W powłoce Bash lub SSH przejdź do katalogu /home/site/wwwroot.
  4. Utwórz katalog o nazwie ini (na przykład mkdir ini).
  5. Zmień bieżący katalog roboczy na folder ini, który utworzyłeś.

Następnie utwórz plik .ini , w którym dodasz ustawienia. W tym przykładzie użyto extensions.ini. Nie ma edytorów plików, takich jak Vi, Vim lub Nano, więc użyj Echo , aby dodać ustawienia do pliku. upload_max_filesize Zmień wartość z 2M na 50M. Użyj następującego polecenia, aby dodać ustawienie i utworzyć extensions.ini plik, jeśli jeszcze nie istnieje:

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

W portalu Azure dodaj ustawienie aplikacji, aby zeskanować właśnie utworzony katalog ini, aby zastosować zmianę dla upload_max_filesize.

  1. Przejdź do witryny Azure Portal i wybierz aplikację PHP usługi App Service dla systemu Linux.
  2. Przejdź do pozycji Ustawienia>Zmienne środowiskowe.
  3. Wybierz + Dodaj.
  4. W polu Nazwa wprowadź PHP_INI_SCAN_DIR i w polu Wartość wprowadź wartość :/home/site/wwwroot/ini.
  5. Wybierz pozycję Zastosuj, a następnie ponownie zastosuj . Potwierdź zmiany.

Pamiętaj, aby dołączyć dwukropek (:) podczas dodawania ścieżek niestandardowych do PHP_INI_SCAN_DIR. Pominięcie spowoduje zwrócenie błędu 404 przez serwer NGINX.

Uwaga

Jeśli ponownie skompilujesz rozszerzenie PHP, takie jak GD, wykonaj kroki opisane w temacie Ponowne komkompilowanie rozszerzeń PHP.

Dostosowywanie dyrektyw PHP_INI_SYSTEM

Aby dostosować PHP_INI_SYSTEM dyrektywy, użyj PHP_INI_SCAN_DIR ustawienia aplikacji.

Najpierw uruchom następujące polecenie, aby dodać ustawienie aplikacji o nazwie 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"

W Azure Portal wybierz swoją aplikację. W obszarze Narzędzia programistyczne w menu paska bocznego wybierz pozycję Narzędzia zaawansowane, a następnie przejdź do d:\home\site pozycji Korzystanie z protokołu SSH.

Utwórz katalog w d:\home\site o nazwie ini. Następnie utwórz plik .ini w katalogu d:\home\site\ini , na przykład settings.ini, z dyrektywami, które chcesz dostosować. Użyj tej samej składni, której należy użyć w php.ini pliku.

Aby na przykład zmienić wartość expose_php, uruchom następujące polecenia:

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

Aby zmiany zaczęły obowiązywać, uruchom ponownie aplikację.

Aby dostosować PHP_INI_SYSTEM dyrektywy, nie można użyć podejścia .htaccess . Usługa App Service udostępnia oddzielny mechanizm korzystający z PHP_INI_SCAN_DIR ustawienia aplikacji.

Najpierw uruchom następujące polecenie, aby dodać ustawienie aplikacji o nazwie 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"

Wartość /usr/local/etc/php/conf.d to katalog domyślny, w którym php.ini istnieje. Katalog /home/site/ini jest miejscem, w którym dodajesz niestandardowy plik .ini. Wartości należy oddzielić dwukropkiem (:).

Przejdź do internetowej sesji SSH z kontenerem systemu Linux.

Utwórz katalog w /home/site o nazwie ini. Następnie utwórz plik .ini w katalogu /home/site/ini , na przykład settings.ini, z dyrektywami, które chcesz dostosować. Użyj tej samej składni, której należy użyć w php.ini pliku.

Wskazówka

Wbudowane kontenery Linuksa w usłudze App Service używają /home jako trwałego magazynu współdzielonego.

Aby na przykład zmienić wartość expose_php, uruchom następujące polecenia:

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

Aby zmiany zaczęły obowiązywać, uruchom ponownie aplikację.

Włączanie rozszerzeń JĘZYKA PHP

Wbudowane instalacje języka PHP zawierają najczęściej używane rozszerzenia. Możesz włączyć więcej rozszerzeń w taki sam sposób, w jaki dostosowujesz dyrektywy php.ini.

Uwaga

Najlepszym sposobem wyświetlenia wersji php i bieżącej php.ini konfiguracji jest wywołanie phpinfo() w aplikacji.

Aby włączyć inne rozszerzenia, wykonaj następujące kroki:

  1. bin Dodaj katalog do katalogu głównego swojej aplikacji i umieść w nim pliki rozszerzeń .dll, na przykład mongodb.dll. Upewnij się, że rozszerzenia są zgodne z wersją PHP na platformie Azure oraz że są zgodne z VC9 i non-thread-safe (NTS).

  2. Wdróż zmiany.

  3. Wykonaj kroki opisane w temacie Dostosowywanie dyrektyw PHP_INI_SYSTEM i dodaj rozszerzenia do niestandardowego pliku .ini za pomocą dyrektywy extension lub zend_extension.

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

Aby zmiany zaczęły obowiązywać, uruchom ponownie aplikację.

Wbudowane instalacje języka PHP zawierają najczęściej używane rozszerzenia. Możesz włączyć więcej rozszerzeń w taki sam sposób, w jaki dostosowujesz dyrektywy php.ini.

Uwaga

Najlepszym sposobem wyświetlenia wersji php i bieżącej php.ini konfiguracji jest wywołanie phpinfo() w aplikacji.

Aby włączyć inne rozszerzenia, wykonaj następujące kroki:

  1. bin Dodaj katalog do katalogu głównego aplikacji i umieść w nim pliki rozszerzenia .so (na przykład mongodb.so). Upewnij się, że rozszerzenia są zgodne z wersją PHP na platformie Azure oraz że są zgodne z VC9 i non-thread-safe (NTS).

  2. Wdróż zmiany.

  3. Wykonaj kroki opisane w temacie Dostosowywanie dyrektyw PHP_INI_SYSTEM i dodaj rozszerzenia do niestandardowego pliku .ini za pomocą dyrektywy extension lub zend_extension.

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

Aby zmiany zaczęły obowiązywać, uruchom ponownie aplikację.

Uzyskiwanie dostępu do dzienników diagnostycznych

Użyj standardowego error_log() narzędzia, aby wyświetlić dzienniki diagnostyczne w usłudze Azure App Service.

Aby uzyskać dostęp do dzienników konsoli wygenerowanych z poziomu kodu aplikacji w usłudze App Service, włącz rejestrowanie diagnostyczne, uruchamiając następujące polecenie w usłudze Cloud Shell:

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

Możliwe wartości to --levelError, Warning, Infoi Verbose. Każdy kolejny poziom obejmuje poprzedni poziom. Na przykład Error zawiera tylko komunikaty o błędach. Verbose zawiera wszystkie komunikaty.

Po włączeniu rejestrowania diagnostycznego uruchom następujące polecenie, aby wyświetlić strumień dziennika:

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

Jeśli dzienniki konsoli nie są wyświetlane natychmiast, sprawdź ponownie w ciągu 30 sekund.

Aby zatrzymać strumieniowanie logów w dowolnym momencie, naciśnij Ctrl+C.

Dostęp do dzienników konsoli generowanych z poziomu kontenera można uzyskać.

Aby włączyć rejestrowanie kontenerów, uruchom następujące polecenie:

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

Zastąp wartości <app-name> i <resource-group-name> nazwami odpowiednimi dla swojej aplikacji internetowej.

Po włączeniu rejestrowania kontenerów uruchom następujące polecenie, aby wyświetlić strumień dziennika:

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

Jeśli dzienniki konsoli nie są wyświetlane natychmiast, sprawdź ponownie w ciągu 30 sekund.

Aby zatrzymać przesyłanie strumieniowe dzienników w dowolnym momencie, użyj skrótu klawiaturowego Ctrl+C.

Rozwiązywanie problemów

Jeśli działająca aplikacja PHP działa inaczej w usłudze App Service lub występują błędy, wypróbuj następujące rozwiązania:

  • Uzyskaj dostęp do strumienia dziennika diagnostycznego.
  • Przetestuj aplikację lokalnie w trybie produkcyjnym. Usługa App Service uruchamia aplikację w trybie produkcyjnym, więc musisz upewnić się, że projekt działa zgodnie z oczekiwaniami w trybie produkcyjnym lokalnie. Na przykład:
    • W zależności od pliku composer.json różne pakiety mogą być instalowane w trybie produkcyjnym (require przeciwko require-dev).
    • Niektóre struktury internetowe mogą wdrażać pliki statyczne inaczej w trybie produkcyjnym.
    • Niektóre frameworki internetowe mogą korzystać z niestandardowych skryptów startowych podczas pracy w trybie produkcyjnym.
  • Uruchom aplikację w usłudze App Service w trybie debugowania. Na przykład w usłudze Laravel możesz skonfigurować aplikację tak, aby wyprowadzała komunikaty debugowania w środowisku produkcyjnym, ustawiając APP_DEBUG ustawienie aplikacji na true.

Ignoruj komunikat robots933456 w logach

W dziennikach kontenera może zostać wyświetlony następujący komunikat:

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

Możesz bezpiecznie zignorować ten komunikat. /robots933456.txt to fikcyjna ścieżka adresu URL. Usługa App Service używa jej do sprawdzania, czy kontener może obsługiwać żądania. Odpowiedź błędu "404" wskazuje, że ścieżka nie istnieje i sygnalizuje usłudze App Service, że kontener jest w dobrej kondycji i gotowy do odpowiadania na żądania.