Distribuire su Azure Container Apps utilizzando l'Azure Developer CLI

L'interfaccia della riga di comando per sviluppatori di Azure (azd) supporta la distribuzione sia delle app contenitore di Azure che dei processi dell'app Azure Container. Per le app contenitore di Azure, azd offre due strategie di distribuzione:

• Strategia basata su immagini. Separa gli aggiornamenti della configurazione dell'app contenitore dalle distribuzioni di immagini.
• Strategia basata sulle revisioni. Combina entrambi in un'unica distribuzione e supporta modelli di distribuzione avanzati.

Le sezioni seguenti illustrano entrambe le strategie, oltre a spiegare come distribuire i processi di lavoro delle app contenitore.

Strategia di distribuzione basata su immagini

In questa strategia, la configurazione dell'app contenitore viene creata e aggiornata durante azd provision, mentre l'immagine del contenitore viene aggiornata durante azd deploy.

• La definizione dell'app contenitore (risorse, variabili di ambiente, probe di integrità e così via) risiede in un modulo Bicep applicato durante il provisioning.
• Solo il riferimento all'immagine del contenitore (containers[0].image) cambia durante la distribuzione.

Comportamento della revisione

Ogni modifica alla configurazione dell'app o all'immagine attiva una nuova revisione:

Ogni revisione alloca repliche aggiuntive nell'ambiente Container Apps, che potrebbero aumentare temporaneamente l'utilizzo e i costi delle risorse.

Configurare distribuzioni basate su immagini

Per assicurarsi che azd provision aggiorni un'app contenitore esistente senza sovrascrivere l'immagine distribuita più recente, eseguire un'operazione upsert . Questo modello viene implementato dal modulo AVM container-app-upsert ed è costituito da due passaggi:

1. Definisci un parametro che fa riferimento alla variabile fornita da azd. Questa variabile viene impostata automaticamente da azd al momento del provisioning per indicare se la risorsa esiste già.

   {
     "$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. Nel file Bicep fare riferimento al exists parametro per controllare se l'app contenitore deve essere creata o aggiornata. Il container-app-upsert modulo incapsula internamente questa logica.

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

   Questo approccio consente di azd provisioneffettuare un'operazione di upsert (aggiornamento se esistente, creare se non esiste) sulla risorsa dell'app contenitore in modo sicuro senza controlli manuali.

   Suggerimento

   Mantenere l'oggetto apiVersion in azure.yaml linea con il modulo apiVersion Bicep per Microsoft.App/containerApps evitare mancate corrispondenze.

Strategia di distribuzione basata sulle revisioni

In questa strategia, sia la definizione dell'app contenitore che l'immagine vengono distribuite insieme durante azd deploy.

• La configurazione dell'app contenitore risiede in un modulo Bicep dedicato applicato durante la distribuzione.

• Le modifiche alle variabili di ambiente, alle immagini, alle risorse e alle impostazioni di bilanciamento del carico vengono implementate come singola revisione.

  Suggerimento

  Questa strategia supporta i modelli blu-verde, canarino e altri modelli di implementazione avanzati.

Configurare distribuzioni basate su revisione

1. Definire la distribuzione dell'app contenitore creando un file infra per il servizio, ad esempio infra/api.bicep. È possibile definire l'app contenitore usando il modulo basato su AVM o definendo direttamente la risorsa:

   • Modulo AVM
   • Risorsa Bicep diretta

   @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. Specificare i parametri in fase di distribuzione creando un file di parametri ,ad esempio 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}" }
     }
   }
   

   Annotazioni

   SERVICE_API_IMAGE_NAME viene impostato in modo dinamico durante la distribuzione e non fa parte degli output di provisioning.

   Quando si esegue azd deploy, la revisione dell'app contenitore viene applicata usando la definizione di risorsa precedente.

   Suggerimento

   Passa eventuali output aggiuntivi da azd provision come parametri a azd deploy se l'app contenitore fa riferimento ad altre risorse provisionate.

Riepilogo del confronto

Distribuire operazioni app per contenitori

Oltre alle app contenitore, azd supporta la distribuzione di processi dell'app Azure Container (Microsoft.App/jobs). I processi dell'app contenitore sono progettati per attività eseguite fino al completamento, ad esempio l'elaborazione batch, le attività pianificate o il lavoro basato su eventi.

Come funziona

Quando azd individua una risorsa di lavoro contrassegnata con azd-service-name, esso:

1. Compila e carica l'immagine Docker nel Registro Azure Container (come Container Apps).
2. Aggiorna l'immagine del container del job utilizzando l'API dei lavori delle app container invece dell'API delle app container.
3. Restituisce endpoint vuoti, perché i processi non dispongono di ingresso.

Configurare la distribuzione di un'operazione per l'app contenitore

1. Definisci il file per il azure.yaml servizio di lavoro. Usare host: containerapp e language: docker:

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

2. Creare un modulo Bicep che configuri una risorsa Microsoft.App/jobs. Contrassegna la risorsa con azd-service-name in modo da azd poterla individuare. I parametri e i riferimenti alle risorse esistenti (registro contenitori, ambiente gestito, identità) seguono lo stesso modello degli esempi di App contenitore precedenti:

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

   Importante

   Il valore del azd-service-name tag deve corrispondere al nome del servizio nel azure.yaml file. Questo tag è il modo in cui azd associa la risorsa approvvigionata al tuo servizio.

3. Eseguire azd up per effettuare il provisioning e la distribuzione. Il CLI rileva automaticamente che la risorsa contrassegnata è un'attività dell'app container e gestisce la distribuzione di conseguenza.

Differenze principali rispetto alle applicazioni container

Risorse aggiuntive

• Panoramica delle app di Azure Container
• Panoramica dei lavori di Azure Container Apps
• Informazioni di riferimento su Bicep per app contenitore di Azure
• Riferimento Bicep per i Jobs di Azure Container App
• Panoramica di .NET Aspire
• Modelli di applicazione Todo (usa immagini)