Freigeben über

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 publishvon ?

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

  1. Build: Erstellt Ihren Anwendungscode in einem Containerimage.
  2. Push: Pusht dieses Image zu einem Registry.
  3. 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: Verwenden Sie den --to Schalter, um genau anzugeben, wo das Bild übertragen werden soll ([registry/]repository[:tag]), und Standardbenennungskonventionen zu überschreiben.
  • 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

Die 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.

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 allgemeiner Produktionsworkflow besteht darin, ein Image einmal zu erstellen und es durch mehrere Umgebungen wie Dev - Test - Prod zu leiten. Dies erreichen Sie mithilfe einer Kombination von azd publish und azd deploy.

  1. 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

  2. Bereitstellen zur 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

  3. 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.

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.

Nächste Schritte

  • Last updated on