Azure App Service에 대한 사용자 지정 컨테이너 구성
이 문서에서는 Azure App Service에서 실행되도록 사용자 지정 컨테이너를 구성하는 방법을 보여 줍니다.
이 가이드에서는 App Service의 Windows 앱 컨테이너화에 대한 주요 개념 및 지침을 제공합니다. 새 Azure App Service 사용자는 먼저 사용자 지정 컨테이너 빠른 시작 및 자습서를 먼저 따라야 합니다.
이 가이드에서는 App Service의 Linux 앱 컨테이너화에 대한 주요 개념 및 지침을 제공합니다. Azure App Service를 처음 사용하는 경우 먼저 사용자 지정 컨테이너 빠른 시작 및 자습서를 따릅니다. 다중 컨테이너 앱 빠른 시작 및 자습서도 있습니다. 사이드카 컨테이너(미리 보기)의 경우 자습서: Azure App Service(미리 보기) 사용자 지정 컨테이너에 대한 사이드카 컨테이너 구성을 참조하세요.
참고 항목
Windows 컨테이너 이미지 끌어오기 인증에는 서비스 주체가 더 이상 지원되지 않습니다. 권장되는 방법은 Windows 및 Linux 컨테이너 모두에 관리 ID를 사용하는 것입니다
지원되는 부모 이미지
사용자 지정 Windows 이미지의 경우 원하는 프레임워크에 적합한 부모 이미지(기본 이미지)를 선택해야 합니다.
- .NET Framework 앱을 배포하려면 Windows Server 2019 Core LTSC(장기 서비스 채널) 릴리스를 기반으로 하는 부모 이미지를 사용합니다.
- .NET Core 앱을 배포하려면 Windows Server 2019 Nano SAC(반기 서비스 채널) 릴리스를 기반으로 하는 부모 이미지를 사용합니다.
앱을 시작하는 동안 부모 이미지를 다운로드하는 데 다소 시간이 걸립니다. 그러나 Azure App Service에서 이미 캐시된 다음 부모 이미지 중 하나를 사용하여 시작 시간을 줄일 수 있습니다.
- mcr.microsoft.com/windows/servercore:ltsc2022
- mcr.microsoft.com/windows/servercore:ltsc2019
- mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2022
- mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2019
- mcr.microsoft.com/dotnet/runtime:6.0-nanoserver-ltsc2022
- mcr.microsoft.com/dotnet/runtime:6.0-nanoserver-1809
- mcr.microsoft.com/dotnet/aspnet:6.0-nanoserver-ltsc2022
- mcr.microsoft.com/dotnet/aspnet:6.0-nanoserver-1809
사용자 지정 컨테이너의 Docker 이미지 변경
기존 사용자 지정 컨테이너를 현재 Docker 이미지에서 새 이미지로 변경하려면 다음 명령을 사용합니다.
az webapp config container set --name <app-name> --resource-group <group-name> --docker-custom-image-name <docker-hub-repo>/<image>
프라이빗 레지스트리의 이미지 사용
Azure Container Registry와 같은 프라이빗 레지스트리의 이미지를 사용하려면 다음 명령을 실행합니다.
az webapp config container set --name <app-name> --resource-group <group-name> --docker-custom-image-name <image-name> --docker-registry-server-url <private-repo-url> --docker-registry-server-user <username> --docker-registry-server-password <password>
<사용자 이름> 및 <암호>의 경우 프라이빗 레지스트리 계정에 대한 로그인 자격 증명을 입력합니다.
관리 ID를 사용하여 Azure Container Registry에서 이미지 끌어오기
다음 단계를 사용하여 관리 ID를 사용하여 ACR(Azure Container Registry)에서 끌어오도록 웹앱을 구성합니다. 이 단계에서는 시스템이 할당한 관리 ID를 사용하지만 사용자가 할당한 관리 ID도 사용할 수 있습니다.
az webapp identity assign명령을 사용하여 시스템이 할당한 관리 ID를 웹앱에 사용하도록 설정합니다.az webapp identity assign --resource-group <group-name> --name <app-name> --query principalId --output tsv<app-name>을 이전 단계에서 사용한 이름으로 바꿉니다. 명령의 출력(--query및--output인수로 필터링됨)은 할당된 ID의 서비스 주체 ID입니다.Azure Container Registry의 리소스 ID를 가져옵니다.
az acr show --resource-group <group-name> --name <registry-name> --query id --output tsv<registry-name>을 레지스트리 이름으로 바꿉니다. 명령의 출력(--query및--output인수로 필터링됨)은 Azure Container Registry의 리소스 ID입니다.컨테이너 레지스트리에 액세스할 수 있는 권한을 관리 ID에 부여합니다.
az role assignment create --assignee <principal-id> --scope <registry-resource-id> --role "AcrPull"다음 값을 바꿉니다.
<principal-id>값을az webapp identity assign명령의 서비스 주체 ID로 바꿉니다.<registry-resource-id>값을az acr show명령의 컨테이너 레지스트리 ID로 바꿉니다
이러한 권한에 대한 자세한 내용은 Azure 역할 기반 액세스 제어란?을 참조하세요.
Azure Container Registry에서 가져올 관리 ID를 사용하도록 앱을 구성합니다.
az webapp config set --resource-group <group-name> --name <app-name> --generic-configurations '{"acrUseManagedIdentityCreds": true}'다음 값을 바꿉니다.
<app-name>을 웹앱 이름으로 바꿉니다.
팁
PowerShell 콘솔을 사용하여 명령을 실행하는 경우 이 단계와 다음 단계의
--generic-configurations인수에서 문자열을 이스케이프해야 합니다. 예:--generic-configurations '{\"acrUseManagedIdentityCreds\": true'(선택 사항) 앱에서 사용자가 할당한 관리 ID를 사용하는 경우 ID가 웹앱에서 구성되었는지 확인한 다음
acrUserManagedIdentityID속성을 설정하여 클라이언트 ID를 지정합니다.az identity show --resource-group <group-name> --name <identity-name> --query clientId --output tsv사용자가 할당한 관리 ID의
<identity-name>을(를) 바꾸고 출력<client-id>을(를) 사용하여 사용자가 할당한 관리 ID를 구성합니다.az webapp config set --resource-group <group-name> --name <app-name> --generic-configurations '{"acrUserManagedIdentityID": "<client-id>"}'
모두 설정되었으며, 이제 웹앱은 Azure Container Registry에서 가져올 관리 ID를 사용합니다.
네트워크 보호된 레지스트리의 이미지 사용
가상 네트워크 또는 온-프레미스 내의 레지스트리에서 연결하고 끌어오려면 앱이 VNET(가상 네트워크)과 통합되어야 합니다. 프라이빗 엔드포인트가 있는 Azure Container Registry에도 VNET 통합이 필요합니다. 네트워크 및 DNS 확인이 구성된 경우 vnetImagePullEnabled 사이트 설정을 구성하여 가상 네트워크를 통해 이미지 끌어오기 라우팅을 사용하도록 설정합니다.
az resource update --resource-group <group-name> --name <app-name> --resource-type "Microsoft.Web/sites" --set properties.vnetImagePullEnabled [true|false]
업데이트된 컨테이너가 표시되지 않음
새 컨테이너를 가리키도록 Docker 컨테이너 설정을 변경하는 경우 앱에서 새 컨테이너의 HTTP 요청을 처리하는 데 몇 분 정도 걸릴 수 있습니다. 새 컨테이너를 끌어오고 시작하는 동안 App Service는 이전 컨테이너의 요청을 계속 처리합니다. 새 컨테이너가 시작되고 요청을 받을 준비가 된 경우에만 App Service에서 요청을 해당 컨테이너에 보내기 시작합니다.
컨테이너 이미지를 저장하는 방법
App Service에서 사용자 지정 Docker 이미지를 처음 실행하는 경우 App Service는 docker pull을 수행하고 모든 이미지 레이어를 끌어옵니다. 이러한 레이어는 온-프레미스에서 Docker를 사용하는 경우와 같이 디스크에 저장됩니다. 앱이 다시 시작될 때마다 App Service는 docker pull을 수행하지만 변경된 레이어만 끌어옵니다. 변경 내용이 없는 경우 App Service는 로컬 디스크의 기존 레이어를 사용합니다.
가격 책정 계층의 크기를 확장/축소하는 등의 이유로 앱에서 컴퓨팅 인스턴스를 변경하는 경우 App Service는 모든 레이어를 다시 끌어와야 합니다. 인스턴스를 더 추가하기 위해 스케일 아웃하는 경우에도 마찬가지입니다. 크기 조정 작업 없이 앱 인스턴스가 변경될 수 있는 드문 경우도 있습니다.
포트 번호 구성
기본적으로 App Service는 사용자 지정 컨테이너가 80 포트에서 수신 대기한다고 가정합니다. 컨테이너가 다른 포트를 수신 대기하는 경우 App Service 앱에서 WEBSITES_PORT 설정을 지정합니다. 이는 Cloud Shell을 통해 설정할 수 있습니다. Bash에서:
az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_PORT=8000
PowerShell에서:
Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITES_PORT"="8000"}
App Service는 현재 컨테이너에서 HTTP 요청에 대해 하나의 포트만 공개하도록 허용합니다.
환경 변수 구성
사용자 지정 컨테이너는 외부로 제공해야 하는 환경 변수를 사용할 수 있습니다. 이는 Cloud Shell을 통해 전달할 수 있습니다. Bash에서:
az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings DB_HOST="myownserver.mysql.database.azure.com"
PowerShell에서:
Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"DB_HOST"="myownserver.mysql.database.azure.com"}
앱이 실행되면 App Service 앱 설정이 환경 변수로 프로세스에 자동으로 삽입됩니다. URL(https://<app-name>.scm.azurewebsites.net/Env)을 사용하여 컨테이너 환경 변수를 확인할 수 있습니다.
앱에서 프라이빗 레지스트리 또는 Docker Hub의 이미지를 사용하는 경우 리포지토리에 액세스하기 위한 자격 증명이 환경 변수(DOCKER_REGISTRY_SERVER_URL, DOCKER_REGISTRY_SERVER_USERNAME 및 DOCKER_REGISTRY_SERVER_PASSWORD)에 저장됩니다. 보안 위험으로 인해 이러한 예약된 변수 이름은 애플리케이션에 공개되지 않습니다.
IIS 또는 .NET Framework(4.0 이상) 기반 컨테이너의 경우 App Service를 통해 자동으로 .NET 앱 설정 및 연결 문자열로 System.ConfigurationManager에 삽입됩니다. 다른 모든 언어 또는 프레임워크의 경우 프로세스에 대해 다음 해당 접두사 중 하나가 포함된 환경 변수로 제공됩니다.
APPSETTING_SQLCONTR_MYSQLCONTR_SQLAZURECOSTR_POSTGRESQLCONTR_CUSTOMCONNSTR_
이 메서드는 환경 변수가 docker-compose.yml 파일에 지정된 단일 컨테이너 앱 또는 다중 컨테이너 앱 모두에서 작동합니다.
영구 공유 스토리지 사용
사용자 지정 컨테이너 파일 시스템의 C:\home 디렉터리를 사용하여 다시 시작 시 파일을 유지하여 인스턴스 간에 공유할 수 있습니다. 사용자 지정 컨테이너에서 영구 스토리지에 액세스할 수 있도록 C:\home 디렉터리가 제공됩니다.
영구 스토리지가 사용하지 않도록 설정되면 앱을 다시 시작할 때마다 또는 여러 인스턴스 간에 C:\home 디렉터리에 대한 쓰기가 유지되지 않습니다. 영구 스토리지가 사용하도록 설정되면 C:\home 디렉터리에 대한 모든 쓰기가 유지되고, 확장된 앱의 모든 인스턴스에서 액세스할 수 있습니다. 또한 컨테이너의 C:\home 디렉터리 내의 모든 콘텐츠는 컨테이너가 시작될 때 영구 스토리지에 이미 있는 기존 파일에 의해 덮어씁니다.
유일한 예외는 컨테이너 및 응용 프로그램 로그를 저장하는 데 사용되는 C:\home\LogFiles 디렉터리입니다. 이 폴더는 영구 스토리지를 사용하거나 사용하지 않도록 설정하는 것과는 별개로 파일 시스템 옵션으로 응용 프로그램 로깅을 사용하는 경우 앱이 다시 시작될 때 항상 유지됩니다. 즉, 영구 스토리지를 사용하거나 사용하지 않도록 설정해도 응용 프로그램 로깅 동작에는 영향을 미치지 않습니다.
기본적으로 영구 스토리지는 Windows 사용자 지정 컨테이너에서 사용하지 않도록 설정됩니다. 이를 사용하도록 설정하려면 Cloud Shell을 통해 WEBSITES_ENABLE_APP_SERVICE_STORAGE 앱 설정 값을 true(으)로 설정합니다. Bash에서:
az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=true
PowerShell에서:
Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITES_ENABLE_APP_SERVICE_STORAGE"=true}
사용자 지정 컨테이너 파일 시스템에서 /home 디렉터리를 사용하여 다시 시작할 때마다 파일을 유지하고 인스턴스 간에 공유할 수 있습니다. 사용자 지정 컨테이너에서 영구 스토리지에 액세스할 수 있도록 /home 디렉터리가 제공됩니다. /home 내에 데이터를 저장하면 App Service 계획에 포함된 스토리지 공간 할당량에 영향을 줍니다.
영구 스토리지가 사용하지 않도록 설정되면 앱을 다시 시작할 때마다 또는 여러 인스턴스 간에 /home 디렉터리에 대한 쓰기가 유지되지 않습니다. 영구 스토리지가 사용하도록 설정되면 /home 디렉터리에 대한 모든 쓰기가 유지되고, 확장된 앱의 모든 인스턴스에서 액세스할 수 있습니다. 또한 컨테이너의 /home 디렉터리 내의 모든 콘텐츠는 컨테이너가 시작될 때 영구 스토리지에 이미 있는 기존 파일에 의해 덮어씁니다.
유일한 예외는 컨테이너 및 응용 프로그램 로그를 저장하는 데 사용되는 /home/LogFiles 디렉터리입니다. 이 폴더는 영구 스토리지를 사용하거나 사용하지 않도록 설정하는 것과는 별개로 파일 시스템 옵션으로 응용 프로그램 로깅을 사용하는 경우 앱이 다시 시작될 때 항상 유지됩니다. 즉, 영구 스토리지를 사용하거나 사용하지 않도록 설정해도 응용 프로그램 로깅 동작에는 영향을 미치지 않습니다.
/home 또는 탑재된 Azure Storage 경로에 데이터를 작성하는 것이 좋습니다. 이러한 경로 외부에서 작성된 데이터는 다시 시작하는 동안 지속되지 않으며 App Service 계획 파일 스토리지 할당량과는 별도로 플랫폼 관리 호스트 디스크 공간에 저장됩니다.
기본적으로 영구 스토리지는 Linux 사용자 지정 컨테이너에서 사용하도록 설정됩니다. 이를 사용하지 않도록 설정하려면 Cloud Shell을 통해 WEBSITES_ENABLE_APP_SERVICE_STORAGE 앱 설정 값을 false로 설정합니다. Bash에서:
az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=false
PowerShell에서:
Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITES_ENABLE_APP_SERVICE_STORAGE"=false}
참고 항목
사용자 고유의 영구 스토리지를 구성할 수도 있습니다.
HTTPS 세션 검색
App Service는 프런트 엔드에서 TLS/SSL을 종료합니다. 즉, TLS/SSL 요청이 앱에 도달하지 않습니다. TLS/SSL에 대한 지원을 앱에 구현할 필요가 없고 구현하지도 않아야 합니다.
프런트 엔드는 Azure 데이터 센터 내에 있습니다. 앱에서 TLS/SSL을 사용하면 인터넷상의 트래픽이 항상 안전하게 암호화됩니다.
ASP.NET 컴퓨터 키 삽입 사용자 지정
컨테이너가 시작되는 동안 자동으로 생성된 키는 ASP.NET 암호화 루틴에 대한 컴퓨터 키로 컨테이너에 삽입됩니다. 환경 변수(MACHINEKEY_Decryption, MACHINEKEY_DecryptionKey, MACHINEKEY_ValidationKey, MACHINEKEY_Validation)를 검색하여 컨테이너에서 이러한 키를 찾을 수 있습니다.
앱이 새 키에 종속되는 경우 다시 시작할 때마다 해당 키에서 ASP.NET 양식 인증 및 보기 상태를 다시 설정할 수 있습니다. 키를 자동으로 다시 생성하지 않도록 방지하려면 수동으로 해당 키를 App Service 앱 설정으로 설정합니다.
컨테이너에 연결
https://<app-name>.scm.azurewebsites.net/로 이동하여 진단 작업을 위해 Windows 컨테이너에 직접 연결하고 SSH 옵션을 선택할 수 있습니다. 컨테이너와 직접 SSH 세션이 설정되어 컨테이너 내에서 명령을 실행할 수 있습니다.
- 위의 그래픽 브라우저와는 별도로 작동하며, 공유 스토리지의 파일만 표시합니다.
- 스케일 아웃된 앱에서 SSH 세션은 컨테이너 인스턴스 중 하나에 연결됩니다. 위쪽 Kudu 메뉴의 인스턴스 드롭다운에서 다른 인스턴스를 선택할 수 있습니다.
- SSH 세션 내에서 컨테이너에 대한 변경 내용은 Docker 이미지의 일부가 아니므로 앱을 다시 시작할 때 유지되지 않습니다(공유 스토리지의 변경 내용 제외). 레지스트리 설정 및 소프트웨어 설치와 같은 변경 내용을 유지하려면 해당 변경 내용을 Dockerfile의 일부로 만듭니다.
진단 로그 액세스
App Service는 Docker 호스트의 작업과 컨테이너 내의 작업을 기록합니다. Docker 호스트의 로그(플랫폼 로그)는 기본적으로 제공되지만 컨테이너 내의 애플리케이션 로그 또는 웹 서버 로그는 수동으로 사용하도록 설정해야 합니다. 자세한 내용은 애플리케이션 로깅 사용 및 웹 서버 로깅 사용을 참조하세요.
Docker 로그에 액세스하는 방법에는 여러 가지가 있습니다.
Azure Portal에서
Docker 로그는 포털의 앱 컨테이너 설정 페이지에 표시됩니다. 로그는 잘리지만, 다운로드를 선택하여 모든 로그를 다운로드할 수 있습니다.
Kudu에서
https://<app-name>.scm.azurewebsites.net/DebugConsole로 이동하고, LogFiles 폴더를 선택하여 개별 로그 파일을 확인합니다. 전체 LogFiles 디렉터리를 다운로드하려면 디렉터리 이름 왼쪽에 있는 다운로드 아이콘을 선택합니다. FTP 클라이언트를 사용하여 이 폴더에 액세스할 수도 있습니다.
SSH 터미널에서는 영구 공유 스토리지를 사용하도록 설정할 수 없으므로 기본적으로 C:\home\LogFiles 폴더에 액세스할 수 없습니다. 콘솔 터미널에서 이 동작을 사용하도록 설정하려면 영구 공유 스토리지를 사용하도록 설정합니다.
FTP 클라이언트를 사용하여 현재 사용하고 있는 Docker 로그를 다운로드하려고 하면 파일 잠금으로 인해 오류가 발생할 수 있습니다.
Kudu API를 통해
https://<app-name>.scm.azurewebsites.net/api/logs/docker로 직접 이동하여 Docker 로그에 대한 메타데이터를 확인합니다. 둘 이상의 로그 파일이 나열될 수 있으며, href 속성을 통해 로그 파일을 직접 다운로드할 수 있습니다.
모든 로그를 하나의 ZIP 파일에 함께 다운로드하려면 https://<app-name>.scm.azurewebsites.net/api/logs/docker/zip에 액세스합니다.
컨테이너 메모리 사용자 지정
기본적으로 Azure App Service에 배포된 모든 Windows 컨테이너에는 구성된 메모리 제한이 있습니다. 다음 표에는 App Service 플랜 SKU당 기본 설정이 나열됩니다.
| App Service 요금제 SKU | 앱당 기본 메모리 제한(MB) |
|---|---|
| P1v3 | 1024 |
| P1Mv3 | 1024 |
| P2v3 | 1536 |
| P2Mv3 | 1536 |
| P3v3 | 2048 |
| P3Mv3 | 2048 |
| P4Mv3 | 2560 |
| P5Mv3 | 3072 |
이 값은 Cloud Shell을 통해 WEBSITE_MEMORY_LIMIT_MB 앱 설정을 제공하여 변경할 수 있습니다. Bash에서:
az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITE_MEMORY_LIMIT_MB=2000
PowerShell에서:
Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITE_MEMORY_LIMIT_MB"=2000}
값은 MB 단위로 정의되며, 호스트의 총 실제 메모리보다 작거나 같아야 합니다. 예를 들어 RAM이 8GB인 App Service 요금제에서 모든 앱에 대한 WEBSITE_MEMORY_LIMIT_MB의 누적 합계는 8GB를 초과하지 않아야 합니다. 각 가격 책정 계층에서 사용할 수 있는 메모리 양에 대한 정보는 App Service 가격 책정의 Premium v3 서비스 플랜 섹션에서 확인할 수 있습니다.
컴퓨팅 코어 수 사용자 지정
기본적으로 Windows 컨테이너는 선택한 가격 책정 계층에서 사용할 수 있는 모든 코어를 사용하여 실행됩니다. 예를 들어 스테이징 슬롯에서 사용하는 코어 수를 줄일 수 있습니다. 컨테이너에서 사용하는 코어 수를 줄이려면 WEBSITE_CPU_CORES_LIMIT 앱 설정을 기본 설정 코어 수로 설정합니다. 이는 Cloud Shell을 통해 설정할 수 있습니다. Bash에서:
az webapp config appsettings set --resource-group <group-name> --name <app-name> --slot staging --settings WEBSITE_CPU_CORES_LIMIT=1
PowerShell에서:
Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"WEBSITE_CPU_CORES_LIMIT"=1}
참고 항목
앱 설정을 업데이트하면 자동 다시 시작이 트리거되어 가동 중지 시간을 최소화합니다. 프로덕션 앱의 경우 스테이징 슬롯으로 교환하고, 스테이징 슬롯에서 앱 설정을 변경한 다음, 프로덕션으로 다시 교환하는 것이 좋습니다.
포털에서 또는 Kudu 포털(https://<app-name>.scm.azurewebsites.net/webssh/host)을 통해 SSH 세션을 열고 PowerShell을 사용하여 다음 명령을 입력하여 조정된 숫자를 확인합니다. 각 명령은 숫자를 출력합니다.
Get-ComputerInfo | ft CsNumberOfLogicalProcessors # Total number of enabled logical processors. Disabled processors are excluded.
Get-ComputerInfo | ft CsNumberOfProcessors # Number of physical processors.
프로세서는 다중 코어 또는 하이퍼스레딩 프로세서일 수 있습니다. 각 가격 책정 계층에서 사용할 수 있는 코어 수에 대한 정보는 App Service 가격 책정의 Premium v3 서비스 플랜 섹션에서 확인할 수 있습니다.
상태 ping 동작 사용자 지정
App Service는 컨테이너가 시작되고 HTTP ping에 응답할 때 컨테이너가 성공적으로 시작된 것으로 간주합니다. 상태 ping 요청에는 User-Agent= "App Service Hyper-V Container Availability Check" 헤더가 포함되어 있습니다. 컨테이너가 시작되었지만 특정 시간이 지난 후에도 ping에 응답하지 않으면 App Service에서 컨테이너가 시작되지 않았다는 이벤트를 Docker 로그에 기록합니다.
애플리케이션에서 리소스를 많이 사용하는 경우 컨테이너가 적시에 HTTP ping에 응답하지 않을 수 있습니다. HTTP ping이 실패할 때의 작업을 제어하려면 CONTAINER_AVAILABILITY_CHECK_MODE 앱 설정을 지정합니다. 이는 Cloud Shell을 통해 설정할 수 있습니다. Bash에서:
az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings CONTAINER_AVAILABILITY_CHECK_MODE="ReportOnly"
PowerShell에서:
Set-AzWebApp -ResourceGroupName <group-name> -Name <app-name> -AppSettings @{"CONTAINER_AVAILABILITY_CHECK_MODE"="ReportOnly"}
다음 표에는 가능한 값이 나와 있습니다.
| 값 | 설명 |
|---|---|
| Repair | 3회 연속 가용성 검사 후 컨테이너를 다시 시작합니다. |
| ReportOnly | 기본값입니다. 컨테이너를 다시 시작하지 않고, 3회 연속 가용성 검사 후 컨테이너에 대한 Docker 로그에 보고합니다. |
| 해제 | 가용성을 확인하지 않습니다. |
그룹 관리 서비스 계정 지원
gMSA(그룹 관리 서비스 계정)는 현재 App Service의 Windows 컨테이너에서 지원되지 않습니다.
SSH 사용
SSH(Secure Shell)는 주로 명령줄 터미널에서 원격으로 관리 명령을 실행하는 데 사용합니다. 사용자 지정 컨테이너에서 Azure Portal SSH 콘솔 기능을 사용하도록 설정하려면 다음 단계가 필요합니다.
다음 예제 내용으로 표준
sshd_config파일을 만들고 애플리케이션 프로젝트 루트 디렉터리에 배치합니다.Port 2222 ListenAddress 0.0.0.0 LoginGraceTime 180 X11Forwarding yes Ciphers aes128-cbc,3des-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr MACs hmac-sha1,hmac-sha1-96 StrictModes yes SyslogFacility DAEMON PasswordAuthentication yes PermitEmptyPasswords no PermitRootLogin yes Subsystem sftp internal-sftp참고 항목
이 파일은 OpenSSH를 구성하며 Azure Portal SSH 기능을 준수하려면 다음 항목을 포함해야 합니다.
Port는 2222로 설정해야 합니다.Ciphers는 이 목록에 적어도 하나의 항목이 있어야 합니다.aes128-cbc,3des-cbc,aes256-cbcMACs는 이 목록에 적어도 하나의 항목이 있어야 합니다.hmac-sha1,hmac-sha1-96
entrypoint.sh이름을 사용하여 진입점 스크립트를 만들고(또는 기존 진입점 파일을 변경) 애플리케이션 시작 명령과 함께 SSH 서비스를 시작하는 명령을 추가합니다. 다음 예제에서는 Python 애플리케이션을 시작하는 방법을 보여 줍니다. 프로젝트 언어/스택에 따라 마지막 명령을 바꿉니다.기본 이미지 배포에 따라 다음 지침을 Dockerfile에 추가합니다. 이러한 지침은 새 파일을 복사하고, OpenSSH 서버를 설치하고, 적절한 권한을 설정하고, 사용자 지정 진입점을 구성하고, 애플리케이션 및 SSH 서버에 필요한 포트를 각각 노출합니다.
COPY entrypoint.sh ./ # Start and enable SSH RUN apt-get update \ && apt-get install -y --no-install-recommends dialog \ && apt-get install -y --no-install-recommends openssh-server \ && echo "root:Docker!" | chpasswd \ && chmod u+x ./entrypoint.sh COPY sshd_config /etc/ssh/ EXPOSE 8000 2222 ENTRYPOINT [ "./entrypoint.sh" ]참고 항목
루트 암호는 컨테이너를 사용하여 SSH 세션에 액세스할 수 있도록 App Service에서 사용하는 것과 정확히
Docker!와 일치해야 합니다. 이 구성은 컨테이너에 대한 외부 연결을 허용하지 않습니다. 컨테이너의 2222 포트는 개인 가상 네트워크의 브리지 네트워크 내에서만 액세스할 수 있으며, 인터넷에서 공격자가 액세스할 수 없습니다.Docker 이미지를 다시 빌드하고 레지스트리에 푸시한 다음, Azure Portal에서 웹앱 SSH 기능을 테스트합니다.
추가 문제 해결에 대한 자세한 내용은 Azure App Service 블로그: Linux Web App for Containers에서 SSH 사용 설정에서 확인할 수 있습니다
진단 로그 액세스
컨테이너 내부에서 생성된 콘솔 로그에 액세스할 수 있습니다.
먼저 다음 명령을 실행하여 컨테이너 로깅을 설정합니다.
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의 브라우저에서 로그 파일을 검사할 수도 있습니다.
다중 컨테이너 앱 구성
Docker Compose에서 영구 스토리지 사용
WordPress와 같은 다중 컨테이너 앱이 제대로 작동하려면 영구 스토리지가 필요합니다. 이를 사용하도록 설정하려면 Docker Compose 구성이 컨테이너 외부의 스토리지 위치를 가리켜야 합니다. 컨테이너 내부의 스토리지 위치에 대한 변경 내용은 앱을 다시 시작한 이후에는 유지되지 않습니다.
Cloud Shell에서 az webapp config appsettings set 명령을 사용하여 WEBSITES_ENABLE_APP_SERVICE_STORAGE 앱 설정을 지정하여 영구 스토리지를 사용하도록 설정합니다.
az webapp config appsettings set --resource-group <group-name> --name <app-name> --settings WEBSITES_ENABLE_APP_SERVICE_STORAGE=TRUE
docker-compose.yml 파일에서 volumes 옵션을 ${WEBAPP_STORAGE_HOME}에 매핑합니다.
WEBAPP_STORAGE_HOME은 앱의 영구 스토리지에 매핑되는 App Service의 환경 변수입니다. 예시:
wordpress:
image: <image name:tag>
volumes:
- "${WEBAPP_STORAGE_HOME}/site/wwwroot:/var/www/html"
- "${WEBAPP_STORAGE_HOME}/phpmyadmin:/var/www/phpmyadmin"
- "${WEBAPP_STORAGE_HOME}/LogFiles:/var/log"
미리 보기 제한 사항
다중 컨테이너는 현재 미리 보기에 있습니다. 다음 App Service 플랫폼 기능은 지원되지 않습니다.
- 인증/권한 부여
- 관리 ID
- CORS
- Docker Compose 시나리오에서는 가상 네트워크 통합이 지원되지 않습니다
- 현재 Azure App Services의 Docker Compose는 4,000자로 제한되어 있습니다.
Docker Compose 옵션
다음 목록에는 지원되는 Docker Compose 구성 옵션 및 지원되지 않는 Docker Compose 구성 옵션이 나와 있습니다.
지원되는 옵션
- command
- entrypoint
- environment
- 이미지
- 고서
- restart
- services
- 볼륨(Azure Storage에 대한 매핑이 지원되지 않음)
지원되지 않는 옵션
- build(허용 안 함)
- depends_on (무시됨)
- networks(무시됨)
- secrets(무시됨)
- 포트 80 및 8080 이외의 포트(무시됨)
- docker와 달리
$variable and ${variable}과 같은 기본 환경 변수
구문 제한 사항
- "버전 x.x"는 항상 파일의 첫 번째 YAML 문이어야 합니다.
- 포트 섹션은 인용된 숫자를 사용해야 합니다.
- 이미지 > 볼륨 섹션은 인용해야 하며 권한 정의를 가질 수 없습니다.
- 볼륨 섹션에는 볼륨 이름 뒤에 빈 중괄호가 없어야 합니다.
참고 항목
명시적으로 호출되지 않는 다른 옵션은 공개 미리 보기에서 무시됩니다.
로그의 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에 알려줍니다.
다음 단계
또는 더 많은 리소스를 참조하세요.