다음을 통해 공유

Azure App Service에 대한 사용자 지정 컨테이너 구성

이 문서에서는 Azure App Service에서 실행되도록 사용자 지정 컨테이너를 구성하는 방법을 보여 줍니다.

주요 개념에 대해 알아보고 App Service에서 Windows 앱의 컨테이너화에 대한 지침을 가져옵니다. 새 사용자는 먼저 사용자 지정 컨테이너 빠른 시작 및 자습서를 따라야 합니다.

주요 개념에 대해 알아보고 App Service에서 Linux 앱의 컨테이너화에 대한 지침을 가져옵니다. 새 사용자는 먼저 사용자 지정 컨테이너 빠른 시작 및 자습서를 따라야 합니다. 사이드카 컨테이너의 경우 자습서: Azure App Service에서 사용자 지정 컨테이너에 대한 사이드카 컨테이너 구성을 참조하세요.

참고

Windows 컨테이너 이미지 끌어오기 인증에 서비스 주체를 사용하는 것은 더 이상 지원되지 않습니다. Windows 및 Linux 컨테이너 모두에 관리 ID를 사용하는 것이 좋습니다.

지원되는 부모 이미지

사용자 지정 Windows 이미지에 원하는 프레임워크에 적합한 부모 이미지(기본 이미지) 를 선택합니다.

  • .NET Framework 앱을 배포하려면 Windows Server 2019 Core Long-Term 서비스 채널 릴리스를 기반으로 하는 부모 이미지를 사용합니다.
  • .NET Core 앱을 배포하려면 Windows Server 2019 Nano 연간 채널 릴리스를 기반으로 하는 부모 이미지를 사용합니다.

앱을 시작하는 동안 부모 이미지를 다운로드하는 데 다소 시간이 걸립니다. Azure App Service에 이미 캐시된 다음 부모 이미지 중 하나를 사용하여 시작 시간을 줄일 수 있습니다.

사용자 지정 컨테이너의 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>

\<username>와 \<password> 필드에 개인 레지스트리 계정의 로그인 자격 증명을 입력하십시오.

관리 ID를 사용하여 Azure Container Registry에서 이미지 끌어오기

다음 단계를 사용하여 관리 ID를 사용하여 Azure Container Registry에서 끌어오도록 웹앱을 구성합니다. 이 단계에서는 시스템 할당 관리 ID를 사용하지만 사용자 할당 관리 ID를 사용할 수도 있습니다.

  1. 다음 명령을 사용하여 웹앱에 대해 시스템 할당 관리 ID 를 az webapp identity assign 사용하도록 설정합니다.

    az webapp identity assign --resource-group <group-name> --name <app-name> --query principalId --output tsv

    앱 이름을< 이전 단계에서 사용한 이름으로 바꿉>습니다. 명령의 출력은 --query 및 --output 인수에 의해 필터링되어 할당된 ID의 서비스 주체 ID를 나타냅니다.

  2. 컨테이너 레지스트리의 리소스 ID를 가져옵니다.

    az acr show --resource-group <group-name> --name <registry-name> --query id --output tsv

    <registry-name>을(를) 사용자의 레지스트리 이름으로 대체하십시오. 명령의 출력은 --query 및 --output 인수로 필터링된 컨테이너 레지스트리의 리소스 ID입니다.

  3. 컨테이너 레지스트리에 액세스할 수 있는 권한을 관리 ID에 부여합니다.

    az role assignment create --assignee <principal-id> --scope <registry-resource-id> --role "AcrPull"

    다음 값을 바꿉니다.

    • <
    • <registry-resource-id>는 az acr show 명령에서 가져온 컨테이너 레지스트리의 ID입니다.

    이러한 권한에 대한 자세한 내용은 Azure 역할 기반 액세스 제어란?을 참조하세요.

  4. Azure Container Registry에서 가져올 관리 ID를 사용하도록 앱을 구성합니다.

    az webapp config set --resource-group <group-name> --name <app-name> --generic-configurations '{"acrUseManagedIdentityCreds": true}'

    다음 값을 바꿉니다.

    • <웹앱의 이름>으로 대체하십시오.

    팁

    PowerShell 콘솔을 사용하여 명령을 실행하는 경우 이 단계와 다음 단계의 --generic-configurations 인수에서 문자열을 이스케이프합니다. 예: --generic-configurations '{\"acrUseManagedIdentityCreds\": true'.

  5. (선택 사항) 앱에서 사용자가 할당한 관리 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>"}'

이제 웹앱은 관리 ID를 사용하여 Azure Container Registry에서 가져옵니다.

네트워크로 보호된 레지스트리의 이미지 사용

가상 네트워크 또는 온-프레미스 내의 레지스트리에 연결하고 끌어오려면 앱이 가상 네트워크와 통합되어야 합니다. 또한 프라이빗 엔드포인트와 Azure Container Registry에 대한 가상 네트워크 통합이 필요합니다. 네트워크와 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 설정을 지정합니다. Azure 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 이미지를 사용하여 컨테이너에 SSH하는 경우 같은 envprintenv명령을 사용하려고 하면 몇 가지 환경 변수만 표시될 수 있습니다. 런타임 사용을 위해 애플리케이션에 전달하는 것과 같이 컨테이너 내의 모든 환경 변수를 보려면 진입점 스크립트에 다음 줄을 추가합니다.

eval $(printenv | sed -n "s/^\([^=]\+\)=\(.*\)$/export \1=\2/p" | sed 's/"/\\\"/g' | sed '/=/s//="/' | sed 's/$/"/' >> /etc/profile)

전체 예제를 참조하세요.

앱이 프라이빗 레지스트리 또는 Docker Hub의 이미지를 사용하는 경우 리포지토리에 액세스하기 위한 자격 증명이 환경 변수에 DOCKER_REGISTRY_SERVER_URLDOCKER_REGISTRY_SERVER_USERNAMEDOCKER_REGISTRY_SERVER_PASSWORD저장됩니다. 보안 위험으로 인해 이러한 예약된 변수 이름은 애플리케이션에 공개되지 않습니다.

IIS(인터넷 정보 서비스) 또는 .NET Framework(4.0 이상) 컨테이너의 경우 App Service에서 System.ConfigurationManager 자격 증명을 .NET 앱 설정 및 연결 문자열로 자동으로 삽입합니다. 다른 모든 언어 또는 프레임워크의 경우 다음 접두사 중 하나를 사용하여 프로세스에 대한 환경 변수로 제공됩니다.

  • APPSETTING_
  • SQLCONTR_
  • MYSQLCONTR_
  • SQLAZURECOSTR_
  • POSTGRESQLCONTR_
  • CUSTOMCONNSTR_

이 메서드는 파일에서 환경 변수가 지정된 단일 컨테이너 또는 다중 컨테이너 앱 모두에 docker-compose.yml 사용할 수 있습니다.

영구 공유 스토리지 사용

사용자 지정 컨테이너 파일 시스템의 디렉터리를 사용하여 C:\home 다시 시작에 걸쳐 파일을 유지하여 인스턴스 간에 공유할 수 있습니다. 디렉터리를 사용하는 C:\home 경우 사용자 지정 컨테이너가 영구 스토리지에 액세스할 수 있습니다.

영구 스토리지를 사용하지 않도록 설정하면 앱 다시 시작 또는 여러 인스턴스에서 디렉터리에 대한 쓰기 C:\home 가 유지되지 않습니다. 비휘발성 저장소를 사용하도록 설정하면 C:\home 디렉터리에 대한 모든 쓰기가 저장됩니다. 스케일 아웃된 앱의 모든 인스턴스가 액세스할 수 있습니다. 컨테이너가 시작되면 영구 스토리지에 파일이 있는 경우 컨테이너의 디렉터리에 있는 C:\home 내용을 덮어씁니다.

유일한 예외는 디렉터리입니다 C:\home\LogFiles . 이 디렉터리에는 컨테이너 및 애플리케이션 로그가 저장됩니다. 영구 스토리지를 사용하는지 여부에 관계없이 파일 시스템 옵션으로 애플리케이션 로깅을 사용하도록 설정하면 앱이 다시 시작될 때 폴더가 항상 유지됩니다. 즉, 영구 스토리지를 사용하거나 사용하지 않도록 설정하면 애플리케이션 로깅 동작에 영향을 주지 않습니다.

기본적으로 영구 스토리지는 Windows 사용자 지정 컨테이너에서 사용하도록 설정됩니다. 사용하지 않도록 설정하려면 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}

사용자 지정 컨테이너 파일 시스템의 디렉터리를 사용하여 /home 다시 시작에 걸쳐 파일을 유지하여 인스턴스 간에 공유할 수 있습니다. 디렉터리를 사용하는 C:\home 경우 사용자 지정 컨테이너가 영구 스토리지에 액세스할 수 있습니다. 저장한 데이터 /home는 앱 서비스 계획에 포함된 스토리지 공간 할당량에 영향을 줍니다.

영구 스토리지를 사용하지 않도록 설정하면 앱 다시 시작 또는 여러 인스턴스에서 디렉터리에 대한 쓰기 C:\home 가 유지되지 않습니다. 영구 스토리지를 사용하도록 설정하면 C:\home 디렉터리에 대한 모든 쓰기가 영구히 저장됩니다. 스케일 아웃된 앱의 모든 인스턴스가 액세스할 수 있습니다. 컨테이너가 시작되면 영구 스토리지에 파일이 있는 경우 컨테이너의 디렉터리에 있는 C:\home 내용을 덮어씁니다.

유일한 예외는 디렉터리입니다 C:\home\LogFiles . 이 디렉터리에는 컨테이너 및 애플리케이션 로그가 저장됩니다. 영구 스토리지를 사용하는지 여부에 관계없이 파일 시스템 옵션으로 애플리케이션 로깅을 사용하도록 설정하면 앱이 다시 시작될 때 폴더가 항상 유지됩니다. 즉, 영구 스토리지를 사용하거나 사용하지 않도록 설정하면 애플리케이션 로깅 동작에 영향을 주지 않습니다.

/home 또는 에 데이터를 쓰는 것이 좋습니다. 이러한 경로 외부에서 작성하는 데이터는 다시 시작하는 동안 지속되지 않습니다. 데이터는 App Service 계획 파일 스토리지 할당량과 별도로 플랫폼 관리형 호스트 디스크 공간에 저장됩니다.

기본적으로 영구 스토리지는 Linux 사용자 지정 컨테이너에서 사용하지 않도록 설정됩니다. 사용하도록 설정하려면 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}

참고

사용자 고유의 영구 스토리지를 구성할 수도 있습니다.

HTTPS 세션 검색

App Service는 프런트 엔드에서 TLS를 종료합니다. 즉, TLS 요청은 앱에 액세스하지 않습니다. TLS에 대한 지원을 앱에 구현할 필요가 없으며 구현해서는 안 됩니다.

프런트 엔드는 Azure 데이터 센터 내에 있습니다. 앱에서 TLS를 사용하는 경우 인터넷을 통해 트래픽이 항상 안전하게 암호화됩니다.

ASP.NET 컴퓨터 키 삽입 사용자 지정

컨테이너를 시작하는 동안 키가 자동으로 생성되고 컨테이너에 ASP.NET 암호화 루틴에 대한 머신 키로 삽입됩니다. 다음 환경 변수를 찾아 컨테이너에서 이러한 키를 찾을 수 있습니다. MACHINEKEY_DecryptionMACHINEKEY_DecryptionKeyMACHINEKEY_ValidationKeyMACHINEKEY_Validation

앱이 새 키에 종속되는 경우 다시 시작할 때마다 해당 키에서 ASP.NET 양식 인증 및 보기 상태를 다시 설정할 수 있습니다. 키를 자동으로 다시 생성하지 않도록 방지하려면 수동으로 해당 키를 App Service 앱 설정으로 설정합니다.

컨테이너에 연결

진단 작업을 위해 Windows 컨테이너에 직접 연결하려면 SSH 옵션으로 https://<app-name>.scm.azurewebsites.net/ 이동하여 선택합니다. 이 옵션은 컨테이너 내에서 명령을 실행할 수 있는 직접 SSH 세션을 설정합니다.

  • 위의 그래픽 브라우저와는 별도로 작동하며, 공유 스토리지의 파일만 표시합니다.
  • 확장된 앱에서 SSH 세션은 컨테이너 인스턴스 중 하나에 연결됩니다. 위쪽 Kudu 메뉴의 인스턴스 드롭다운 목록에서 다른 인스턴스를 선택할 수 있습니다.
  • 공유 스토리지의 변경 내용을 제외하고 SSH 세션 내에서 컨테이너를 변경한 내용은 앱이 다시 시작될 때 유지 되지 않습니다 . 이러한 변경 내용은 Docker 이미지의 일부가 아닙니다. 레지스트리 설정 및 소프트웨어 설치와 같은 변경 내용을 유지하려면 Dockerfile의 일부로 만듭니다.

진단 로그 액세스

App Service는 Docker 호스트의 작업과 컨테이너 내의 작업을 기록합니다. Docker 호스트(플랫폼 로그)의 로그는 기본적으로 사용하도록 설정됩니다. 컨테이너 내에서 애플리케이션 로그 또는 웹 서버 로그를 수동으로 사용하도록 설정해야 합니다. 자세한 내용은 애플리케이션 로깅 사용 및 웹 서버 로깅 사용을 참조하세요.

다음과 같은 여러 가지 방법으로 Docker 로그에 액세스할 수 있습니다.

Azure 포털

Docker 로그는 앱의 컨테이너 설정 창에 Azure Portal에 표시됩니다. 로그가 잘립니다. 모든 로그를 다운로드하려면 다운로드를 선택합니다.

Kudu

개별 로그 파일을 보려면 폴더로 https://<app-name>.scm.azurewebsites.net/DebugConsole 이동하여 선택합니다 LogFiles . 전체 LogFiles 디렉터리를 다운로드하려면 디렉터리 이름 왼쪽에 있는 다운로드 아이콘을 선택합니다. FTP 클라이언트를 사용하여 이 폴더에 액세스할 수도 있습니다.

기본적으로 영구 공유 스토리지를 C:\home\LogFiles 사용할 수 없으므로 SSH 터미널의 폴더에 액세스할 수 없습니다. 콘솔 터미널에서 이 동작을 사용하도록 설정하려면 영구 공유 스토리지를 사용하도록 설정합니다.

FTP 클라이언트를 사용하여 현재 사용 중인 Docker 로그를 다운로드하려고 하면 파일 잠금으로 인해 오류가 발생할 수 있습니다.

Kudu API

Docker 로그에 https://<app-name>.scm.azurewebsites.net/api/logs/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

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}

팁

앱 설정을 업데이트하면 자동 다시 시작이 트리거되어 가동 중지 시간이 최소화됩니다. 프로덕션 앱의 경우, 스테이징 슬롯으로 전환하는 것을 고려해 보세요. 스테이징 슬롯에서 앱 설정을 변경한 후 프로덕션으로 전환합니다.

조정된 번호를 확인하려면 Azure Portal 또는 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"}

다음 표에는 가능한 값이 나와 있습니다.

값 Description
Repair 세 번의 연속 가용성 검사 후 컨테이너를 다시 시작합니다.
ReportOnly 기본값입니다. 세 번의 연속 가용성 검사 후에 Docker 로그에 컨테이너를 기록하지만 다시 시작하지 마세요.
Off 가용성을 확인하지 않습니다.

그룹 관리 서비스 계정에 대한 지원

그룹 관리 서비스 계정은 App Service의 Windows 컨테이너에서 지원되지 않습니다.

SSH 사용

SSH(Secure Shell)를 사용하여 명령줄 터미널에서 관리 명령을 원격으로 실행할 수 있습니다. 사용자 지정 컨테이너에서 Azure Portal SSH 콘솔 기능을 사용하도록 설정하려면 다음 단계를 수행합니다.

  1. 다음 예제 내용으로 표준 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-cbc.
    • 값에는 이 목록의 항목 하나 이상이 반드시 포함되어야 합니다: hmac-sha1 또는 hmac-sha1-96.

  2. 명명 entrypoint.sh 된 진입점 스크립트를 만들거나 기존 진입점 파일을 변경합니다. 애플리케이션 시작 명령과 함께 SSH 서비스를 시작하는 명령을 추가합니다. 다음 예제에서는 Python 애플리케이션을 시작하는 방법을 보여 줍니다. 프로젝트 언어 또는 스택에 따라 마지막 명령을 바꿉니다.

    #!/bin/sh
set -e
service ssh start
exec gunicorn -w 4 -b 0.0.0.0:8000 app:app

  3. 기본 이미지 배포에 따라 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 는 프라이빗 가상 네트워크의 브리지 네트워크 내에서만 액세스할 수 있습니다. 인터넷의 공격자는 액세스할 수 없습니다.

  4. Docker 이미지를 다시 빌드하고 레지스트리에 푸시한 다음 Azure Portal에서 웹앱 SSH 기능을 테스트합니다.

자세한 문제 해결 정보는 Azure App Service 블로그: 컨테이너용 Linux 웹앱에서 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를 사용합니다.

다중 컨테이너 앱 구성

참고

Docker Compose 기능은 2027년 3월 31일에 사용 중지됩니다. 사이드카 컨테이너는 App Service에서 다중 컨테이너 앱의 후속입니다. 새 서비스의 경우 자습서: Azure App Service에서 사용자 지정 컨테이너에 대한 사이드카 컨테이너 구성을 참조하세요. App Service의 기존 다중 컨테이너 앱에 대해서는 Docker Compose 애플리케이션을 사이드카 기능으로 마이그레이션하는 방법을 참조하세요.

Docker Compose에서 영구 스토리지 사용

WordPress와 같은 다중 컨테이너 앱이 제대로 작동하려면 영구 스토리지가 필요합니다. 영구 스토리지를 사용하도록 설정하려면 Docker Compose 구성이 컨테이너 외부 의 스토리지 위치를 가리킵니다. 컨테이너 내부의 스토리지 위치에 대한 변경 내용은 앱을 다시 시작한 이후에는 유지되지 않습니다.

영구 스토리지를 사용하도록 설정하려면 앱 설정을 지정합니다 WEBSITES_ENABLE_APP_SERVICE_STORAGE . az webapp config appsettings set에서 명령을 사용합니다.

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 Service의 Docker Compose는 현재 4,000자로 제한됩니다.

Docker Compose 옵션

다음 섹션에서는 지원되는 Docker Compose 구성 옵션과 지원되지 않는 Docker Compose 구성 옵션을 보여 줍니다.

지원되는 옵션

지원되지 않는 옵션

  • build (허용되지 않음)
  • depends_on (무시됨)
  • networks (무시됨)
  • secrets (무시됨)
  • 이외의 80 포트( 8080 무시됨)
  • 기본 환경 변수 $variable 및 ${variable} (Docker와 다르게)

구문 제한 사항

  • 파일의 첫 번째 YAML 문은 항상 version x.x이어야 합니다.
  • 포트 섹션에서 따옴표 붙은 숫자를 사용해야 합니다.
  • 섹션은 image > volume 따옴표로 묶어야 하며 사용 권한 정의를 가질 수 없습니다.
  • 볼륨 섹션은 볼륨 이름 뒤에 빈 중괄호를 포함할 수 없습니다.

참고

명시적으로 언급되지 않은 다른 옵션은 미리 보기에서 무시됩니다.

로그에서 robots933456 메시지 무시

컨테이너 로그에 다음 메시지가 표시될 수 있습니다.

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

이 메시지는 무시해도 괜찮습니다. /robots933456.txt 는 더미 URL 경로입니다. App Service는 이를 사용하여 컨테이너가 요청을 처리할 수 있는지 확인합니다. "404" 오류 응답은 경로가 존재하지 않음을 나타내며, 컨테이너가 정상이며 요청에 응답할 준비가 되었음을 App Service에 알립니다.

관련 콘텐츠

  • Last updated on