다음을 통해 공유


Azure App Service에서 PHP 앱 구성

경고

Windows의 PHP는 2022년 11월에 지원이 종료 되었습니다. PHP는 Linux의 App Service에 대해서만 지원됩니다. 이 문서는 참조 전용입니다.

이 가이드에서는 Azure App Service에서 PHP 웹앱, 모바일 백 엔드 및 API 앱을 구성하는 방법을 보여 줍니다. 가장 일반적인 구성 작업을 다룹니다.

App Service를 처음 사용하는 경우 먼저 Azure App Service에서 PHP 웹앱 만들기 빠른 시작과 Azure App Service에PHP, MySQL 및 Redis 앱 배포 자습서를 따라야 합니다.

PHP 버전 표시

현재 PHP 버전을 표시하려면 다음 명령을 실행합니다. Azure Cloud Shell을 사용할 수 있습니다.

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

<resource-group-name><app-name>을 웹앱에 적절한 이름으로 바꿉니다.

비고

개발 슬롯의 주소를 지정하려면 매개 변수 --slot 뒤에 슬롯의 이름을 포함합니다.

지원되는 모든 PHP 버전을 표시하려면 다음 명령을 실행합니다.

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

이 가이드에서는 Azure App Service에서 PHP 웹앱, 모바일 백 엔드 및 API 앱을 구성하는 방법을 보여 줍니다. 가장 일반적인 구성 작업을 다룹니다.

App Service를 처음 사용하는 경우 먼저 Azure App Service에서 PHP 웹앱 만들기 빠른 시작과 Azure App Service에PHP, MySQL 및 Redis 앱 배포 자습서를 따라야 합니다.

PHP 버전 표시

현재 PHP 버전을 표시하려면 다음 명령을 실행합니다. Azure Cloud Shell을 사용할 수 있습니다.

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

<resource-group-name><app-name>을 웹앱에 적절한 이름으로 바꿉니다.

비고

개발 슬롯의 주소를 지정하려면 매개 변수 --slot 뒤에 슬롯의 이름을 포함합니다.

지원되는 모든 PHP 버전을 표시하려면 다음 명령을 실행합니다.

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

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"

App Service에서 오래된 런타임은 어떻게 되나요?

오래된 런타임은 유지 관리 조직에서 더 이상 사용되지 않거나 심각한 취약성이 있는 것으로 확인됩니다. 따라서 포털의 만들기 및 구성 페이지에서 제거됩니다. 오래된 런타임이 포털에서 숨겨지면 해당 런타임을 계속 사용하는 모든 앱이 계속 실행됩니다.

더 이상 포털에 표시되지 않는 오래된 런타임 버전으로 앱을 만들려면 Azure CLI, ARM 템플릿 또는 Bicep을 사용합니다. 이러한 배포 대안을 사용하면 포털에서 제거되었지만 여전히 지원되는 사용되지 않는 런타임을 만들 수 있습니다.

런타임이 App Service 플랫폼에서 완전히 제거된 경우 Azure 구독 소유자는 제거 전에 이메일 알림을 받습니다.

작성기 실행

App Service가 배포 시 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 실행

App Service가 배포 시 Bower, Gulp 또는 Grunt와 같은 인기 있는 자동화 도구를 실행하려면 사용자 지정 배포 스크립트를 제공해야 합니다. App Service는 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 끝에 필요한 도구를 실행하는 데 필요한 코드 섹션을 추가합니다.

배포 스크립트가 사용자 지정 명령도 실행하는 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 패키지를 사용하여 앱을 배포하는 경우 App Service의 빌드 자동화는 다음 순서를 수행합니다.

  1. PRE_BUILD_SCRIPT_PATH에서 해당 스크립트를 지정한 경우, 실행합니다.
  2. php composer.phar install를 실행합니다.
  3. POST_BUILD_SCRIPT_PATH에서 해당 스크립트를 지정한 경우, 실행합니다.

PRE_BUILD_COMMANDPOST_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 구성을 참조하세요.

Linux에서 App Service가 PHP 앱을 실행하고 빌드하는 방법을 알아보려면 PHP 앱을 검색하고 빌드하는 방법에 대한 Oryx 설명서를 참조하세요.

시작 사용자 지정

컨테이너 시작 시 사용자 지정 명령을 실행할 수 있습니다. 다음 명령을 실행합니다.

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

환경 변수에 액세스

App Service에서 앱 코드 외부에서 앱 설정을 설정할 수 있습니다. 그런 다음 표준 getenv() 패턴을 사용하여 해당 설정에 액세스할 수 있습니다. 예를 들어 호출 DB_HOST된 앱 설정에 액세스하려면 다음 코드를 사용합니다.

getenv("DB_HOST")

사이트 루트 변경

선택한 웹 프레임워크는 하위 디렉터리를 사이트 루트로 사용할 수 있습니다. 예를 들어 Laravelpublic/ 하위 디렉터리를 사이트 루트로 사용합니다.

사이트 루트를 사용자 지정하려면 명령을 사용하여 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 App Service는 루트 가상 애플리케이션 경로(/)를 배포된 애플리케이션 파일(sites\wwwroot)의 루트 디렉터리를 가리킵니다.

선택한 웹 프레임워크는 하위 디렉터리를 사이트 루트로 사용할 수 있습니다. 예를 들어 Laravelpublic/ 하위 디렉터리를 사이트 루트로 사용합니다.

App Service의 기본 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를 다시 시작합니다.

HTTPS 세션 검색

App Service에서 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을 사용자 지정하려면 앱의 루트 디렉터리에 .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() 비지시문을 다양하게 사용자 지정할 수 있습니다.

Linux 웹 앱용 PHP_INI_USER, PHP_INI_PERDIR, 및 PHP_INI_ALL 지시문을 사용자 지정하고 upload_max_filesizeexpose_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 Portal로 이동하여 App Service Linux PHP 애플리케이션을 선택합니다.
  2. 설정>환경 변수로 이동합니다.
  3. 을 선택하고을 추가합니다.
  4. 이름PHP_INI_SCAN_DIR을 입력하고, 에는 :/home/site/wwwroot/ini을 입력합니다.
  5. 적용을 선택한 다음 다시 적용합니다. 변경 내용을 확인합니다.

비고

GD와 같은 PHP 확장을 다시 컴파일한 경우 PHP 확장 다시 컴파일의 단계를 따릅니다.

PHP_INI_SYSTEM 지시문 사용자 지정

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 Portal에서 앱을 선택합니다. 사이드바 메뉴의 Development Tools(개발 도구 )에서 Advanced Tools(고급 도구)를 선택한 다음, SSH 사용으로 이동합니다 d:\home\site .

d:\home\siteini 디렉터리를 만듭니다. 그런 다음, 사용자 지정하려는 지시문을 포함하여 .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 접근 방식을 사용할 수 없습니다. App Service는 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 파일을 추가하는 사용자 지정 디렉터리입니다. 값을 콜론(:)으로 구분합니다.

Linux 컨테이너가 있는 웹 SSH 세션으로 이동합니다.

/home/siteini 디렉터리를 만듭니다. 그런 다음, 사용자 지정하려는 지시문을 포함하여 .ini 파일을 /home/site/ini 디렉터리에 생성합니다. 예를 들어, settings.ini 디렉터리에 파일을 만들 수 있습니다. 파일에서 사용하는 것과 동일한 구문을 사용합니다 php.ini .

팁 (조언)

App Service의 기본 제공 Linux 컨테이너는 지속형 공유 스토리지로 사용됩니다 /home .

예를 들어 값을 expose_php변경하려면 다음 명령을 실행합니다.

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

변경 내용을 적용하려면 앱을 다시 시작합니다.

PHP 확장 기능 활성화

기본 제공 PHP 설치에는 가장 일반적으로 사용되는 확장이 포함되어 있습니다. php.ini 지시문을 사용자 지정하는 것과 동일한 방식으로 더 많은 확장을 사용하도록 설정할 수 있습니다.

비고

PHP 버전 및 현재 php.ini 구성을 확인하는 가장 좋은 방법은 앱에서 호출 phpinfo() 하는 것입니다.

다른 확장을 사용하도록 설정하려면 다음 단계를 사용합니다.

  1. bin 앱의 루트 디렉터리에 디렉터리를 추가하고 .dll 확장 파일(예: mongodb.dll)을 넣습니다. 확장이 Azure의 PHP 버전과 호환되며 VC9 및 스레드에 안전하지 않은(NTS) 호환성을 갖추고 있는지 확인하세요.

  2. 변경 내용을 배포합니다.

  3. 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() 하는 것입니다.

다른 확장을 사용하도록 설정하려면 다음 단계를 사용합니다.

  1. bin 앱의 루트 디렉터리에 디렉터리를 추가하고 .so 확장 파일(예: mongodb.so)을 넣습니다. 확장이 Azure의 PHP 버전과 호환되며 VC9 및 스레드에 안전하지 않은(NTS) 호환성을 갖추고 있는지 확인하세요.

  2. 변경 내용을 배포합니다.

  3. PHP_INI_SYSTEM 지시문 사용자 지정의 단계에 따라 .ini 사용자 정의 파일에 확장 기능을 추가하고, extension 또는 zend_extension 지시문을 사용하세요.

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

변경 내용을 적용하려면 앱을 다시 시작합니다.

진단 로그에 접근하기

표준 error_log() 도구를 사용하여 진단 로그가 Azure App Service에 표시되도록 합니다.

App Service의 애플리케이션 코드 내에서 생성된 콘솔 로그에 액세스하려면 Cloud Shell에서 다음 명령을 실행하여 진단 로깅을 설정합니다.

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

가능한 값 --levelError, Warning, InfoVerbose. 각 후속 수준에는 이전 수준이 포함됩니다. 예를 들어 Error 오류 메시지만 포함합니다. Verbose 에는 모든 메시지가 포함됩니다.

진단 로깅을 켠 후 다음 명령을 실행하여 로그 스트림을 확인합니다.

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

콘솔 로그가 즉시 나타나지 않으면 30초 후에 다시 확인합니다.

언제든지 로그 스트리밍을 중지하려면 Ctrl+를 선택합니다.

컨테이너 내부에서 생성된 콘솔 로그에 액세스할 수 있습니다.

컨테이너 로깅을 켜려면 다음 명령을 실행합니다.

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+를 선택합니다.

문제 해결

App Service에서 작동하는 PHP 앱이 다르게 동작하거나 오류가 있는 경우 다음 솔루션을 시도해 보세요.

  • 진단 로그 스트림에 액세스합니다.
  • 프로덕션 모드에서 로컬로 앱을 테스트합니다. App Service는 프로덕션 모드에서 앱을 실행하므로 프로젝트가 프로덕션 모드에서 예상대로 로컬로 작동하는지 확인해야 합니다. 예를 들어:
    • composer.json 파일에 따라 프로덕션 모드에서 requirerequire-dev의 경우 다른 패키지가 설치될 수 있습니다.
    • 특정 웹 프레임워크는 프로덕션 모드에서 정적 파일을 다르게 배포할 수 있습니다.
    • 특정 웹 프레임워크는 프로덕션 모드에서 실행할 때 사용자 지정 시작 스크립트를 사용할 수 있습니다.
  • 디버그 모드에서 App Service에서 앱을 실행합니다. 예를 들어 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는 App Service에서 컨테이너가 요청을 처리할 수 있는지 확인하기 위해 사용하는 더미 URL 경로입니다. 404 응답은 경로가 존재하지 않음을 나타내며, 컨테이너가 정상이며 요청에 응답할 준비가 되었음을 App Service에 알릴 수 있습니다.