Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
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
azdcrie a imagem localmente, quer a crie remotamente no Azure Container Registry (ACR), quer utilize uma imagem existente. - Se
azdpublica e implementa a imagem em conjunto ou como passos separados.
O artigo compara estes serviços de alojamento de uso geral:
- Aplicativos de contêiner do Azure
- Contentores de Serviços de Aplicações
- Azure Kubernetes Service (AKS)
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
imagepropriedade em vez deproject, eazdainda 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
remoteBuilde não suporta as opçõesazd publish --from-packagenemazd publish --to, porqueazdnã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:
- Implementar em Azure Container Apps usando o Azure Developer CLI
- Implementações de contentores no App Service com o Azure Developer CLI
- Apoio a Helm e Kustomize
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.