Compartilhar via

Implantar em Aplicativos de Contêiner do Azure usando a CLI do Desenvolvedor do Azure

A CLI do Desenvolvedor do Azure (azd) dá suporte a duas estratégias de implantação para Aplicativos de Contêiner do Azure:

  • Estratégia baseada em imagem. Separa as atualizações de configuração do aplicativo de contêiner das implantações de imagens.
  • Estratégia baseada em revisão. Combina ambos em uma única implantação e dá suporte a padrões de distribuição avançados.

As seções a seguir explicam ambas as estratégias.

Estratégia de implantação baseada em imagem

Nessa estratégia, a configuração do aplicativo de contêiner é criada e atualizada durante azd provision, enquanto a imagem do contêiner é atualizada durante azd deploy.

  • A definição do aplicativo de contêiner (recursos, variáveis de ambiente, probes de integridade e assim por diante) reside em um módulo Bicep aplicado durante o provisionamento.
  • Apenas a referência da imagem do contêiner (containers[0].image) muda durante a implantação.

Comportamento de revisão

Cada alteração na configuração ou imagem do aplicativo dispara uma nova revisão:

Passo Command Aplica alterações a Anotações
1 azd provision Variáveis de ambiente, recursos, pontos de montagem, sondas, balanceadores de carga Cria uma nova revisão
2 azd deploy Imagem do contêiner Cria outra revisão

Cada revisão aloca réplicas adicionais no ambiente de Aplicativos de Contêiner, o que pode aumentar temporariamente o uso e o custo dos recursos.

Observação

Padrões avançados de distribuição, como azul-verde ou canário, não têm suporte nessa estratégia.

Configurar implantações baseadas em imagem

Para garantir que azd provision atualize um aplicativo de contêiner existente sem substituir a imagem implantada mais recente, execute uma operação upsert . Esse padrão é implementado pelo módulo AVM container-app-upsert e consiste em duas etapas:

  1. Em sua main.parameters.json, defina um parâmetro que referencie a variável SERVICE_{NAME}_RESOURCE_EXISTSfornecida pelo azd. Essa variável é definida automaticamente no azd momento do provisionamento para indicar se o recurso já existe.

    {
  "$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. No arquivo Bicep, faça referência ao exists parâmetro para controlar se o aplicativo contêiner deve ser criado ou atualizado. O container-app-upsert módulo encapsula essa lógica internamente.

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

    Essa abordagem permite que azd provisionatualize ou insira o recurso do aplicativo de contêiner de forma segura e sem a necessidade de verificações manuais.

    Dica

    Mantenha o apiVersion em azure.yaml alinhado com o apiVersion do módulo Bicep para Microsoft.App/containerApps evitar desalinhamentos.

Estratégia de implantação baseada em revisão

Nessa estratégia, a definição do aplicativo de contêiner e a imagem são implantadas juntas durante azd deploy.

  • A configuração do aplicativo de contêiner reside em um módulo Bicep dedicado aplicado durante a implantação.

  • As alterações em variáveis de ambiente, imagens, recursos e configurações de balanceamento de carga são distribuídas como uma única revisão.

    Dica

    Essa estratégia dá suporte a padrões de distribuição azul-verde, canário e outros padrões de distribuição avançados.

Configurar implantações baseadas em revisão

  1. Defina a implantação do aplicativo de contêiner criando um arquivo infra para seu serviço, como infra/api.bicep. Você pode definir seu aplicativo de contêiner usando o módulo baseado em AVM ou definindo o recurso diretamente:

    @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. Forneça parâmetros no momento da implantação criando um arquivo de parâmetros (por exemplo 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}" }
  }
}

    Observação

    SERVICE_API_IMAGE_NAME é definido dinamicamente durante a implantação e não faz parte das saídas de provisionamento.

    Quando você executa azd deploy, a revisão do aplicativo de contêiner é aplicada usando a definição de recurso acima.

    Dica

    Passe quaisquer saídas adicionais de azd provision como parâmetros para azd deploy se o seu aplicativo de contêiner fizer referência a outros recursos provisionados.

Resumo da comparação

Aspecto Baseado em imagem Baseado em revisão
Comando Atualizar azd provision + azd deploy azd deploy somente
Tipo de implementação Duas revisões Revisão única
Controle de implementação Gerenciado por azd Configurável (azul-verde, canário)
Caso de uso Ambientes simples Implantações avançadas
Local de definição do aplicativo de contêiner Bicep para tempo de provisionamento Bicep no momento de implantação

Recursos adicionais

  • Last updated on