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

Azure Developer CLI (azd) prend en charge deux stratégies de déploiement pour Azure Container Apps :

• 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 expliquent les deux stratégies.

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 :

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

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 provisiond'effectuer un upsert (mettre à jour s’il existe, créer si ce n’est pas le cas) sur la ressource d'application conteneur en toute sécurité sans vérifications manuelles.

   Conseil / Astuce

   Maintenez apiVersion dans azure.yaml aligné avec le module Bicep apiVersion pour Microsoft.App/containerApps éviter les décalages.

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 :

   • Module AVM
   • Ressource bicep directe

   @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

Ressources supplémentaires

• Vue d’ensemble d’Azure Container Apps
• Informations de référence sur Azure Container Apps Bicep
• Vue d’ensemble de .NET Aspire
• Modèles d’application todo (utilise des images)