Azure 개발자 CLI를 사용하여 Azure Container Apps에 배포

Azure 개발자 CLI(azd)는 Azure Container Apps 및 Azure Container App 작업 배포를 모두 지원합니다. Azure Container Apps의 azd 경우 두 가지 배포 전략을 제공합니다.

이미지 기반 전략. 컨테이너 앱 구성 업데이트를 이미지 배포와 구분합니다.
수정 기반 전략입니다. 둘 다 단일 배포로 결합하고 고급 롤아웃 패턴을 지원합니다.

다음 섹션에서는 컨테이너 앱 작업을 배포하는 방법과 함께 두 가지 전략을 설명합니다.

Container Apps Express에 배포 (미리 보기)

azd는 Azure Container Apps express(미리 보기)에 대한 이미지 기반 배포를 지원합니다. 기존 containerapp 호스트를 azure.yaml에서 사용합니다. express에 별도의 호스트 유형이 필요하지 않습니다.

중요합니다

Container Apps Express 지원을 사용하려면 azd 버전 1.35.0-beta.1 이상이 필요합니다.

services:
  web:
    host: containerapp
    image: mcr.microsoft.com/azuredocs/containerapps-helloworld:latest
    docker:
      imagePassthrough: true

인프라에서 Express를 properties.environmentMode(으)로 설정하여 관리형 환경을 만듭니다. 컨테이너 앱은 해당 환경을 참조하고 azure.yaml의 서비스 이름과 일치하는 azd-service-name 태그를 포함해야 합니다.

resource containerAppsEnvironment 'Microsoft.App/managedEnvironments@2026-07-01' = {
  name: 'cae-${environmentName}'
  location: location
  properties: {
    environmentMode: 'Express'
  }
}

environmentId를 containerAppsEnvironment.id로 설정한 Microsoft.App/containerApps 리소스를 정의합니다. azure.yaml의 서비스 이름과 일치하도록 값이 web인 azd-service-name 태그를 추가합니다.

azd 중에 azd deploy는 부모 환경의 익스프레스 모드를 검색하고 사용자 지정 수정 접미사 또는 트래픽 가중치를 설정하지 않고 컨테이너 이미지를 업데이트합니다. Express는 단일 리비전 롤링 업데이트를 자동으로 수행합니다.

Express용 이미지 기반 배포 전략을 사용합니다. 수정 버전 기반 전략은 배포 Bicep을 express용으로 조정하지 않으며, express는 여러 수정 버전 또는 트래픽 분할을 지원하지 않습니다. 인프라를 정의하기 전에 현재 Express 기능 가용성 및 제한 사항을 검토합니다.

이미지 기반 배포 전략

이 전략에서는 컨테이너 앱 구성 이 생성되고 업데이트 azd provision되는 동안 컨테이너 이미지가 업데이트 azd deploy됩니다.

컨테이너 앱 정의(리소스, 환경 변수, 상태 프로브 등)는 프로비전 중에 적용되는 Bicep 모듈 에 상주합니다.
배포하는 동안 컨테이너 이미지 참조(containers[0].image)만 변경됩니다.

수정 동작

앱 구성 또는 이미지에 대한 각 변경 내용은 새 수정 버전을 트리거합니다.

Step	Command	변경 내용을 적용합니다.	비고
1	`azd provision`	환경 변수, 리소스, 탑재, 프로브, 부하 분산 장치	새 수정 버전을 만듭니다.
2	`azd deploy`	컨테이너 이미지	다른 수정 버전을 만듭니다.

각 수정 버전에서는 컨테이너 앱 환경에 추가 복제본을 할당하므로 리소스 사용량과 비용이 일시적으로 증가할 수 있습니다.

비고

파란색-녹색 또는 카나리아와 같은 고급 롤아웃 패턴은 이 전략에서 지원되지 않습니다.

이미지 기반 배포 구성

azd provision 배포된 최신 이미지를 덮어쓰지 않고 기존 컨테이너 앱을 업데이트하려면 upsert 작업을 수행합니다. 이 패턴은 AVM container-app-upsert 모듈에서 구현되며 다음 두 단계로 구성됩니다.

main.parameters.json에, azd 제공 변수를 참조하는 매개변수 SERVICE_{NAME}_RESOURCE_EXISTS를 정의합니다. 이 변수는 프로비전 시 리소스가 이미 존재하는지 여부를 나타내기 위해 자동으로 azd 설정됩니다.

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "environmentName": {
      "value": "${AZURE_ENV_NAME}"
    },
    "location": {
      "value": "${AZURE_LOCATION}"
    },
    // ... other parameters
    "apiExists": {
      "value": "${SERVICE_API_RESOURCE_EXISTS}"
    }
  }
}

Bicep 파일에서 매개 변수를 exists 참조하여 컨테이너 앱을 만들거나 업데이트해야 하는지 여부를 제어합니다. 모듈은 container-app-upsert 내부적으로 이 논리를 캡슐화합니다.

@description('Indicates whether the container app resource already exists.')
param apiExists bool

module api 'br/public:avm/ptn/azd/container-app-upsert:0.1.2' = {
  name: 'api'
  params: {
    name: 'my-api'
    location: location
    containerAppsEnvironmentName: containerAppsEnvironment.name
    containerRegistryName: containerRegistry.name
    imageName: !empty(apiImageName) ? apiImageName : ''
    exists: apiExists
    env: [
      {
        name: 'MONGODB_CONNECTION_STRING'
        value: mongodb.outputs.connectionString
      }
    ]
    targetPort: 3100
  }
}

이 방법을 사용하면 azd provision 수동 검사 없이 컨테이너 앱 리소스를 안전하게 upsert (존재하는 경우 업데이트, 생성하지 않을 경우 만들기)할 수 있습니다.

팁 (조언)

apiVersion을 azure.yaml에서 Bicep 모듈의 apiVersion에 맞춰 Microsoft.App/containerApps 간 불일치를 방지하세요.

수정 기반 배포 전략

이 전략에서는 컨테이너 앱 정의와 이미지가 azd deploy같이 배치됩니다.

컨테이너 앱 구성은 배포 중에 적용되는 전용 Bicep 모듈 에 상주합니다.
환경 변수, 이미지, 리소스 및 부하 분산 설정에 대한 변경 내용은 단일 수정 버전으로 롤아웃됩니다.

팁 (조언)

이 전략은 청록색, 카나리아 및 기타 고급 출시 패턴을 지원합니다.

수정 버전 기반 배포 구성

서비스에 대한 인프라 파일(예: infra/api.bicep.)을 만들어 컨테이너 앱 배포를 정의합니다. AVM 기반 모듈을 사용하거나 리소스를 직접 정의하여 컨테이너 앱을 정의할 수 있습니다.

AVM 모듈
직접 바이셉 리소스

@description('Unique environment name used for resource naming.')
param environmentName string

@description('Primary location for all resources.')
param location string

param containerRegistryName string
param containerAppsEnvironmentName string
param imageName string
param identityId string

resource containerRegistry 'Microsoft.ContainerRegistry/registries@2023-01-01-preview' existing = {
  name: containerRegistryName
}

resource containerAppsEnvironment 'Microsoft.App/managedEnvironments@2022-03-01' existing = {
  name: containerAppsEnvironmentName
}

module api 'br/public:avm/res/app/container-app:0.8.0' = {
  name: 'api'
  params: {
    name: 'api'
    ingressTargetPort: 80
    scaleMinReplicas: 1
    scaleMaxReplicas: 10
    containers: [
      {
        name: 'main'
        image: imageName
        resources: {
          cpu: json('0.5')
          memory: '1.0Gi'
        }
      }
    ]
    managedIdentities: {
      systemAssigned: false
      userAssignedResourceIds: [identityId]
    }
    registries: [
      {
        server: containerRegistry.properties.loginServer
        identity: identityId
      }
    ]
    environmentResourceId: containerAppsEnvironment.id
    location: location
    tags: {
      'azd-env-name': environmentName
      'azd-service-name': 'api'
    }
  }
}

AVM 모듈을 사용하지 않으려는 경우 컨테이너 앱 리소스를 직접 정의할 수 있습니다.

@description('Unique environment name used for resource naming.')
param environmentName string

@description('Primary location for all resources.')
param location string

param containerRegistryName string
param containerAppsEnvironmentName string
param imageName string
param identityId string

resource containerRegistry 'Microsoft.ContainerRegistry/registries@2023-01-01-preview' existing = {
  name: containerRegistryName
}

resource containerAppsEnvironment 'Microsoft.App/managedEnvironments@2022-03-01' existing = {
  name: containerAppsEnvironmentName
}

resource api 'Microsoft.App/containerApps@2025-02-02-preview' = {
  name: 'api'
  location: location
  tags: {
    'azd-env-name': environmentName
    'azd-service-name': 'api'
  }
  properties: {
    environmentId: containerAppsEnvironment.id
    configuration: {
      ingress: {
        external: true
        targetPort: 8080
        transport: 'http'
      }
      registries: [
        {
          server: containerRegistry.properties.loginServer
          identity: identityId
        }
      ]
      activeRevisionsMode: 'Single'
    }
    template: {
      containers: [
        {
          image: imageName
          name: 'main'
          resources: {
            cpu: json('0.5')
            memory: '1.0Gi'
          }
        }
      ]
      scale: {
        minReplicas: 1
        maxReplicas: 10
      }
    }
  }
  identity: {
    type: 'UserAssigned'
    userAssignedIdentities: {
      '${identityId}': {}
    }
  }
}

매개 변수 파일(예: )을 만들어 배포 시 매개 변수를 제공합니다. api.parameters.json

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "environmentName": { "value": "${AZURE_ENV_NAME}" },
    "location": { "value": "${AZURE_LOCATION}" },
    "containerRegistryName": { "value": "${AZURE_CONTAINER_REGISTRY_NAME}" },
    "containerAppsEnvironmentName": { "value": "${AZURE_CONTAINER_ENVIRONMENT_NAME}" },
    "imageName": { "value": "${SERVICE_API_IMAGE_NAME}" },
    "identityId": { "value": "${SERVICE_API_IDENTITY_ID}" }
  }
}

비고

SERVICE_API_IMAGE_NAME 는 배포 중에 동적으로 설정되며 프로비전 출력의 일부가 아닙니다.

실행 azd deploy하면 위의 리소스 정의를 사용하여 컨테이너 앱 수정 버전이 적용됩니다.

팁 (조언)

컨테이너 앱이 프로비전된 다른 리소스를 참조하는 경우, azd provision의 추가 출력 값을 azd deploy에 매개 변수로 전달합니다.

비교 요약

측면	이미지 기반	수정 버전 기반
업데이트 명령	`azd provision` + `azd deploy`	`azd deploy`에만 해당
배포 유형	두 개의 수정 버전	단일 수정
롤아웃 제어	관리됨 `azd`	구성 가능(파란색-녹색, 카나리아)
사용 사례	간단한 환경	최첨단 배포
컨테이너 앱 정의 위치	프로비전 시간 Bicep	배포 시간 Bicep

컨테이너 앱 작업 배포

Container Apps azd 외에도 Azure 컨테이너 앱 잡(Microsoft.App/jobs)의 배포를 지원합니다. 컨테이너 앱 작업은 일괄 처리, 예약된 작업 또는 이벤트 기반 작업과 같이 완료될 때 실행되는 작업을 위해 설계되었습니다.

비고

컨테이너 앱 작업은 host: containerapp에서 동일한 azure.yaml 설정을 사용합니다. 새 호스트 유형이 필요하지 않습니다. Bicep 템플릿은 정의한 리소스 종류에 따라 컨테이너 앱 또는 컨테이너 앱 작업을 프로비전할지 여부를 azd 결정합니다.

작동 방식

azd 태그azd-service-name가 지정된 작업 리소스를 검색하면 다음을 수행합니다.

Docker 이미지를 빌드하고 Azure Container Registry에 푸시합니다(Container Apps와 동일).
Container Apps API 대신 컨테이너 앱 작업 API를 호출하여 작업의 컨테이너 이미지를 업데이트합니다.
작업에 인그레스가 없으므로 빈 엔드포인트를 반환합니다.

컨테이너 앱 작업 배포 구성

작업 서비스에 사용할 azure.yaml 파일을 정의합니다. host: containerapp 및 language: docker를 사용하십시오:

name: myapp
services:
  job:
    host: containerapp
    language: docker
    project: ./src/job
    docker:
      path: ./Dockerfile
      context: .

Microsoft.App/jobs 리소스를 프로비전하는 Bicep 모듈을 구축합니다. 리소스에 azd-service-name 태그를 지정하여 azd에서 검색할 수 있도록 하십시오. 매개 변수 및 기존 리소스 참조(컨테이너 레지스트리, 관리되는 환경, ID)는 위의 Container Apps 예제와 동일한 패턴을 따릅니다.

resource job 'Microsoft.App/jobs@2025-02-02-preview' = {
  name: 'job'
  location: location
  tags: {
    'azd-env-name': environmentName
    'azd-service-name': 'job'
  }
  properties: {
    environmentId: containerAppsEnvironment.id
    configuration: {
      replicaTimeout: 300
      replicaRetryLimit: 1
      triggerType: 'Manual'
      registries: [
        {
          server: containerRegistry.properties.loginServer
          identity: identityId
        }
      ]
    }
    template: {
      containers: [
        {
          image: imageName
          name: 'main'
          resources: {
            cpu: json('0.5')
            memory: '1.0Gi'
          }
        }
      ]
    }
  }
  identity: {
    type: 'UserAssigned'
    userAssignedIdentities: {
      '${identityId}': {}
    }
  }
}

중요합니다

태그 값은 azd-service-name 파일의 서비스 이름과 azure.yaml 일치해야 합니다. 이 태그는 프로비전된 리소스를 서비스와 연결하는 방법입니다 azd .

azd up을(를) 실행하여 프로비전 및 배포합니다. CLI는 태그가 지정된 리소스가 컨테이너 앱 작업임을 자동으로 감지하고 그에 따라 배포를 처리합니다.

Container Apps의 주요 차이점

측면	컨테이너 앱	컨테이너 응용 프로그램 작업
리소스 유형	`Microsoft.App/containerApps`	`Microsoft.App/jobs`
인그레스/엔드포인트	HTTP 인그레스 지원	인그레스 없음(비어 있는 엔드포인트)
실행 모델	장기 실행 서비스	실행-완료 작업
트리거 유형	요청 기반	수동, 예약 또는 이벤트 기반
호스트 설정 `azure.yaml`	`host: containerapp`	`host: containerapp`

추가 리소스

피드백

이 페이지가 도움이 되었나요?

2026-10-01 에 마지막으로 업데이트됨