Distribuera till Azure Container Apps med hjälp av Azure Developer CLI

Azure Developer CLI (azd) stöder distribution av både Azure Container Apps och Azure Container App Jobs. För Azure Container Apps azd erbjuder två distributionsstrategier:

  • Bildbaserad strategi. Skiljer konfigurationsuppdateringar för containerappar från bilddistributioner.
  • Revisionsbaserad strategi. Kombinerar båda i en enda distribution och har stöd för avancerade distributionsmönster.

I följande avsnitt beskrivs båda strategierna, tillsammans med hur du distribuerar containerappjobb.

Avbildningsbaserad distributionsstrategi

I den här strategin skapas och uppdateras konfigurationen av containerappen under azd provision, medan containeravbildningen uppdateras under azd deploy.

  • Definitionen av containerappen (resurser, miljövariabler, hälsoavsökningar och så vidare) finns i en Bicep-modul som tillämpas under provisionering.
  • Endast containeravbildningsreferensen (containers[0].image) ändras under distributionen.

Revisionsbeteende

Varje ändring av appkonfigurationen eller avbildningen utlöser en ny revision:

Step Befallning Tillämpar ändringar på Noteringar
1 azd provision Miljövariabler, resurser, databindningar, prober, belastningsbalanserare Skapar en ny revision
2 azd deploy Containeravbildning Skapar en annan revision

Varje revision allokerar ytterligare repliker i Container Apps-miljön, vilket tillfälligt kan öka resursanvändningen och kostnaden.

Anmärkning

Avancerade distributionsmönster, till exempel blågröna eller kanariefågel, stöds inte i den här strategin.

Konfigurera avbildningsbaserade distributioner

Utför en azd provision på en befintlig containerapp för att säkerställa att den uppdateras utan att den senaste distribuerade imagen skrivs över. Det här mönstret implementeras av AVM-modulen container-app-upsert och består av två steg:

  1. I din main.parameters.json definierar du en parameter som refererar till den azd-tillhandahållna variabeln SERVICE_{NAME}_RESOURCE_EXISTS. Den här variabeln anges automatiskt vid azd etableringstillfället för att ange om resursen redan finns.

    {
  "$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. I Bicep-filen refererar du till parametern exists för att styra om containerappen ska skapas eller uppdateras. Modulen container-app-upsert kapslar in denna logik internt.

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

    Med den här metoden kan azd provisiondu uppdatera (uppdatera om det finns, skapa om inte) containerappresursen på ett säkert sätt utan manuella kontroller.

    Tips/Råd

    Håll apiVersion i linje med azure.yaml i Bicep-modulen apiVersion för att undvika felaktiga matchningar.

Revisionsbaserad distributionsstrategi

I den här strategin distribueras både definitionen av containerappen och avbildningen tillsammans under azd deploy.

  • Konfigurationen av containerappen finns i en dedikerad Bicep-modul som tillämpas under distributionen.

  • Ändringar i miljövariabler, bilder, resurser och belastningsutjämningsinställningar distribueras som en enskild revision.

    Tips/Råd

    Den här strategin stöder blå/grön, kanari och andra avancerade distributionsmönster.

Konfigurera revisionsbaserade distributioner

  1. Definiera distributionen av containerappen genom att skapa en infrafil för tjänsten, till exempel infra/api.bicep. Du kan definiera din containerapp med hjälp av den AVM-baserade modulen eller genom att definiera resursen direkt:

    @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. Ange parametrar vid distributionstillfället genom att skapa en parameterfil (t.ex. 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}" }
  }
}

    Anmärkning

    SERVICE_API_IMAGE_NAME anges dynamiskt under utplaceringen och ingår inte i provisionens resultat.

    När du kör azd deploytillämpas containerappens revision med hjälp av resursdefinitionen ovan.

    Tips/Råd

    Skicka eventuella ytterligare utdata från azd provision som parametrar till azd deploy om din containerapp refererar till andra etablerade resurser.

Jämförelsesammanfattning

Aspekt Bildbaserad Revisionsbaserad
Kommandot Uppdatera azd provision + azd deploy azd deploy bara
Distributionstyp Två revisioner Enkel revision
Distributionskontroll Hanteras av azd Konfigurerbar (blågrön, kanariefågel)
Användningsfall Enkla miljöer Avancerade implementeringar
Containerappens definitionsplats Provisionstid Bicep Bicep vid distributionstid

Distribuera containerapp-jobb

Förutom Container Apps har azd stöd för distribution av Azure Container App Jobs (Microsoft.App/jobs). Container App-jobb är utformade för aktiviteter som körs till slutförande, till exempel batchbearbetning, schemalagda uppgifter eller händelsedrivet arbete.

Anmärkning

Container App Jobs använder samma host: containerapp inställning i azure.yaml. Ingen ny värdtyp krävs. Bicep-mallen avgör om azd etablerar en containerapp eller ett containerappjobb baserat på den resurstyp som du definierar.

Så här fungerar det

När azd identifierar en jobbresurs taggad med azd-service-name, det:

  1. Skapar och push-överför Docker-avbildningen till Azure Container Registry (samma som Container Apps).
  2. Uppdaterar jobbets containeravbildning genom att anropa Container App Jobs API istället för Container Apps API.
  3. Returnerar tomma slutpunkter eftersom jobben inte har någon ingångspunkt.

Konfigurera distributionen av ett containerappsjobb

  1. Definiera azure.yaml-filen för din tjänst. Använd host: containerapp och language: docker:

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

  2. Skapa en Bicep-modul som tillhandahåller en Microsoft.App/jobs resurs. Tagga resursen med azd-service-name så azd att den kan identifieras. Parametrarna och befintliga resursreferenser (containerregister, hanterad miljö, identitet) följer samma mönster som containerappexemplen ovan:

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

    Viktigt!

    Taggvärdet azd-service-name måste matcha tjänstnamnet i azure.yaml filen. Den här taggen associerar azd den etablerade resursen med din tjänst.

  3. Kör azd up för att förbereda och distribuera. CLI identifierar automatiskt att den taggade resursen är ett containerappjobb och hanterar distributionen därefter.

Viktiga skillnader från Container Apps

Aspekt Containerapplikationer ContainerApp-jobb
Resurstyp Microsoft.App/containerApps Microsoft.App/jobs
Ingress/slutpunkter Stöder HTTP-ingång Inga ingresser (tomma slutpunkter)
Körningsmodell Långvariga tjänster Aktiviteter för körning till slutförande
Utlösartyper Förfrågestyrd Manuell, schemalagd eller händelsedriven
Värdinställning i azure.yaml host: containerapp host: containerapp

Ytterligare resurser

  • Last updated on