Déployer sur Azure Container Apps à l’aide d’Azure Developer CLI

Azure Developer CLI (azd) prend en charge le déploiement des Azure Container Apps et des Azure Container App Jobs. Pour Azure Container Apps, azd propose deux stratégies de déploiement :

  • Stratégie basée sur l’image. Sépare les mises à jour de configuration des applications conteneur des déploiements d’images.
  • Stratégie basée sur la révision. Combine les deux en un seul déploiement et prend en charge les modèles de déploiement avancés.

Les sections suivantes présentent les deux stratégies, ainsi que la procédure de déploiement des Container App Jobs.

Déployer sur Container Apps express (préversion)

azdprend en charge les déploiements basés sur des images pour Azure Container Apps express (préversion). Utilisez l’hôte existant containerapp dans azure.yaml; vous n’avez pas besoin d’un type d’hôte distinct pour express :

Important

La prise en charge simplifiée de Container Apps nécessite la version 1.35.0-beta.1 ou ultérieure de azd.

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

Dans votre infrastructure, créez un environnement managé avec properties.environmentMode défini sur Express. L’application conteneur doit référencer cet environnement et inclure une azd-service-name balise qui correspond au nom du service dans azure.yaml:

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

Définissez la ressource environmentId avec Microsoft.App/containerApps défini sur containerAppsEnvironment.id. Ajoutez une azd-service-name balise avec la valeur web pour qu’elle corresponde au nom du service dans azure.yaml.

Pendant azd deploy, azd détecte le mode express de l’environnement parent et met à jour l’image conteneur sans définir un suffixe de révision personnalisé ou des pondérations de trafic. Express effectue automatiquement une mise à jour progressive sur une seule révision.

Utilisez la stratégie de déploiement basée sur l’image pour Express. La stratégie basée sur la révision n'adapte pas votre fichier Bicep de déploiement pour express, et express ne prend pas en charge plusieurs révisions ni le fractionnement du trafic. Avant de définir votre infrastructure, passez en revue la disponibilité et les limitations actuelles des fonctionnalités express.

Stratégie de déploiement basée sur l’image

Dans cette stratégie, la configuration de l’application conteneur est créée et mise à jour pendant azd provision, tandis que l’image conteneur est mise à jour pendant azd deploy.

  • La définition de l’application conteneur (ressources, variables d’environnement, sondes d’intégrité, et ainsi de suite) réside dans un module Bicep appliqué lors de l’approvisionnement.
  • Seule la référence d’image conteneur (containers[0].image) change pendant le déploiement.

Comportement de révision

Chaque modification apportée à la configuration de l’application ou à l’image déclenche une nouvelle révision :

Étape Command Applique les modifications à Remarques
1 azd provision Variables d’environnement, ressources, montages, sondes, équilibreurs de charge Crée une révision
2 azd deploy Image conteneur Crée une autre révision

Chaque révision alloue des réplicas supplémentaires dans l’environnement Container Apps, ce qui peut temporairement augmenter l’utilisation des ressources et les coûts.

Note

Les modèles de déploiement avancés, tels que blue-green ou canary, ne sont pas pris en charge dans cette stratégie.

Configurer des déploiements basés sur des images

Pour garantir que l'application conteneur existante azd provision soit mise à jour sans écraser la dernière image déployée, effectuez une opération upsert. Ce modèle est implémenté par le module AVM container-app-upsert et se compose de deux étapes :

  1. Dans votre main.parameters.json, définissez un paramètre qui fait référence à la variable SERVICE_{NAME}_RESOURCE_EXISTSfournie par azd . Cette variable est définie automatiquement azd au moment de l’approvisionnement pour indiquer si la ressource existe déjà.

    {
  "$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. Dans votre fichier Bicep, référencez le exists paramètre pour contrôler si l’application conteneur doit être créée ou mise à jour. Le container-app-upsert module encapsule cette logique en interne.

    @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
  }
}

    Cette approche permet à azd provision d'effectuer un upsert (mettre à jour si la ressource existe, la créer dans le cas contraire) la ressource Container App en toute sécurité, sans vérifications manuelles.

    Conseil / Astuce

    Veillez à ce que le apiVersion dans azure.yaml corresponde à la valeur apiVersion du module Bicep pour Microsoft.App/containerApps afin d’éviter toute incohérence.

Stratégie de déploiement basée sur la révision

Dans cette stratégie, la définition et l’image de l’application conteneur sont déployées ensemble pendant azd deploy.

  • La configuration de l’application conteneur réside dans un module Bicep dédié appliqué pendant le déploiement.

  • Les modifications apportées aux variables d’environnement, aux images, aux ressources et aux paramètres d’équilibrage de charge sont déployées en tant que révision unique.

    Conseil / Astuce

    Cette stratégie prend en charge les modèles de déploiement bleu-vert, canary et autres modèles de déploiement avancés.

Configurer des déploiements basés sur le contrôle de version

  1. Définissez le déploiement de l’application conteneur en créant un fichier d'infrastructure pour votre service, par exemple infra/api.bicep. Vous pouvez définir votre application conteneur à l’aide du module basé sur AVM ou en définissant directement la ressource :

    @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. Fournissez des paramètres au moment du déploiement en créant un fichier de paramètres (par exemple 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}" }
  }
}

    Note

    SERVICE_API_IMAGE_NAME est défini dynamiquement pendant le déploiement et ne fait pas partie des sorties de provisionnement.

    Lorsque vous exécutez azd deploy, la révision de l’application conteneur est appliquée à l’aide de la définition de ressource ci-dessus.

    Conseil / Astuce

    Transmettez toutes les sorties supplémentaires de azd provision en tant que paramètres à azd deploy si votre application conteneur référence d'autres ressources approvisionnées.

Résumé de comparaison

Aspect Basé sur l’image Basé sur la révision
Commande Mettre à jour azd provision + azd deploy azd deploy uniquement
Type de déploiement Deux révisions Révision unique
Contrôle de déploiement Géré par azd Configurable (bleu-vert, canari)
Cas d’utilisation Environnements simples Déploiements avancés
Emplacement de la définition de la Container App Bicep lors du provisionnement Bicep lors du déploiement

Déployer des Container App Jobs

En plus de Container Apps, azd permet de déployer des jobs Azure Container App (Microsoft.App/jobs). Les Container App Jobs sont conçus pour les tâches qui s’exécutent jusqu’à leur terme, comme le traitement par lots, les tâches planifiées ou les traitements déclenchés par des événements.

Note

Les Container App Jobs utilisent le même paramètre host: containerapp dans azure.yaml. Aucun nouveau type d’hôte n’est requis. Le modèle Bicep détermine si azd provisionne une Container App ou un Container App Job en fonction du type de ressource que vous définissez.

Fonctionnement

Lorsque azd découvre une ressource de travail marquée avec azd-service-name, il :

  1. Génère et envoie (push) l’image Docker à Azure Container Registry (identique à Container Apps).
  2. Met à jour l’image conteneur du job en appelant l’API Container App Jobs plutôt que l’API Container Apps.
  3. Retourne des points de terminaison vides, car les jobs ne disposent d’aucun point d’entrée.

Configurer un déploiement de tâche d’application conteneurisée

  1. Définissez le azure.yaml fichier de votre service de travail. Utiliser host: containerapp et language: docker:

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

  2. Créez un module Bicep qui provisionne une Microsoft.App/jobs ressource. Étiquetez la ressource avec azd-service-name afin que azd puisse la découvrir. Les paramètres et les références de ressources existantes (registre de conteneurs, environnement managé, identité) suivent le même modèle que les exemples Container Apps ci-dessus :

    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}': {}
    }
  }
}

    Important

    La azd-service-name valeur de balise doit correspondre au nom du service dans votre azure.yaml fichier. Cette balise explique comment azd associer la ressource provisionnée à votre service.

  3. Exécutez azd up pour provisionner et déployer. L’interface CLI détecte automatiquement que la ressource étiquetée est un travail d’application conteneur et gère le déploiement en conséquence.

Principales différences par rapport à Container Apps

Aspect Container Apps Container App Jobs
Type de ressource Microsoft.App/containerApps Microsoft.App/jobs
Entrée/points de terminaison Prend en charge l’entrée HTTP Aucune entrée (points de terminaison vides)
Modèle d’exécution Services fonctionnant sur de longues périodes Tâches jusqu'à achèvement
Types de déclencheurs Sur demande Manuel, planifié ou piloté par les événements
Paramètre d’hôte dans azure.yaml host: containerapp host: containerapp

Ressources supplémentaires

  • Dernière mise à jour :