App Service는 문제 해결 및 관리 작업을 위해 실행 중인 앱 컨테이너에 인증된 접근 권한을 제공합니다. 컨테이너 접근을 특권 작업으로 간주하고, 필요한 사용자에게만 접근 권한을 부여하세요.
App Service는 Windows 커스텀 컨테이너에 호스팅된 앱에 브라우저 기반 SSH 접근을 제공합니다. 브라우저 세션에는 특별한 이미지 설정이 필요하지 않습니다.
Azure CLI az webapp exec 명령어는 리눅스 웹 앱에서만 지원됩니다. 이 글의 리눅스 CLI 예제를 Windows 앱 서비스 요금제에 사용하지 마세요.
기본 제공 Linux 컨테이너 및 사용자 지정 Linux 컨테이너의 경우, 최신 브라우저 터미널과 az webapp exec는 Kudu를 인증된 프록시로 사용하여 실행 중인 컨테이너에 연결하는 데 사용됩니다. 이 옵션들은 SSH 서버를 설치하거나, SSH 비밀번호를 삽입하거나, SSH 포트를 노출하거나, 사용자 지정 이미지에서 SSH 데몬을 시작할 필요가 없습니다. 레거시 Kudu WebSSH 및 az webapp ssh 액세스는 여전히 맞춤형 이미지에서 SSH 서버가 필요할 수 있습니다.
브라우저 세션에는 Azure 포털을 사용하거나, 로컬 터미널 세션이나 분리된 명령 실행에는 preview az webapp exec 명령어를 사용하세요. 브라우저 터미널은 이미지에 /bin/bash가 있어야 하며 현재 다른 셸 선택을 지원하지 않습니다. 이미지에 다른 쉘이 있다면 az webapp exec --shell /bin/sh를 대신 사용하세요. 셸이 없는 이미지(디스트로리스 이미지 포함)에서는 인터랙티브 세션을 열 수 없습니다.
Prerequisites
- 앱과 그 컨테이너는 실행 중입니다.
- 앱의 SCM/Kudu 사이트에 접근할 권한이 있습니다. 권한에 대해서는 Kudu에 접근하기 위해 필요한 RBAC 권한을 참조하세요.
- 클라이언트는 SCM 엔드포인트에 네트워크 접근 권한을 가지고 있습니다. 접속이 안 되면 앱의 접근 제한 과 프라이빗 네트워킹 설정을 확인하세요.
- CLI 예제의 경우, Azure CLI 2.90.0 이상을 설치하고 로그인하세요.
az version을 사용하여 버전을 확인합니다. CLI가 이 조건을 충족한다면 Azure Cloud Shell도 사용할 수 있습니다. - CLI 인터랙티브 세션의 경우, 인터랙티브 터미널과 이미지에 있는 셸을 사용하세요. 기본값은
/bin/bash입니다. 배시가 없는 이미지의 경우, 해당 셸을 사용할 수 있는 경우--shell /bin/sh를 지정합니다.
브라우저에서 SSH 세션 열기
브라우저 세션을 열기 전에 앱과 그 컨테이너가 실행되어야 합니다.
Azure 포털에서 App Service 앱을 엽니다. 개발 도구 아래에서 SSH를 선택한 후 Go를 선택하세요. 요청이 나오면 Azure 계정으로 로그인하세요.
세션은 브라우저에서 열리며, 앱 컨테이너 내에서 명령을 실행할 수 있습니다.
Azure CLI를 사용하여 SSH 세션 열기
미리보기 az webapp exec 명령어는 앱의 메인 컨테이너에서 인터랙티브 셸을 엽니다. 이 세션은 Windows, macOS, Linux에서 로컬 터미널을 사용하며, 브라우저를 열지 않습니다.
az webapp exec --resource-group <resource-group-name> --name <app-name>
bash 대신 /bin/sh를 사용하는 이미지의 경우:
az webapp exec --resource-group <resource-group-name> --name <app-name> --shell /bin/sh
이 세션에서 명령어를 실행하고 그 결과물을 검사할 수 있습니다. 예를 들어, 이미지에 설치되어 있다면 top를 사용하세요. 앱 컨테이너 대신 SCM/Kudu 컨테이너를 검사하려면:
az webapp exec --resource-group <resource-group-name> --name <app-name> --target kudu
앱과 Kudu 컨테이너는 서로 다른 환경입니다. 앱 컨테이너 내에서 애플리케이션의 런타임, 의존성 또는 네트워크 연결성에 의존하는 명령어를 실행하세요.
인스턴스 또는 배포 슬롯을 선택하세요
기본적으로 CLI는 하나의 앱 인스턴스에 연결됩니다. 인스턴스 ID를 찾으려면:
az webapp list-instances --resource-group <resource-group-name> --name <app-name> --output table
특정 인스턴스에 연결하자면:
az webapp exec --resource-group <resource-group-name> --name <app-name> --instance <instance-id>
--slot <slot-name>를 추가하여 배치 슬롯에 접근하세요. 슬롯 인스턴스를 선택할 때는 --slot도 az webapp list-instances에 추가합니다.
인터랙티브 셸 모드는 한 번에 하나의 인스턴스만 지원합니다.
상호작용 세션 없이 명령어 실행
--mode execute를 사용하여 터미널 세션을 열지 않고 메인 앱 컨테이너에 명령을 제출하세요. 명령은 분리된 상태로 실행됩니다. 이 모드는 백그라운드 진단이나 즉각적인 출력이 필요 없는 기타 작업에 유용합니다.
Important
실행 모드는 fire-and-forget입니다. 상태가 accepted인 결과는 요청이 수락되었음을 확인할 뿐, 명령이 실행되었거나 완료되었는지, 또는 성공했는지는 확인하지 못합니다. CLI는 원격 명령어의 표준 출력, 표준 오류, 또는 종료 코드를 반환하지 않습니다. 제출에 실패하면 CLI 오류가 발생하지만, 성공적인 CLI 호출이 원격 실행의 성공을 증명하는 것은 아닙니다. 결과를 즉시 관찰해야 할 때는 인터랙티브 셸을 사용하세요.
프로그램을 직접 실행하세요
프로그램과 그 인자를 지정하는 데 사용됩니다 --command . 명령어 전체를 인용하세요:
az webapp exec --resource-group <resource-group-name> --name <app-name> --mode execute --command "python3 /home/site/wwwroot/scripts/diagnostics.py" --working-directory /home/site/wwwroot --instance <instance-id>
스크립트 경로를 앱에 배포한 스크립트로 교체하세요. 실행 파일과 그 의존성은 컨테이너 내에 존재해야 합니다.
--command는 &&, > 또는 |와 같은 셸 연산자를 해석하지 않는다. 셸이 필요할 때는 대신 --shell-command를 사용하세요. 이 두 가지 선택지는 상호 배타적입니다.
출력을 캡처하고 완료 여부를 확인
다음 예시는 Cloud Shell과 같은 Bash 클라이언트의 따옴표 처리 방식을 사용합니다. 한 인스턴스에 읽기 전용 진단 명령을 제출하고, 출력과 종료 상태를 별도로 기록합니다.
<run-id>를 각 호출마다 새로운 식별자로 바꾸고 <instance-id>를 az webapp list-instances의 ID로 바꾸세요.
az webapp exec --resource-group <resource-group-name> --name <app-name> \
--mode execute --instance <instance-id> --shell /bin/sh \
--shell-command 'uname -a > /home/LogFiles/diagnostics-<run-id>.log 2>&1; result=$?; printf "%s\n" "$result" > /home/LogFiles/diagnostics-<run-id>.exit'
/bin/sh 및 진단 명령어가 존재하고 /home/LogFiles이(가) 존재하며 쓰기 가능한지 확인하십시오. 커스텀 컨테이너에서의 지속성은 /home 앱의 저장 구성에 따라 달라집니다. 작은따옴표는 요청이 컨테이너에 도달하기 전에 클라이언트 셸이 $? 및 $result을 확장하는 것을 막아줍니다.
제출 후 같은 인스턴스에서 인터랙티브 앱 셸 을 열고 파일을 검사하세요:
cat /home/LogFiles/diagnostics-<run-id>.log
cat /home/LogFiles/diagnostics-<run-id>.exit
기록된 종료 상태 0 는 진단 명령이 성공했음을 나타냅니다. 0이 아닌 상태는 실패를 의미합니다; 로그를 검사합니다. 상태 파일이 존재하지 않는다면, 완료가 확립되지 않은 것입니다: 명령어가 아직 실행 중일 수도 있고, 시작되지 않았을 수도 있고, 중단되었을 수도 있습니다. 수락이나 부분 로그의 존재만으로 성공을 추론하지 마세요. 이전 상태 파일이 현재 결과와 혼동되지 않도록 새 실행 식별자를 사용하세요.
CLI는 완료 상태를 폴링하는 API를 제공하지 않습니다. 출력을 파일로 리디렉션한다고 해서 자동으로 App Service 로그 스트리밍에서 사용할 수 있게 되는 것은 아닙니다.
데이터베이스 마이그레이션이나 공유 상태를 변경하는 다른 작업의 경우, 인스턴스 하나를 선택하고 완료 여부를 별도로 확인하며, 제출이 출력을 반환하지 않는다고 해서 작업을 다시 실행하지 마세요. 성공을 확인해야 할 때는 인터랙티브 워크플로우를 유지하세요.
여러 인스턴스에서 독립적인 명령어를 실행하세요
실행 모드는 쉼표로 구분된 인스턴스 ID 목록 또는 --instance all도 허용합니다. 여러 인스턴스에 대한 요청은 병렬로 제출됩니다. 예를 들어, 모든 인스턴스에 배포된 인스턴스별 진단 스크립트를 실행하세요:
az webapp exec --resource-group <resource-group-name> --name <app-name> --mode execute --command "python3 /home/site/wwwroot/scripts/diagnostics.py" --instance all
스크립트는 자체 결과를 수집해야 합니다. 스토리지가 공유된다면 인스턴스별 및 실행당 출력 경로를 별도로 사용하세요. 공유 데이터베이스 마이그레이션이나 한 번만 실행해야 하는 다른 작업에는 사용하지 all 마세요. 일부 제출이 실패하면, 다른 인스턴스가 명령을 수락했음에도 불구하고 CLI가 오류를 보고합니다.
--slot <slot-name>을 추가하여 배포 슬롯에 대해 실행하세요.
Limitations
- 실행 모드는 메인 앱 컨테이너만 대상으로 합니다.
--target kudu는 인터랙티브 셸 모드에서만 사용할 수 있습니다. -
--working-directory또는--cwd는 실행 모드에서만 사용하고 절대 경로를 제공하세요. -
--shell에 대한 절대 경로를 제공한다. 실행 모드에서는--shell-command에서만 사용할 수 있습니다. - 이 미리보기에는 파일 전송, 포트 포워딩, 또는 임의의 사이드카 컨테이너 선택 옵션이 제공되지 않습니다. 지원되는 배포 방식을 사용해 파일을 업로드하세요.
- 분리된 실행은 영속적인 작업 스케줄러가 아닙니다. 컨테이너 재시작이나 교체는 작업을 중단시킬 수 있습니다. 자동 재시도나 정확히 한 번만 실행된다고 가정하지 마세요.
SSH 접근 제어
SSH 접근이 필요 없는 앱의 false 설정 속성을 sshEnabled로 설정하여 SSH 접근을 비활성화하세요. 다음 예시들은 Bash JSON 인용을 사용합니다:
az webapp config set --resource-group <resource-group-name> --name <app-name> \
--generic-configurations '{"sshEnabled": false}'
SSH 액세스를 다시 활성화하려면:
az webapp config set --resource-group <resource-group-name> --name <app-name> \
--generic-configurations '{"sshEnabled": true}'
구성 검사:
az webapp config show --resource-group <resource-group-name> --name <app-name> --query sshEnabled
--slot <slot-name>을 추가하여 배포 슬롯을 구성하거나 검사하세요.
앱과 슬롯 간 거버넌스를 위해서는 App Service apps should disable SSH 및 App Service app slots should disable SSH 기본 제공 정책을 사용하세요. 앱 서비스 정책 참조에서 할당 링크를 확인하세요.
두 정책 모두 Audit가 기본값이며, 또한 Deny 및 Disabled도 지원합니다. 그들은 없거나 sshEnabled 값이 거짓이 아닌 경우를 비준수로 평가합니다. 감사 기능은 비준수 사항을 보고합니다; SSH는 비활성화하지 않습니다. Deny는 규정을 준수하지 않는 리소스 변경을 방지합니다. 기존 앱을 자동으로 재구성하지는 않습니다. 구독 또는 관리 그룹 범위에서 정책을 할당할 수 있으며, 테넌트 전체 거버넌스를 위한 테넌트 루트 관리 그룹도 포함됩니다.
SSH 설정과 정책 준수는 SCM/Kudu 액세스 보안을 대체할 수 없습니다. 적절한 RBAC 권한 과 네트워크 접근 제한을 사용하세요.
컨테이너 접근 문제 해결
- 앱이 성공적으로 시작되는지 확인하세요. 시작 실패에 대해 진단 로그를 검토하세요.
- CLI 접근을 위해서는 CLI 버전, 선택한 앱, 슬롯, 인스턴스, 그리고 요청된 실행 파일 또는 셸이 존재하는지 확인하세요.
- SCM 엔드포인트에 대한 권한 및 네트워크 연결성을 확인하세요. 기본 퍼블리싱 인증을 활성화할 필요는 없습니다; CLI는 SCM 기본 인증이 비활성화된 상태에서 Microsoft Entra 인증을 지원합니다. 기본 인증 비활성화를 참조하세요.
- 컨테이너 내에서 변경하는 것이 앱이나 이미지를 업데이트하거나 재배포하는 것을 대체하지 않습니다. 컨테이너 재시작은 영속 저장소 외부의 파일을 제거할 수 있습니다.