Azure Container Apps에 관한 자주 묻는 질문(FAQ)

다음 Azure CLI 명령을 실행하면 목록을 생성할 수 있습니다.

  az provider show \
  --namespace Microsoft.App \
  --query "resourceTypes[?resourceType=='managedEnvironments'].locations"

아니요, Azure Container Apps는 Kubernetes API에 대한 직접적인 접근을 제공하지 않습니다.

네, API Management의 컨텍스트에서 Azure Container Apps API를 가져올 수 있습니다.

청구는 CPU, 메모리, 요청 수를 포함한 리소스 사용량을 기준으로 합니다. 자세한 내용은 청구 페이지를 참조하세요.

네. GitHub Actions는 Azure CLI 또는 Azure 포털을 사용하여 구성할 수 있습니다.

• Azure CLI를 사용하여 az containerapp github-action -h를 실행하여 옵션을 확인합니다.

• Azure 포털에서 컨테이너 앱의 "지속적 배포" 창으로 이동합니다.

Azure Container Apps는 URL 혼동 공격으로부터 앱을 보호하기 위해 URL을 디코딩합니다. 인코딩된 부분을 포함한 요청 URL, 예를 들어 http://mysite.com/archive/http%3A%2F%2Fmysite.com%2Farchive%2F123은 앱에 http://mysite.com/archive/http%3A/mysite.com/archive/123 형태로 전송됩니다.

소비 기반 환경에서는 사용자 정의 경로(UDR)에 대한 지원이 제한적입니다. ExpressRoute는 지원되지 않습니다. 제한된 사용자 정의 경로(UDR) 지원은 다음과 같이 구성할 때 사용할 수 있습니다.

• 경로는 Azure.<REGION_NAME> 서비스 태그를 사용하고 다음 홉을 "인터넷"으로 설정하여 정의해야 합니다.

• 환경이 올바르게 작동하도록 하려면 네트워크 보안 그룹(NSG) 규칙도 NSG 문서에 설명된 대로 구성해야 합니다.

이러한 제한 사항은 워크로드 프로필에는 적용되지 않으며, 완전한 UDR 및 Express Route 지원을 위해서는 워크로드 프로필 환경을 사용해야 합니다.

Azure Container Apps는 배포된 지역 외부로 고객 데이터를 이동하거나 저장하지 않습니다.

Azure 포털에서 할당량 증가를 요청할 때 Azure Container Apps를 공급자로 선택합니다.

할당량 증가 요청을 제출할 때 다음 세부 정보를 고려합니다.

• 앱과 환경의 스케일링: 증가시킬 수 있는 다양한 할당량이 있습니다. 다음 설명을 사용하여 필요 사항을 식별하는 데 도움을 받으세요.

  • 환경당 앱 및 코어 증가: 환경 내에서 더 많은 앱을 실행하거나 더 많은 리소스를 요구하는 앱을 실행할 수 있습니다. 워크로드를 동일한 네트워크 및 보안 경계 내에서 배포할 수 있는 경우 권장됩니다.
  • 환경 증가: 워크로드에 네트워크 또는 보안 경계가 필요한 경우 권장됩니다. 참고: 환경 수준 할당량 증가 요청이 포함된 경우, 자세한 비즈니스 컨텍스트가 필요할 수 있습니다. 지역 환경 할당량 변경을 요청할 때는 글로벌 환경 할당량에도 해당 변경을 요청해야 합니다.

• 지역: 증가 요청 승인은 Azure 지역에서 사용할 수 있는 컴퓨팅 용량에 따라 달라집니다.

• 특정 컴퓨팅 요구 사항: 플랫폼은 컨테이너 앱당 4GB를 지원합니다. 메모리 제한 재정의는 개별 사례별로 평가됩니다.

• 크기 조정에 대한 비즈니스 사유: 플랫폼 제한으로 인해 워크로드 요구 사항이 차단되는 경우, 할당량 증가 요청 자격이 있을 수 있습니다. 스케일 제한 재정의는 개별 사례별로 평가됩니다.

각 Dapr 기능은 Azure Container Apps 환경에서 마이크로서비스를 실행하는 고객에게 긍정적인 영향을 미치고 최상의 경험을 제공하는지 확인하기 위해 철저하게 평가됩니다.

Dapr의 알파 API는 사용 가능성이 보장되지 않으며, Microsoft의 지원을 받지 않습니다.

1단계 구성 요소는 완전히 지원되지만, 2단계 구성 요소는 최선의 노력으로 지원됩니다. 더 알아보기.

Azure Container Apps GitHub 저장소를 통해 기능 요청을 제출할 수 있습니다. 기능 요청 제목에 "Dapr"를 포함해야 합니다.

1.13.6-msft.1이 프로덕션 지역에 배포되는 동안, 이전 버전(1.12.5 또는 1.12.5-msft.6 등)을 여전히 볼 수 있습니다. -msft.<number> 접미사는 환경을 향상시키기 위해 Azure Container Apps에 대한 특정 사용자 지정을 나타냅니다.

Dapr 버전은 안정성, 철저한 테스트, 고객 영향 최소화에 중점을 두고 최선의 노력으로 업데이트됩니다. 목표는 업데이트가 문제를 일으키지 않고 원활하게 통합되도록 하는 것입니다.

Dapr 버전 업데이트는 자동으로 적용되므로 항상 가장 안전한 버전을 사용할 수 있습니다. 하지만 Azure Container Apps의 Dapr는 새로운 기능에 대해 고정된 릴리스 일정을 따르지 않습니다. 대신, 새로운 기능을 위한 Dapr 버전의 릴리스는 Dapr 바이너리의 우선순위와 안정성에 따라 결정됩니다.

GitHub의 Azure Container Apps에서 Dapr에 대한 업데이트 및 릴리스 공지 사항을 찾습니다.

사용자 지정 버전 선택은 지원되지 않습니다. 대신 환경이 자동으로 업그레이드되어 Azure Container Apps에서 Dapr의 완전 관리형 서버리스 서비스의 무결성이 유지됩니다. 컨테이너 앱 환경에서 계획된 유지 관리 기능을 구성하여 자동 업그레이드를 제어할 수 있습니다.

Docker 없이 배포하면 코드에 Dockerfile을 정의하지 않고도 애플리케이션을 배포할 수 있습니다. 대신, Container Apps 클라우드 빌드 기능은 Buildpacks를 사용하여 로컬 머신의 소스 코드를 컨테이너 이미지로 변환합니다. 이 옵션은 Azure Container Apps 기본 레지스트리를 사용합니다.

Docker 없는 배포에서 알려진 문제가 발생합니다. 다시 시도하면 이 문제가 해결될 수 있습니다. 이 문제가 발생하면 팀에서 조사할 수 있도록 GitHub 문제를 개설합니다.

Azure Container Apps의 모든 .NET 앱에 대해 데이터 보호를 활성화해야 합니다. 자세한 내용은 Azure Container Apps에서 ASP.NET Core 앱 배포 및 스케일링을 참조하세요.

Container Apps는 JDK 8, JDK 11, JDK 17 및 JDK 21의 4가지 LTS JDK 버전을 지원합니다. 소스 코드 빌드의 기본 버전은 JDK 17입니다. JAR 파일 빌드의 경우 JDK 버전은 JAR 내 META-INF\MANIFEST.MF 파일 위치에서 읽지만, 지정된 버전을 사용할 수 없는 경우 기본 JDK 버전 17을 사용합니다.

빌드 환경 변수를 통해 기본 버전을 재정의하도록 JDK 버전을 구성할 수 있습니다.

Azure Container Apps는 현재 Java 빌드 도구로 Apache Maven을 지원합니다.

빌드 환경 변수를 통해 Java 이미지 빌드를 사용자 지정할 수 있습니다.

Docker 없는 코드베이스와 containerapp up을 함께 사용할 때, 애플리케이션이 미국 동부가 아닌 다른 위치에서 실행되도록 --location 매개변수를 사용하세요.

컨테이너 이미지에 latest과 같은 정적 태그 사용을 피하세요. 정적 태그를 사용하면 캐싱 문제가 발생할 수 있으며, 앱 문제를 해결하기 어렵게 만들 수 있습니다. 대신, 각 배포마다 Git 해시나 날짜 및 시간을 포함한 고유 태그를 사용하여 업데이트가 올바르게 추적되고 배포되도록 하세요.

관리되는 에이전트는 gRPC만 지원합니다.