Azure Container Apps의 컨테이너
Azure Container Apps는 Kubernetes 및 컨테이너 오케스트레이션의 세부 정보를 관리합니다. Azure Container Apps의 컨테이너는 사용자가 선택한 런타임, 프로그래밍 언어 또는 개발 스택을 사용할 수 있습니다.
Azure Container Apps는 다음을 지원합니다.
다음 기능도 포함됩니다.
- 앱은
template
구성 섹션을 사용하여 컨테이너 이미지와 기타 설정을 정의합니다.template
구성 섹션을 변경하면 새로운 컨테이너 앱 수정 버전이 트리거됩니다. - 컨테이너가 충돌하면 자동으로 다시 시작됩니다.
작업 기능은 다음과 같습니다.
- 작업 실행은
template
구성 섹션을 사용하여 각 실행이 시작될 때 컨테이너 이미지와 기타 설정을 정의합니다. - 컨테이너가 0이 아닌 종료 코드로 종료되면 작업 실행이 실패한 것으로 표시됩니다. 실패한 실행을 다시 시도하도록 작업을 구성할 수 있습니다.
구성
대부분의 컨테이너 앱에는 단일 컨테이너가 있습니다. 고급 시나리오에서는 앱에 사이드카와 init 컨테이너가 있을 수도 있습니다. 컨테이너 앱 정의에서 메인 앱과 사이드카 컨테이너는 properties.template
섹션의 containers
배열에 나열되고, init 컨테이너는 initContainers
배열에 나열됩니다. 다음 발췌 내용은 앱의 컨테이너를 설정할 때 사용 가능한 구성 옵션을 보여 줍니다.
{
"properties": {
"template": {
"containers": [
{
"name": "main",
"image": "[parameters('container_image')]",
"env": [
{
"name": "HTTP_PORT",
"value": "80"
},
{
"name": "SECRET_VAL",
"secretRef": "mysecret"
}
],
"resources": {
"cpu": 0.5,
"memory": "1Gi"
},
"volumeMounts": [
{
"mountPath": "/appsettings",
"volumeName": "appsettings-volume"
}
],
"probes": [
{
"type": "liveness",
"httpGet": {
"path": "/health",
"port": 8080,
"httpHeaders": [
{
"name": "Custom-Header",
"value": "liveness probe"
}
]
},
"initialDelaySeconds": 7,
"periodSeconds": 3
},
{
"type": "readiness",
"tcpSocket": {
"port": 8081
},
"initialDelaySeconds": 10,
"periodSeconds": 3
},
{
"type": "startup",
"httpGet": {
"path": "/startup",
"port": 8080,
"httpHeaders": [
{
"name": "Custom-Header",
"value": "startup probe"
}
]
},
"initialDelaySeconds": 3,
"periodSeconds": 3
}
]
}
]
},
"initContainers": [
{
"name": "init",
"image": "[parameters('init_container_image')]",
"resources": {
"cpu": 0.25,
"memory": "0.5Gi"
},
"volumeMounts": [
{
"mountPath": "/appsettings",
"volumeName": "appsettings-volume"
}
]
}
]
...
}
...
}
설정 | 설명 | 설명 |
---|---|---|
image |
컨테이너 앱의 컨테이너 이미지 이름입니다. | 이 값은 repository/<IMAGE_NAME>:<TAG> 형식을 사용합니다. |
name |
컨테이너의 식별 이름입니다. | 보고 및 식별에 사용됩니다. |
command |
컨테이너의 시작 명령입니다. | Docker의 entrypoint 필드와 동일합니다. |
args |
시작 명령 인수입니다. | 배열의 항목은 함께 조인되어 시작 명령에 전달할 매개 변수 목록을 만듭니다. |
env |
환경 변수를 정의하는 이름/값 쌍의 배열입니다. | 비밀을 참조하려면 value 필드 대신 secretRef 를 사용합니다. |
resources.cpu |
컨테이너에 할당되는 CPU 수입니다. | vCPU 및 메모리 할당 요구 사항을 참조하세요. |
resources.memory |
컨테이너에 할당되는 RAM 양입니다. | vCPU 및 메모리 할당 요구 사항을 참조하세요. |
volumeMounts |
볼륨 탑재 정의의 배열입니다. | 컨테이너에 대한 임시 또는 영구 스토리지 볼륨을 정의할 수 있습니다. 스토리지 볼륨에 대한 자세한 내용은 Azure Container Apps에서 스토리지 탑재 사용을 참조하세요. |
probes |
컨테이너에서 사용하도록 설정된 상태 프로브의 배열입니다. | 프로브 설정에 대한 자세한 내용은 Azure Container Apps의 상태 프로브를 참조하세요. |
vCPU 및 메모리 할당 요구 사항
사용량 플랜을 사용하는 경우 컨테이너 앱의 모든 컨테이너에 할당된 총 CPU 및 메모리는 다음 조합 중 하나에 도달해야 합니다.
vCPU(코어) | 메모리 |
---|---|
0.25 |
0.5Gi |
0.5 |
1.0Gi |
0.75 |
1.5Gi |
1.0 |
2.0Gi |
1.25 |
2.5Gi |
1.5 |
3.0Gi |
1.75 |
3.5Gi |
2.0 |
4.0Gi |
2.25 |
4.5Gi |
2.5 |
5.0Gi |
2.75 |
5.5Gi |
3.0 |
6.0Gi |
3.25 |
6.5Gi |
3.5 |
7.0Gi |
3.75 |
7.5Gi |
4.0 |
8.0Gi |
참고 항목
사용량 전용 환경에서 사용량 플랜을 사용하는 앱은 최대 2개의 코어와 4Gi 메모리로 제한됩니다.
여러 컨테이너
고급 시나리오에서는 단일 컨테이너 앱에서 여러 컨테이너를 실행할 수 있습니다. 컨테이너가 긴밀하게 결합된 특정 인스턴스에만 이 패턴을 사용합니다.
대부분의 마이크로 서비스 시나리오에서 가장 좋은 방법은 각 서비스를 별도의 컨테이너 앱으로 배포하는 것입니다.
동일한 컨테이너 앱에 있는 여러 컨테이너는 하드 디스크와 네트워크 리소스를 공유하며 동일한 애플리케이션 수명 주기를 경험합니다.
컨테이너 앱에서 추가 컨테이너를 실행하는 방법에는 사이드카 컨테이너와 init 컨테이너의 두 가지가 있습니다.
사이드카 컨테이너
단일 컨테이너 앱에서 여러 컨테이너를 정의하여 사이드카 패턴을 구현할 수 있습니다.
사이드카 컨테이너의 예는 다음과 같습니다.
공유 볼륨의 기본 앱 컨테이너에서 로그를 읽고 이를 로깅 서비스로 전달하는 에이전트입니다.
공유 볼륨의 기본 앱 컨테이너에서 사용하는 캐시를 새로 고치는 백그라운드 프로세스입니다.
이러한 시나리오는 예일 뿐 사이드카를 구현할 수 있는 유일한 방법을 나타내지는 않습니다.
컨테이너 앱에서 여러 컨테이너를 실행하려면 컨테이너 앱 템플릿의 containers
배열에 둘 이상의 컨테이너를 추가합니다.
init 컨테이너
컨테이너 앱에서 하나 이상의 init 컨테이너를 정의할 수 있습니다. init 컨테이너는 기본 앱 컨테이너보다 먼저 실행되며 데이터 다운로드 또는 환경 준비와 같은 초기화 작업을 수행하는 데 사용됩니다.
init 컨테이너는 컨테이너 앱 템플릿의 initContainers
배열에 정의됩니다. 컨테이너는 배열에 정의된 순서대로 실행되며 기본 앱 컨테이너가 시작되기 전에 성공적으로 완료되어야 합니다.
참고 항목
전용 플랜을 사용하거나 사용량 전용 환경에서 실행되는 앱의 init 컨테이너는 런타임에 관리 ID에 액세스할 수 없습니다.
컨테이너 레지스트리
Container Apps 구성에서 자격 증명을 제공하여 프라이빗 레지스트리에 호스트되는 이미지를 배포할 수 있습니다.
컨테이너 레지스트리를 사용하려면 컨테이너 앱 리소스 템플릿의 properties.configuration
섹션에 있는 registries
배열에서 레지스트리를 정의합니다. passwordSecretRef
필드는 암호를 정의한 secrets
배열 이름에서 비밀의 이름을 식별합니다.
{
...
"registries": [{
"server": "docker.io",
"username": "my-registry-user-name",
"passwordSecretRef": "my-password-secret-name"
}]
}
저장된 자격 증명은 앱이 배포될 때 프라이빗 레지스트리에서 컨테이너 이미지를 가져오는 데 사용됩니다.
다음 예제에서는 컨테이너 앱에서 Azure Container Registry 자격 증명을 구성하는 방법을 보여줍니다.
{
...
"configuration": {
"secrets": [
{
"name": "docker-hub-password",
"value": "my-docker-hub-password"
}
],
...
"registries": [
{
"server": "docker.io",
"username": "someuser",
"passwordSecretRef": "docker-hub-password"
}
]
}
}
참고 항목
Docker Hub는 Docker 이미지 다운로드 수를 제한합니다. 한도에 도달하면 앱의 컨테이너가 시작되지 않습니다. 이 문제를 방지하려면 Azure Container Registry와 같이 제한이 충분한 레지스트리를 사용합니다.
Azure Container Registry를 사용한 관리 ID
사용자 이름과 암호를 사용하는 대신 Azure 관리 ID를 사용하여 Azure Container Registry로 인증할 수 있습니다. 자세한 내용은 Azure Container Apps의 관리 ID를 참조하세요.
레지스트리에서 관리 ID를 사용하려면 앱에서 ID를 사용하도록 설정해야 하며 레지스트리에서 acrPull
역할이 할당되어야 합니다. 레지스트리를 구성하려면 사용자가 할당한 ID의 경우 관리 ID 리소스 ID를 사용하거나 레지스트리의 identity
속성에서 시스템이 할당한 ID의 경우 system
을 사용합니다. 관리 ID를 사용하는 경우 사용자 이름과 암호를 구성하지 마세요.
{
"identity": {
"type": "SystemAssigned,UserAssigned",
"userAssignedIdentities": {
"<IDENTITY1_RESOURCE_ID>": {}
}
}
"properties": {
"configuration": {
"registries": [
{
"server": "myacr1.azurecr.io",
"identity": "<IDENTITY1_RESOURCE_ID>"
},
{
"server": "myacr2.azurecr.io",
"identity": "system"
}]
}
...
}
}
사용자 할당 ID 구성에 대한 자세한 내용은 사용자 할당 ID 추가를 참조하세요.
제한 사항
Azure Container Apps의 제한 사항은 다음과 같습니다.
권한 있는 컨테이너: Azure Container Apps는 호스트 수준 액세스 권한이 있는 컨테이너 모드를 허용하지 않습니다.
운영 체제: Linux 기반(
linux/amd64
) 컨테이너 이미지가 필요합니다.최대 이미지 크기:
- 사용량 워크로드 프로필은 각 앱 또는 작업 복제본에 대해 최대 8GB의 컨테이너 이미지를 지원합니다.
- 전용 워크로드 프로필은 더 큰 컨테이너 이미지를 지원합니다. 전용 워크로드 프로필은 여러 앱 또는 작업을 실행할 수 있으므로 여러 컨테이너 이미지가 사용 가능한 디스크 공간을 공유합니다. 실제 지원되는 이미지 크기는 다른 앱 및 작업에서 사용하는 리소스에 따라 달라집니다.