Partilhar via

Fluxos de trabalho de publicação do Azure Developer CLI

O azd publish comando permite-lhe construir e enviar imagens de contentores para um registo de contentores como Azure Container Registry ou Docker Hub sem as implementar imediatamente para um recurso Azure.

Ao separar as etapas de build e push da etapa de deployment, pode implementar fluxos de trabalho de deployment mais avançados, como o padrão "construir uma vez, implementar em todo o lado". Esta abordagem é útil para aplicações containerizadas direcionadas a Azure Container Apps ou Azure Kubernetes Service (AKS).

Porquê usar azd publish?

Num fluxo de trabalho padrão azd , o azd deploy comando executa três ações em sequência:

  1. Build: Constrói o código da sua aplicação numa imagem de contentor.
  2. Push: Empurra essa imagem para um registo.
  3. Deploy: Atualiza o seu serviço de alojamento Azure (como Container Apps) para executar a nova imagem.

Embora conveniente para desenvolvimento em circuito interno, esta abordagem assume que cada implementação requer uma nova construção. Em cenários de produção, muitas vezes quer-se:

  • Construa uma vez, implemente em todo o lado: construa um único artefacto (imagem), teste-o num ambiente de desenvolvimento e depois promova exatamente esse mesmo artefacto para produção sem o reconstruir.
  • Centralize artefatos: Use um único Azure Container Registry (ACR) partilhado para armazenar imagens para todos os ambientes.
  • Melhorar a segurança: Garantir que apenas imagens verificadas e testadas sejam implementadas em produção.

azd publish permite estes cenários ao tratar apenas os passos 1 e 2 (Construir e Empurrar). Pode então usar azd deploy com flags específicos para gerir o passo 3 (Deploy) usando a imagem pré-publicada.

Principais características

  • Publicação Independente: Publique imagens num registo sem desencadear uma implementação.
  • Alvos Personalizados: Use a --to flag para especificar exatamente onde a imagem deve ser empurrada ([registry/]repository[:tag]), sobrepondo as convenções de nomenclatura padrão.
  • Suporte para Registos de Terceiros: Fazer push para registos externos (como o Docker Hub) além do registo de contentores do Azure.
  • Suporte a Ganchos: Suporte a ganchos prepublish e postpublish para automação personalizada.
  • Segmentação de Serviços: Atualmente suporta serviços alojados em Azure Container Apps e AKS.

Usage

Para construir e publicar a imagem para um serviço específico definido no seu azure.yaml:

azd publish <service-name>

Para construir e publicar todos os serviços:

azd publish --all

Parâmetros

Flag Description
--all Publica todos os serviços definidos em azure.yaml.
--from-package <image> Usa uma imagem ou pacote local existente em vez de construir a partir da fonte.
--to <image-ref> Especifica a referência da imagem alvo (por exemplo, <your-registry>.azurecr.io/my-app:v1). Sobrepõe o nome predefinido em azure.yaml.

Examples

Publique um serviço específico numa etiqueta personalizada:

azd publish api-service --to <your-registry>.azurecr.io/api-service:v1.0.0

Publique uma imagem local num registo remoto:

Se já criaste uma imagem localmente (por exemplo: local-api:dev), podes marcá-la e enviá-la usando azd:

azd publish api-service --from-package local-api:dev --to <your-registry>.azurecr.io/api-service:v1.0.0

Cenário: Construir uma vez, implementar em todo o lado

Um fluxo de trabalho comum em produção envolve construir uma imagem uma vez e promovê-la através de múltiplos ambientes, como Dev -> Test -> Prod. Obtenha-se isto usando uma combinação de azd publish e azd deploy.

  1. Publique a imagem:

    Constrói o código e envia-o para o teu registo partilhado.

    azd publish api-service --to <your-registry>.azurecr.io/my-app:v1.0.0

  2. Implementar para o Desenvolvimento:

    Implemente a versão específica da imagem no ambiente de desenvolvimento. A --from-package flag indica azd deploy para saltar os passos de build/push e apenas atualizar a configuração do serviço.

    azd env select dev
azd deploy api-service --from-package <your-registry>.azurecr.io/my-app:v1.0.0

  3. Promover para a Produção:

    Depois de testar em desenvolvimento, implemente a mesma referência de imagem no ambiente de produção.

    azd env select prod
azd deploy api-service --from-package <your-registry>.azurecr.io/my-app:v1.0.0

Comparação com outros comandos

Command Ações Realizadas Melhor Para
azd publish Build -> Empurrar Pipelines CI/CD, criação de artefactos, fluxos de trabalho "Construir uma vez".
azd publish --from-package Apenas empurrar Empurra artefactos pré-construídos para os ambientes.
azd deploy Construir -> Enviar -> Implementar Iteração padrão de desenvolvimento (ciclo interno).
azd deploy --from-package Apenas implantação implantar artefactos pré-construídos/pré-publicados em ambientes.
azd up Provisão -> Construção -> Empurrar -> Implementar Começar, inicializar novos ambientes do zero.

Observação

O comportamento padrão de azd up mantém-se inalterado. Continua a orquestrar todo o processo de ponta a ponta. No entanto, pode personalizar os seus fluxos de trabalho no azure.yaml para usar o azd publish, se necessário.

Configuração em azure.yaml

Configure as definições padrão do Docker para os seus serviços em azure.yaml. O azd publish comando respeita estas definições, a menos que seja sobreposto por flags como --to.

name: my-app
services:
  api:
    project: ./src/api
    host: containerapp
    docker:
      registry: 'docker.io/myusername' # Default registry
      image: 'my-api'                  # Default image name
      tag: 'latest'                    # Default tag

Com esta configuração, executar azd publish api empurraria para docker.io/myusername/my-api:latest.

Próximos passos

  • Last updated on