Condividi tramite

Flussi di lavoro di pubblicazione per la CLI per sviluppatori Azure

Il azd publish comando consente di compilare ed eseguire il push di immagini del contenitore in un registro contenitori come Registro Azure Container o l'hub Docker senza distribuirle immediatamente in una risorsa di Azure.

Separando i passaggi di compilazione e push dal passaggio di distribuzione, è possibile implementare flussi di lavoro di distribuzione più avanzati, ad esempio il modello "build once, deploy everywhere". Questo approccio è utile per le applicazioni in contenitori destinate ad App Azure Container o al servizio Azure Kubernetes.

Perché usare azd publish?

In un flusso di lavoro standard azd , il azd deploy comando esegue tre azioni in sequenza:

  1. Compilazione: compila il codice dell'applicazione in un'immagine del contenitore.
  2. Push: esegue il push dell'immagine in un registro.
  3. Implementazione: aggiorna il servizio di hosting su Azure (ad esempio Container Apps) per eseguire la nuova immagine.

Sebbene sia utile per lo sviluppo iterativo interno, questo approccio presuppone che ogni rilascio richieda una nuova compilazione. Negli scenari di produzione è spesso necessario:

  • Compilare una sola volta, distribuire ovunque: compilare un singolo artefatto (immagine), testarlo in un ambiente di sviluppo e quindi alzare di livello lo stesso artefatto esattamente all'ambiente di produzione senza ricompilarlo.
  • Centralizzare gli artefatti: usare un singolo Registro Azure Container condiviso per archiviare le immagini per tutti gli ambienti.
  • Migliorare la sicurezza: assicurarsi che solo le immagini verificate e testate vengano distribuite nell'ambiente di produzione.

azd publish abilita questi scenari gestendo solo i passaggi 1 e 2 (compilazione e push). È quindi possibile usare azd deploy con flag specifici per gestire il passaggio 3 (Distribuisci) usando l'immagine prepubblicata.

Funzionalità principali

  • Pubblicazione indipendente: pubblicare immagini in un registro senza attivare una distribuzione.
  • Destinazioni personalizzate: usare il --to flag per specificare esattamente dove deve essere eseguito il push dell'immagine ([registry/]repository[:tag]), sostituendo le convenzioni di denominazione predefinite.
  • Supporto per registri di terze parti: eseguire il push nei registri esterni (ad esempio Docker Hub) oltre al Registro Azure Container.
  • Supporto ganci: supporta i ganci prepublish e postpublish per l'automazione personalizzata.
  • Targeting dei servizi: supporta attualmente i servizi ospitati su Azure Container Apps e AKS.

Usage

Per compilare e pubblicare l'immagine per un servizio specifico definito in azure.yaml:

azd publish <service-name>

Per compilare e pubblicare tutti i servizi:

azd publish --all

Parametri

Flag Description
--all Pubblica tutti i servizi definiti in azure.yaml.
--from-package <image> Usa un'immagine o un pacchetto locale esistente anziché crearlo dall'origine.
--to <image-ref> Specifica il riferimento all'immagine di destinazione, ad esempio <your-registry>.azurecr.io/my-app:v1. Sovrascrive la denominazione predefinita in azure.yaml.

Esempi

Pubblicare un servizio specifico in un tag personalizzato:

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

Pubblicare un'immagine locale in un registro remoto:

Se è già stata creata un'immagine in locale (ad esempio: local-api:dev), è possibile contrassegnarla ed eseguirne il push usando azd:

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

Scenario: costruire una sola volta, distribuire ovunque

Un flusso di lavoro di produzione comune prevede la creazione di un'immagine una sola volta e la promozione tramite più ambienti, ad esempio Sviluppo -> Test -> Prod. Ottenere questo risultato usando una combinazione di azd publish e azd deploy.

  1. Pubblicare l'immagine:

    Compilare il codice ed eseguirne il push nel registro condiviso.

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

  2. Distribuzione nello sviluppo:

    Distribuire la versione specifica dell'immagine nell'ambiente di sviluppo. Il flag --from-package indica a azd deploy di saltare i passaggi di build/invio e di aggiornare la configurazione del servizio semplicemente.

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

  3. Alzare di livello la produzione:

    Dopo il test in Dev, distribuire lo stesso riferimento all'immagine nell'ambiente di produzione.

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

Confronto con altri comandi

Command Azioni eseguite Ideale per
azd publish Compilazione -> Push Pipeline CI/CD, creazione di artefatti, flussi di lavoro "Compila una sola volta".
azd publish --from-package Solo push invia artefatti predefiniti agli ambienti.
azd deploy Compilazione -> Inoltro -> Distribuzione Iterazione di sviluppo standard (ciclo interno).
azd deploy --from-package Distribuire soltanto distribuzione di artefatti pre-compilati/pre-pubblicati in ambienti.
azd up Provision -> Compilazione -> Push -> Distribuzione Introduzione, inizializzazione di nuovi ambienti da zero.

Annotazioni

Il comportamento predefinito di azd up rimane invariato. Orchestra ancora il processo end-to-end completo. Tuttavia, è possibile personalizzare i flussi di lavoro in azure.yaml per usare azd publish se necessario.

Configurazione in azure.yaml

Configurare le impostazioni docker predefinite per i servizi in azure.yaml. Il azd publish comando rispetta queste impostazioni a meno che non venga sovrascritto da flag come --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

Con questa configurazione, l'esecuzione di azd publish api porterà a un push in docker.io/myusername/my-api:latest.

Passaggi successivi

  • Last updated on