다음을 통해 공유

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

Azure 개발자 CLI(azd)는 Azure Container Apps에 대한 두 가지 배포 전략을 지원합니다.

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

다음 섹션에서는 두 가지 전략을 모두 설명합니다.

이미지 기반 배포 전략

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

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

수정 동작

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

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

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

비고

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

이미지 기반 배포 구성

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

  1. 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}"
    }
  }
}

  2. 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 모듈 에 상주합니다.

  • 환경 변수, 이미지, 리소스 및 부하 분산 설정에 대한 변경 내용은 단일 수정 버전으로 롤아웃됩니다.

    팁 (조언)

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

수정 버전 기반 배포 구성

  1. 서비스에 대한 인프라 파일(예: infra/api.bicep.)을 만들어 컨테이너 앱 배포를 정의합니다. 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'
    }
  }
}

  2. 매개 변수 파일(예: )을 만들어 배포 시 매개 변수를 제공합니다. 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

추가 리소스

  • Last updated on