Azure Container Apps의 컨테이너
Azure Container Apps는 Kubernetes 및 컨테이너 오케스트레이션의 세부 정보를 관리합니다. Azure Container Apps의 컨테이너는 사용자가 선택한 런타임, 프로그래밍 언어 또는 개발 스택을 사용할 수 있습니다.
Azure Container Apps는 다음을 지원합니다.
다음 기능도 포함됩니다.
template구성 섹션을 변경하면 새로운 컨테이너 앱 수정 버전이 트리거됩니다.- 컨테이너가 충돌하면 자동으로 다시 시작됩니다.
작업 기능은 다음과 같습니다.
- 작업 실행은
template구성 섹션을 사용하여 각 실행이 시작될 때 컨테이너 이미지와 기타 설정을 정의합니다. - 컨테이너가 0이 아닌 종료 코드로 종료되면 작업 실행이 실패한 것으로 표시됩니다. 실패한 실행을 다시 시도하도록 작업을 구성할 수 있습니다.
구성
다음 코드는 컨테이너 앱 리소스 템플릿의 properties.template 섹션에 있는 containers 배열의 예입니다. 발췌 내용은 컨테이너를 설정할 때 사용 가능한 구성 옵션을 보여줍니다.
{
"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 수입니다. | 소비 플랜에서 값은 다음 규칙을 준수해야 합니다. • 0보다 큼 • 2보다 작거나 같음 • 임의의 10진수일 수 있음(최대 소수점 이하 2자리) 예를 들어 1.25는 유효하지만 1.555는 유효하지 않습니다.기본값은 컨테이너당 CPU 0.25개입니다. Dedicated 계획에서 소비 워크로드 프로필을 사용하는 경우 CPU가 4보다 작거나 같아야 한다는 점을 제외하고 동일한 규칙이 적용됩니다. 전용 플랜을 사용하는 경우 최대 CPU는 컨테이너 앱이 실행되는 프로필에서 사용 가능한 코어 수보다 작거나 같아야 합니다. |
resources.memory |
컨테이너에 할당되는 RAM 양입니다. | 소비 플랜에서 값은 다음 규칙을 준수해야 합니다. • 0보다 큼 • 4Gi보다 작거나 같음• 임의의 10진수일 수 있음(최대 소수점 이하 2자리) 예를 들어 1.25Gi는 유효하지만 1.555Gi는 유효하지 않습니다.기본값은 컨테이너당 0.5Gi입니다.전용 플랜에서 사용량 워크로드를 사용하는 경우 메모리가 8Gi보다 작거나 같아야 한다는 점을 제외하고 동일한 규칙이 적용됩니다.Dedicated 계획을 사용하는 경우 최대 메모리는 컨테이너 앱이 실행되는 프로필에서 사용 가능한 메모리 양보다 작거나 같아야 합니다. |
volumeMounts |
볼륨 탑재 정의의 배열입니다. | 컨테이너에 대한 임시 볼륨 또는 여러 영구 스토리지 볼륨을 정의할 수 있습니다. 스토리지 볼륨에 대한 자세한 내용은 Azure Container Apps에서 스토리지 탑재 사용을 참조하세요. |
probes |
컨테이너에서 사용하도록 설정된 상태 프로브의 배열입니다. | 이 기능은 Kubernetes 상태 프로브를 기반으로 합니다. 프로브 설정에 대한 자세한 내용은 Azure Container Apps의 상태 프로브를 참조하세요. |
전용 플랜에서 사용량 계획 또는 사용량 워크로드를 사용하는 경우 컨테이너 앱의 모든 컨테이너에 대해 요청된 총 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 |
✔ |
모든 컨테이너의 총 CPU 요청은 vCPU 열의 값 중 하나와 일치해야 합니다.
모든 컨테이너의 총 메모리 요청은 CPU 열의 동일한 행에 있는 메모리 열의 메모리 값과 일치해야 합니다.
전용 플랜에서 사용량 프로필을 사용하는 경우 컨테이너 앱의 모든 컨테이너에 대해 요청된 총 CPU 및 메모리 할당은 프로필에서 사용량 가능한 코어 및 메모리보다 작거나 같아야 합니다.
여러 컨테이너
고급 시나리오에서는 단일 컨테이너 앱에서 여러 컨테이너를 실행할 수 있습니다. 컨테이너가 긴밀하게 결합된 특정 인스턴스에만 이 패턴을 사용합니다.
대부분의 마이크로 서비스 시나리오에서 가장 좋은 방법은 각 서비스를 별도의 컨테이너 앱으로 배포하는 것입니다.
동일한 컨테이너 앱에 있는 여러 컨테이너는 하드 디스크와 네트워크 리소스를 공유하며 동일한 애플리케이션 수명 주기를 경험합니다.
컨테이너 앱에서 여러 컨테이너를 실행하는 방법에는 사이드카 컨테이너와 init 컨테이너라는 두 가지 방법이 있습니다.
사이드카 컨테이너
단일 컨테이너 앱에서 여러 컨테이너를 정의하여 사이드카 패턴을 구현할 수 있습니다.
사이드카 컨테이너의 예는 다음과 같습니다.
공유 볼륨의 기본 앱 컨테이너에서 로그를 읽고 이를 로깅 서비스로 전달하는 에이전트입니다.
공유 볼륨의 기본 앱 컨테이너에서 사용하는 캐시를 새로 고치는 백그라운드 프로세스입니다.
이러한 시나리오는 예일 뿐 사이드카를 구현할 수 있는 유일한 방법을 나타내지는 않습니다.
컨테이너 앱에서 여러 컨테이너를 실행하려면 컨테이너 앱 템플릿의 containers 배열에 둘 이상의 컨테이너를 추가합니다.
init 컨테이너
컨테이너 앱에서 하나 이상의 init 컨테이너를 정의할 수 있습니다. init 컨테이너는 기본 앱 컨테이너보다 먼저 실행되며 데이터 다운로드 또는 환경 준비와 같은 초기화 작업을 수행하는 데 사용됩니다.
init 컨테이너는 컨테이너 앱 템플릿의 initContainers 배열에 정의됩니다. 컨테이너는 배열에 정의된 순서대로 실행되며 기본 앱 컨테이너가 시작되기 전에 성공적으로 완료되어야 합니다.
참고 항목
Init 컨테이너는 관리 ID를 사용한 이미지 가져오기를 지원하지만 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": "acr-password",
"value": "my-acr-password"
}
],
...
"registries": [
{
"server": "myacr.azurecr.io",
"username": "someuser",
"passwordSecretRef": "acr-password"
}
]
}
}
참고 항목
Docker Hub는 Docker 이미지 다운로드 수를 제한합니다. 한도에 도달하면 앱의 컨테이너가 시작되지 않습니다. 이 문제를 방지하려면 Azure Container Registry와 같이 제한이 충분한 레지스트리를 사용합니다.
Azure Container Registry를 사용한 관리 ID
사용자 이름과 암호를 사용하는 대신 Azure 관리 ID를 사용하여 Azure Container Registry로 인증할 수 있습니다. 자세한 내용은 Azure Container Apps의 관리 ID를 참조하세요.
관리 ID를 레지스트리에 할당할 때 사용자 할당 ID의 경우 관리 ID 리소스 ID를 사용하고 시스템 할당 ID의 경우 system을 사용합니다.
{
"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) 컨테이너 이미지가 필요합니다.