Escolha um fluxo de trabalho de construção e implementação de contentores

O Azure Developer CLI (azd) pode construir, publicar e implementar imagens de contentores em vários serviços de alojamento Azure. Um fluxo de trabalho de contentor combina um alvo de alojamento com um local de compilação e uma abordagem de publicação. A melhor combinação depende da sua aplicação, das ferramentas que a sua equipa tem disponíveis e de como promove imagens entre ambientes.

Use este artigo para adaptar essas escolhas às suas necessidades. Compara as seguintes decisões:

  • Que serviço Azure hospeda o teu contentor?
  • Quer azd crie a imagem localmente, quer a crie remotamente no Azure Container Registry (ACR), quer utilize uma imagem existente.
  • Se azd publica e implementa a imagem em conjunto ou como passos separados.

O artigo compara estes serviços de alojamento de uso geral:

Comece por comparar os destinos de alojamento e as opções de criação de imagens. Depois de compreender essas escolhas, use-as para identificar um fluxo de trabalho candidato na secção Comparar fluxos de trabalho de implementação de contentores .

Compare destinos de alojamento de contentores

A propriedade host em azure.yaml identifica o serviço Azure no qual azd implementa o seu contentor. Escolha o host independentemente do local de construção da imagem.

Valor do hospedeiro Destino de alojamento do Azure Fluxo de trabalho do contentor Considerações
containerapp Azure Container Apps e tarefas do Container Apps Construa a partir de um projeto e do Dockerfile, ou implemente uma imagem pré-construída. Suporta variáveis ambientais ao nível de serviço e estratégias de implementação específicas das Aplicações Container. Utilize o mesmo valor de anfitrião para tarefas do Container Apps.
appservice Aplicação Web Linux para Contentores no Serviço de Aplicações do Azure Construa a partir de um projeto e do Dockerfile, ou implemente uma imagem pré-construída. A sua infraestrutura deve fornecer um site Linux pronto para contentores e configurar o acesso de identidade gerida ao ACR. azd deploy Atualiza apenas a referência da imagem.
aks Azure Kubernetes Service Construir uma imagem e implementar manifestos Kubernetes, gráficos de Helm ou configurações Kustomize. Proporciona o maior controlo, mas exige que gere o cluster e a configuração do Kubernetes. A utilização do Helm ou do Kustomize com azd requer a ativação dos sinalizadores de funcionalidades alpha.

Os anfitriões ai.endpoint e azure.ai.agent também suportam a configuração do Docker para cenários especializados do Microsoft Foundry. Para essas cargas de trabalho, consulte Deploy to Microsoft Foundry online endpoints e a extensão do agente Microsoft Foundry.

Compare opções de construção de imagem

A definição do serviço determina se constrói uma imagem ou começa azd com uma imagem existente.

Opção de compilação Configuração necessária Onde a compilação é executada Motor local de contentores Mais indicado para
Construção local project e, opcionalmente, docker O seu ambiente de desenvolvimento ou executor de CI Obrigatório Iterações rápidas de desenvolvimento e ambientes de construção que já fornecem Docker ou Podman.
Construção remota ACR project e docker.remoteBuild: true Azure Container Registry Não é obrigatório, exceto se azd recuar após uma falha de compilação remota Compilações e ambientes consistentes na nuvem sem um motor local de contentores. O fluxo de trabalho documentado de compilação remota visa o Azure Container Apps.
Imagem existente gerida por azd image Sem compilação do código-fonte Pode ser necessário para operações do ciclo de vida de imagens Imagens que já existem localmente ou num registo e que azd pode transferir, marcar e enviar.
Passagem remota de imagem image e docker.imagePassthrough: true Sem compilação Não é obrigatório Imagens remotas totalmente qualificadas que o recurso de alojamento deve usar as-is.

Tenha em mente estas diferenças conceptuais ao ler os artigos sobre configuração por opção:

  • Uma imagem pré-construída usa a image propriedade em vez de project, e azd ainda pode puxar, etiquetar e empurrar.
  • Uma compilação remota ACR recorre a uma compilação local Docker ou Podman quando a compilação remota falha e um motor de contentores suportado está disponível.
  • A transmissão de imagem requer uma referência de imagem remota totalmente qualificada que inclua um registo, não pode ser combinada com remoteBuild e não suporta as opções azd publish --from-package nem azd publish --to, porque azd não gere a imagem.

Para a configuração completa de cada opção, consulte Suporte para compilações remotas com o Azure Container Registry, Utilizar registos de contentores de terceiros, Implementações de contentores do App Service com o Azure Developer CLI e o esquema docker.

Compare os fluxos de trabalho de implementação de contentores

Depois de comparar os alvos de alojamento em Comparar alvos de alojamento de contentores e as opções de construção em Comparar opções de construção de imagem, use a tabela seguinte para identificar os fluxos de trabalho mais prováveis para as suas necessidades.

Se precisares Comece com Porquê
Implementar uma aplicação containerizada numa plataforma serverless Azure Container Apps com compilação local Este fluxo de trabalho constrói e implementa um projeto baseado em Dockerfile num único fluxo de desenvolvimento.
Construa sem instalar o Docker ou o Podman localmente Azure Container Apps com compilação remota no ACR O ACR constrói a imagem a partir do teu projeto e do Dockerfile no Azure.
Implante uma imagem que outro sistema de compilação produza Azure Container Apps ou App Service com uma imagem pré-construída A image propriedade identifica a imagem existente em vez do código-fonte a construir.
Reutilizar uma imagem remota sem a puxar, etiquetar ou empurrar Azure Container Apps com transmissão direta de imagem azd Passa a referência da imagem totalmente qualificada diretamente ao recurso de alojamento.
Hospedar uma aplicação web tradicional como um contentor Linux Aplicação Web para Contentores no Serviço de Aplicações do Azure O App Service fornece uma plataforma integrada de alojamento web, enquanto a sua infraestrutura controla a configuração do site pronto para contentores.
Controle os manifestos do Kubernetes e a configuração do cluster Serviço de Kubernetes do Azure (AKS) azd pode criar e publicar a imagem e, em seguida, implementar manifestos do Kubernetes, gráficos Helm ou configurações do Kustomize.
Construa uma vez e promova a mesma imagem através de ambientes azd publish, seguido de azd deploy --from-package A publicação e a implementação são separadas, pelo que cada ambiente recebe a mesma imagem.

Cada linha combina as opções de alojamento de Comparar destinos de alojamento de contentores e as opções de criação de Comparar opções de criação de imagens como ponto de partida. Configura a tua escolha em azure.yaml, e deixa que os ficheiros Bicep ou Terraform preencham os respetivos recursos de alojamento e registo.

Uma definição mínima de serviço define o host, a origem da compilação e o Dockerfile:

services:
  api:
    project: ./src/api
    language: docker
    host: containerapp
    docker:
      path: ./Dockerfile

Para adaptar esta definição a outro host, altere o host valor e siga o contrato de configuração por host:

Compare os comandos de publicação e implementação

Depois de escolheres uma opção de host e build, seleciona se queres combinar ou separar a publicação e a implementação de imagens.

Command Ações de imagem Ação de recurso do Azure Utilizar quando
azd up Construir e impulsionar Provisão e implantação Quer criar ou atualizar o ambiente completo e implementar a aplicação num único fluxo de trabalho.
azd deploy Construir e impulsionar Implementar A infraestrutura já existe e queres implementar alterações na aplicação.
azd publish Construir e impulsionar None Queres criar um artefacto de registo sem o implementar. azd publish suporta Aplicações Container e serviços AKS.
azd publish --from-package <image> Enviar uma imagem local existente None Outro processo construiu a imagem e pretende que azd a publique.
azd deploy --from-package <image> None Implementar Queres implementar uma imagem específica sem a reconstruir.

Por exemplo, publicar uma imagem versionada e implementar essa mesma imagem noutro ambiente:

azd publish api --to myregistry.azurecr.io/my-api:v1.0.0
azd env select production
azd deploy api --from-package myregistry.azurecr.io/my-api:v1.0.0

Este fluxo de trabalho previne diferenças que podem ocorrer quando se reconstrói uma imagem para cada ambiente. Para um fluxo de trabalho completo de promoção, consulte os fluxos de trabalho de publicação do CLI para Desenvolvedores do Azure.