경고
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의 빌드 자동화는 다음 순서를 수행합니다.
-
PRE_BUILD_SCRIPT_PATH
에서 해당 스크립트를 지정한 경우, 실행합니다. -
php composer.phar install
를 실행합니다. -
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 구성을 참조하세요.
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")
사이트 루트 변경
선택한 웹 프레임워크는 하위 디렉터리를 사이트 루트로 사용할 수 있습니다. 예를 들어 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 App Service는 루트 가상 애플리케이션 경로(/
)를 배포된 애플리케이션 파일(sites\wwwroot
)의 루트 디렉터리를 가리킵니다.
선택한 웹 프레임워크는 하위 디렉터리를 사이트 루트로 사용할 수 있습니다. 예를 들어 Laravel 은 public/
하위 디렉터리를 사이트 루트로 사용합니다.
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_filesize
와 expose_php
와 같은 앱을 위해 맞춤 .ini 파일을 사용하십시오.
SSH 세션에서 만들 수 있습니다. 먼저 디렉터리를 설정합니다.
- Kudu 사이트로 이동합니다. 임의 해시 및 지역 값을 얻으려면 앱 개요에서 기본 도메인을 복사합니다.
- 위쪽 메뉴에서 디버그 콘솔, Bash 또는 SSH를 선택합니다.
- Bash 또는 SSH에서
/home/site/wwwroot
디렉터리로 이동하세요. - 디렉터리
ini
를 생성하세요 (예:mkdir ini
). - 현재 작업 디렉터리를 만든 폴더로
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
에 대한 변경 사항을 적용합니다.
- Azure Portal로 이동하여 App Service Linux PHP 애플리케이션을 선택합니다.
- 설정>환경 변수로 이동합니다.
- 을 선택하고을 추가합니다.
-
이름에 PHP_INI_SCAN_DIR을 입력하고, 값에는
:/home/site/wwwroot/ini
을 입력합니다. - 적용을 선택한 다음 다시 적용합니다. 변경 내용을 확인합니다.
비고
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\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 접근 방식을 사용할 수 없습니다. 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/site
에 ini
디렉터리를 만듭니다. 그런 다음, 사용자 지정하려는 지시문을 포함하여 .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()
하는 것입니다.
다른 확장을 사용하도록 설정하려면 다음 단계를 사용합니다.
bin
앱의 루트 디렉터리에 디렉터리를 추가하고 .dll 확장 파일(예:mongodb.dll
)을 넣습니다. 확장이 Azure의 PHP 버전과 호환되며 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
)을 넣습니다. 확장이 Azure의 PHP 버전과 호환되며 VC9 및 스레드에 안전하지 않은(NTS) 호환성을 갖추고 있는지 확인하세요.변경 내용을 배포합니다.
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
가능한 값 --level
은 Error
, Warning
, Info
및 Verbose
. 각 후속 수준에는 이전 수준이 포함됩니다. 예를 들어 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
파일에 따라 프로덕션 모드에서require
와require-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에 알릴 수 있습니다.