Развертывание приложений в Контейнеры приложений Azure с использованием Azure Developer CLI.

Интерфейс командной строки разработчика Azure (azd) поддерживает развертывание приложений контейнеров Azure и заданий приложений контейнеров Azure. Для приложений azd контейнеров Azure предлагает две стратегии развертывания:

• Стратегия на основе изображений. Отделяет обновления настроек конфигурации приложения-контейнера от развертываний образов.
• Стратегия на основе пересмотра. Объединяет оба в единое развертывание и поддерживает сложные модели развертывания.

В следующих разделах описаны обе стратегии, а также развертывание заданий приложений для контейнеров.

Развертывание в Container Apps express (предварительная версия)

azdподдерживает развертывания на основе образов для Контейнеры приложений Azure 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

В инфраструктуре создайте управляемую среду с properties.environmentMode заданным значением Express. Приложение-контейнер должно ссылаться на эту среду и включать тег azd-service-name, соответствующий имени службы в azure.yaml:

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

Определите ресурс Microsoft.App/containerApps с параметром environmentId, установленным в значение containerAppsEnvironment.id. Добавьте тег azd-service-name со значением web, чтобы оно соответствовало имени службы в azure.yaml.

Во время azdazd deploy обнаруживает экспресс-режим родительской среды и обновляет образ контейнера без настройки пользовательского суффикса редакции или весов трафика. Express автоматически выполняет скользящее обновление с одной ревизией.

Используйте стратегию развертывания на основе образов для Express. Стратегия на основе редакций не адаптирует Bicep развертывания для 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 и состоит из двух шагов:

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обновлять (обновлять, если существует, создавать, если нет) ресурс приложения-контейнера безопасно без проверок вручную.

   Подсказка

   Убедитесь, что apiVersion в azure.yaml выровнены с apiVersion модуля Bicep для Microsoft.App/containerApps, чтобы избежать несоответствий.

Стратегия развертывания на основе ревизий

В этой стратегии определение и образ приложения-контейнера развертываются вместе во время azd deploy.

• Конфигурация приложения контейнера находится в выделенном модуле Bicep , применяемом во время развертывания.

• Изменения переменных среды, изображений, ресурсов и параметров балансировки нагрузки развертываются в виде одной редакции.

  Подсказка

  Эта стратегия поддерживает сине-зеленый, канареечный и другие сложные шаблоны развертывания.

Настройка развертываний на основе версий

1. Определите параметры развертывания контейнерного приложения, создав файл инфраструктуры для вашей службы, например 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}': {}
       }
     }
   }
   

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 в момент развертывания

Запуск заданий для контейнерных приложений

Помимо контейнерных приложений, azd поддерживает развертывание заданий приложений контейнеров Azure (Microsoft.App/jobs). Задания приложений-контейнеров предназначены для задач, выполняемых до завершения, таких как пакетная обработка, запланированные задачи или работа на основе событий.

Замечание

Задания приложений контейнера используют тот же host: containerapp параметр в azure.yaml. Новый тип узла не требуется. Шаблон Bicep определяет, подготавливает ли azd контейнерное приложение или задачу контейнерного приложения на основе типа ресурса, который вы определяете.

Принцип работы

При обнаружении ресурса задания, помеченного тегом azd, azd-service-name:

1. Создает и отправляет образ Docker в реестр контейнеров Azure (так же, как и в приложениях контейнеров).
2. Обновляет образ контейнера задания, вызывая API заданий контейнеров вместо API приложений-контейнеров.
3. Возвращает пустые конечные точки, так как задания не имеют входа.

Настройка развертывания задания контейнерного приложения

1. Определите azure.yaml файл для службы обработки заданий. Использование host: containerapp и language: docker:

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

2. Создайте модуль Bicep, который подготавливает Microsoft.App/jobs ресурс. Пометьте ресурс так azd-service-name , чтобы azd его можно было обнаружить. Параметры и существующие ссылки на ресурсы (реестр контейнеров, управляемая среда, удостоверение) соответствуют тому же шаблону, что и приведенные выше примеры приложений контейнеров:

   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 связывает подготовленный ресурс с вашей службой.

3. Запустите azd up для настройки и развертывания. Интерфейс командной строки автоматически обнаруживает, что помеченный ресурс является заданием приложения-контейнера и обрабатывает развертывание соответствующим образом.

Основные отличия от контейнерных приложений

Аспект	Контейнерные приложения	Задания контейнерного приложения
Тип ресурса	Microsoft.App/containerApps	Microsoft.App/jobs
Вход/конечные точки	Поддержка входящего трафика HTTP	Нет входящего трафика (пустые конечные точки)
Модель выполнения	службы длительного действия	Задачи выполнения до завершения
Типы триггеров	Управляемое запросом	Ручное, запланированное или управляемое событиями
Параметр хоста в azure.yaml	host: containerapp	host: containerapp

Дополнительные ресурсы

• Общие сведения о приложениях контейнеров Azure
• Краткий обзор Контейнеры приложений Azure
• Общие сведения о заданиях в Контейнеры приложений Azure
• Справочник по Bicep для контейнерных приложений Azure
• Справочник по заданиям контейнерных приложений Azure Bicep
• Обзор .NET Aspire
• Шаблоны приложений Todo (использует образы)