Azure Developer CLI-Veröffentlichungsworkflows

Mit dem azd publish Befehl können Sie Containerimages erstellen und an eine Containerregistrierung wie Azure Container Registry oder Docker Hub übertragen, ohne sie sofort in einer Azure-Ressource bereitzustellen.

Indem Sie die Build- und Pushschritte vom Bereitstellungsschritt trennen, können Sie erweiterte Bereitstellungsworkflows implementieren, z. B. das Muster "Einmal erstellen, überall bereitstellen". Dieser Ansatz ist nützlich für containerisierte Anwendungen, die auf Azure-Container-Apps oder Azure Kubernetes Service (AKS) abzielen.

Gründe für die Verwendung `azd publish`von ?

In einem Standardworkflow azd führt der azd deploy Befehl drei Aktionen in Folge aus:

Build: Erstellt Ihren Anwendungscode in einem Containerimage.
Push: Pusht dieses Image zu einem Registry.
Bereitstellen: Aktualisiert Ihren Azure-Hostingdienst (z. B. Container-Apps), um das neue Image auszuführen.

Wenn dieser Ansatz für die Entwicklung im inneren Zyklus verwendet wird, wird davon ausgegangen, dass jede Bereitstellung einen neuen Build erfordert. In Produktionsszenarien möchten Sie häufig:

Erstellen Sie einmal, stellen Sie überall bereit: Erstellen Sie ein einzelnes Artefakt (Image), testen Sie es in einer Entwicklungsumgebung, und fördern Sie dann das gleiche Artefakt für die Produktion, ohne es neu zu erstellen.
Zentrale Artefakte: Verwenden Sie eine einzelne freigegebene Azure Container Registry (ACR), um Bilder für alle Ihre Umgebungen zu speichern.
Sicherheit verbessern: Stellen Sie sicher, dass nur überprüfte und getestete Images in der Produktion bereitgestellt werden.

azd publish ermöglicht diese Szenarien, indem nur die Schritte 1 und 2 (Build und Push) behandelt werden. Sie können dann azd deploy mit bestimmten Flags Schritt 3 (Bereitstellen) mithilfe des vorab veröffentlichten Images ausführen.

Wichtigste Funktionen

Unabhängige Veröffentlichung: Veröffentlichen von Images in einer Registrierung, ohne eine Bereitstellung auszulösen.
Benutzerdefinierte Ziele: Mit dem Flag--to Mit dem Flag ([registry/]repository[:tag]), wodurch die Standardbenennungskonventionen überschrieben werden.
Unterstützung von Drittanbieterregistrierungen: Push an externe Registrierungen (z. B. Docker Hub) zusätzlich zur Azure-Containerregistrierung.
Hook-Unterstützung: Unterstützt prepublish und postpublish Hooks für die benutzerdefinierte Automatisierung.
Dienstadressierung: Unterstützt derzeit dienste, die in Azure Container-Apps und AKS gehostet werden.

Usage

Erstellen und veröffentlichen Sie das Image für einen bestimmten Dienst, der in Ihrem azure.yaml definiert ist:

azd publish <service-name>

So erstellen und veröffentlichen Sie alle Dienste:

azd publish --all

Parameter

Flag	Description
`--all`	Veröffentlicht alle Dienste in `azure.yaml`.
`--from-package <image>`	Verwendet ein vorhandenes lokales Image oder Paket, anstatt aus der Quelle zu erstellen.
`--to <image-ref>`	Gibt den Zielbildverweis an (z. B `<your-registry>.azurecr.io/my-app:v1`. ). Überschreibt die Standardbenennung in `azure.yaml`.

Hinweis

Für Dienste, die mit services.<name>.docker.imagePassthrough: truekonfiguriert sind, azd publish erstellt oder pusht kein Image. Es verwendet stattdessen das konfigurierte Remote-Image wieder und lehnt die Flags --from-package und --to für diesen Dienst ab.

Examples

Veröffentlichen eines bestimmten Diensts unter einem benutzerdefinierten Tag:

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

Veröffentlichen Sie ein lokales Image in einer Remote-Registry:

Wenn Sie bereits ein Image lokal erstellt haben (z. B.: local-api:dev), können Sie es mit folgendem Tag markieren und pushen:azd

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

Szenario: Einmal erstellen, überall bereitstellen

Ein gängiger Produktionsworkflow beinhaltet das einmalige Erstellen eines Images und dessen Weitergabe an verschiedene Umgebungen wie Entwicklung - > Test -> Produktion. Dies lässt sich durch eine Kombination von azd publish und azd deploy erreichen.

Dieses Szenario gilt nicht für Dienste, die mit services.<name>.docker.imagePassthrough: truekonfiguriert sind, da azd publish kein Image für diese Dienste erstellt oder übertragen wird.

Veröffentlichen Sie das Bild:

Erstellen Sie den Code und pushen Sie ihn in Ihr freigegebenes Registry.
```
azd publish api-service --to <your-registry>.azurecr.io/my-app:v1.0.0
```
Bereitstellen für die Entwicklung:

Stellen Sie die spezifische Imageversion in der Entwicklungsumgebung bereit. Das --from-package Flag weist azd deploy an, die Build-/Pushschritte zu überspringen und einfach die Dienstkonfiguration zu aktualisieren.
```
azd env select dev
azd deploy api-service --from-package <your-registry>.azurecr.io/my-app:v1.0.0
```
Förderung der Produktion:

Stellen Sie nach dem Testen in Dev denselben Imageverweis für die Produktionsumgebung bereit.
```
azd env select prod
azd deploy api-service --from-package <your-registry>.azurecr.io/my-app:v1.0.0
```

Vergleich mit anderen Befehlen

Command	Ausgeführte Aktionen	Am besten geeignet für
`azd publish`	Build –> Push	CI/CD-Pipelines, Erstellen von Artefakten, "Einmal erstellen"-Workflows.
`azd publish --from-package`	Nur Pushen	Überträgt vorgefertigte Artefakte an Umgebungen.
`azd deploy`	Build –> Push –> Bereitstellen	Standardentwicklungsiteration (innere Schleife).
`azd deploy --from-package`	Ausschließlich bereitstellen	Bereitstellen vorgefertigter/vorab veröffentlichter Artefakte in Umgebungen.
`azd up`	Bereitstellung –> Build –> Push –> Bereitstellen	Erste Schritte, Initialisieren neuer Umgebungen von Grund auf neu.

Hinweis

Das Standardverhalten bleibt azd up unverändert. Es orchestriert weiterhin den vollständigen End-to-End-Prozess. Sie können jedoch bei Bedarf Ihre Workflows in azure.yaml anpassen, um azd publish zu verwenden.

Für Dienste, die mit services.<name>.docker.imagePassthrough: true konfiguriert sind, gelten azd publish und azd publish --from-package nicht. azd verwendet das konfigurierte Remoteimage wieder, anstatt ein Remoteimage zu erstellen oder zu pushen.

Konfiguration in `azure.yaml`

Konfigurieren Sie standardmäßige Docker-Einstellungen für Ihre Dienste in azure.yaml. Der azd publish Befehl berücksichtigt diese Einstellungen, es sei denn, sie werden durch Flags wie --toüberschrieben.

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

Bei dieser Konfiguration würde azd publish api an docker.io/myusername/my-api:latest pushen.

Wiederverwenden eines Remoteimages mit `imagePassthrough`

Wenn Ihr Dienst bereits über ein veröffentlichtes Image verfügt, das von azd nicht erstellt, gepusht oder anderweitig verwaltet werden soll, setzen Sie services.<name>.docker.imagePassthrough: true. Wenn Sie diese Option aktivieren:

Legen Sie services.<name>.image auf die endgültige, vollqualifizierte Remote-Image-Referenz fest, unter Angabe einer expliziten Registry.
Sie können docker.imagePassthrough nicht mit docker.remoteBuild kombinieren.
azd publish erstellt kein Image für den Dienst und pusht auch keines, und es lehnt die Flags --from-package und --to für diesen Dienst ab.

name: my-app
services:
  api:
    host: containerapp
    docker:
      imagePassthrough: true
    image: docker.io/myusername/my-api:v1.0.0

Nächste Schritte

Feedback

War diese Seite hilfreich?

Zuletzt aktualisiert um 2026-09-03