Compartilhar via

Fluxos de trabalho de publicação da CLI de Desenvolvimento do Azure

O azd publish comando permite que você crie e envie imagens de contêiner por push para um registro de contêiner, como o Registro de Contêiner do Azure ou o Docker Hub, sem implantá-las imediatamente em um recurso do Azure.

Separando as etapas de build e push da etapa de implantação, você pode implementar fluxos de trabalho de implantação mais avançados, como o padrão "compilar uma vez, implantar em todos os lugares". Essa abordagem é útil para aplicativos em contêineres direcionados aos Aplicativos de Contêiner do Azure ou ao AKS (Serviço de Kubernetes do Azure).

Porquê utilizar azd publish?

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

  1. Build: cria o código do aplicativo em uma imagem de contêiner.
  2. Push: envia essa imagem por push para um registro.
  3. Implantar: atualiza o serviço de hospedagem do Azure (como Aplicativos de Contêiner) para executar a nova imagem.

Embora conveniente para o desenvolvimento de loop interno, essa abordagem pressupõe que cada implantação requer um novo build. Em cenários de produção, você geralmente deseja:

  • Crie uma vez, implante em todos os lugares: crie um único artefato (imagem), teste-o em um ambiente de desenvolvimento e promova exatamente o mesmo artefato para produção sem recompilá-lo.
  • Centralizar artefatos: use um único Registro de Contêiner do Azure compartilhado (ACR) para armazenar imagens para todos os seus ambientes.
  • Melhorar a segurança: verifique se apenas as imagens verificadas e testadas são implantadas na produção.

azd publish habilita esses cenários manipulando apenas as etapas 1 e 2 (Build e Push). Em seguida, você pode usar azd deploy com sinalizadores específicos para manipular a etapa 3 (Implantar) usando a imagem pré-publicada.

Características principais

  • Publicação Independente: Publicar imagens em um repositório sem disparar uma implantação de software.
  • Destinos Personalizados: Use o --to flag para especificar exatamente onde a imagem deve ser enviada por meio do comando [registry/]repository[:tag], substituindo as convenções de nomenclatura padrão.
  • Suporte ao Registro de Terceiros: fazer push para registries externos (como o Docker Hub) além do Azure Container Registry.
  • Suporte para Ganchos: suporta ganchos prepublish e postpublish para automação personalizada.
  • Direcionamento de Serviço: atualmente dá suporte aos serviços hospedados nos Aplicativos de Contêiner do Azure e no AKS.

Usage

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

azd publish <service-name>

Para criar 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 compilar a partir da origem.
--to <image-ref> Especifica a referência de imagem de destino (por exemplo, <your-registry>.azurecr.io/my-app:v1). Substitui a nomenclatura padrão em azure.yaml.

Exemplos

Publicar um serviço específico em uma etiqueta personalizada:

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

Publique uma imagem local em um registro remoto:

Se você já tiver criado uma imagem localmente (por exemplo: local-api:dev), poderá marcá-la e efetuá-la por push usando azd:

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

Cenário: criar uma vez, implantar em todos os lugares

Um fluxo de trabalho de produção comum envolve criar uma imagem uma vez e promovê-la por meio de vários ambientes, como Desenvolvimento –> Teste –> Prod. Obtenha isso usando uma combinação de azd publish e azd deploy.

  1. Publique a imagem:

    Compile o código e envie-o por push para o registro compartilhado.

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

  2. Implantar no Desenvolvimento:

    Implante a versão de imagem específica no ambiente de desenvolvimento. A --from-package flag diz para azd deploy ignorar as etapas de build/push e atualizar apenas 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 produção:

    Após o teste no Desenvolvimento, implante 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 executadas Mais Adequado Para
azd publish Build –> Push Pipelines de CI/CD, criando artefatos, fluxos de trabalho "Compilar uma vez".
azd publish --from-package Somente push envia artefatos pré-construídos para os ambientes.
azd deploy Build –> Push –> Implantar Iteração de desenvolvimento padrão (loop interno).
azd deploy --from-package Implantar somente implantando artefatos pré-criados/pré-publicados em ambientes.
azd up Provisionamento –> Build –> Push –> Implantar Introdução, inicializando novos ambientes do zero.

Observação

O comportamento padrão de azd up permanece inalterado. Ele ainda orquestra o processo completo de ponta a ponta. No entanto, você pode personalizar seus fluxos azure.yaml de trabalho para usar azd publish , se necessário.

Configuração em azure.yaml

Defina as configurações padrão do Docker para seus serviços em azure.yaml. O azd publish comando respeita essas configurações, a menos que seja substituído por sinalizadores 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 essa configuração, executar azd publish api faria push para docker.io/myusername/my-api:latest.

Próximas etapas

  • Last updated on