Auswählen eines Containerbuild- und Bereitstellungsworkflows

Azure Developer CLI (azd) kann Containerimages in mehreren Azure Hostingdiensten erstellen, veröffentlichen und bereitstellen. Ein Container-Workflow kombiniert ein Hostingziel mit einem Buildort und einem Bereitstellungsansatz. Die beste Kombination hängt von Ihrer Anwendung, den Tools, die Ihrem Team zur Verfügung stehen, und davon ab, wie Sie Images zwischen Umgebungen hochstufen.

Verwenden Sie diesen Artikel, um diese Auswahl an Ihre Anforderungen anzupassen. Es vergleicht die folgenden Entscheidungen:

  • Welcher Azure Dienst Ihren Container hosten soll.
  • Ob azd das Image lokal erstellt, es remote in Azure Container Registry (ACR) erstellt oder ein vorhandenes Image verwendet.
  • Ob azd das Image zusammen oder in separaten Schritten veröffentlicht und bereitstellt.

Der Artikel vergleicht diese allgemeinen Hostingdienste:

Vergleichen Sie zunächst die Hosting-Ziele und Image-Build-Optionen. Nachdem Sie diese Auswahlmöglichkeiten verstanden haben, verwenden Sie sie, um einen Kandidatenworkflow im Abschnitt " Containerbereitstellungsworkflows vergleichen " zu identifizieren.

Vergleichen von Containerhostingzielen

Die Eigenschaft host in azure.yaml gibt den Azure-Dienst an, für den azd Ihren Container bereitstellt. Wählen Sie den Host unabhängig vom Ort der Image-Erstellung aus.

Hostwert Azure-Hostingziel Containerworkflow Überlegungen
containerapp Aufträge für Azure Container Apps und Container-Apps Erstellen Sie ein Image aus einem Projekt und einem Dockerfile oder stellen Sie ein vorgefertigtes Image bereit. Unterstützt Umgebungsvariablen auf Dienstebene und Container-Apps-spezifische Bereitstellungsstrategien. Verwenden Sie denselben Hostwert für Container-Apps-Aufträge.
appservice Linux Web App für Container auf Azure App Service Erstellen Sie ein Image aus einem Projekt und einem Dockerfile oder stellen Sie ein vorgefertigtes Image bereit. Ihre Infrastruktur muss einen für Linux containerfähigen Standort bereitstellen und verwalteten Identitätszugriff auf ACR konfigurieren. azd deploy aktualisiert nur den Bildverweis.
aks Azure Kubernetes-Dienst Erstellen Sie ein Image, und stellen Sie Kubernetes-Manifeste, Helmdiagramme oder Kustomize-Konfigurationen bereit. Bietet die meiste Kontrolle, erfordert jedoch die Verwaltung der Cluster- und Kubernetes-Konfiguration. Die Verwendung von Helm oder Kustomize mit azd erfordert die Aktivierung von Alpha-Feature-Flags.

Die ai.endpoint und azure.ai.agent Hosts unterstützen auch die Docker-Konfiguration für spezialisierte Microsoft Foundry-Szenarien. Informationen zu diesen Workloads finden Sie unter Bereitstellen für Microsoft Foundry-Online-Endpunkte und Microsoft Foundry-Agenterweiterung.

Image-Build-Optionen vergleichen

Die Dienstdefinition bestimmt, ob azd ein Image erstellt oder mit einem vorhandenen Image beginnt.

Buildoption Erforderliche Konfiguration Wo der Build ausgeführt wird Lokale Container-Engine Am besten geeignet für
Lokaler Build project und optional docker Ihre Entwicklungsumgebung oder CI-Runner Erforderlich Schnelle Entwicklungsiterationen und Buildumgebungen, die bereits Docker oder Podman bereitstellen.
ACR-Remotebuild project und docker.remoteBuild: true Azure Container Registry (Registrierungsdienst für Container von Azure) Nicht erforderlich, es sei denn, azd fällt nach einem Fehlschlag eines Remote-Builds zurück. Konsistente Cloud-Builds und Umgebungen ohne lokale Container-Engine. Der dokumentierte Remotebuild-Workflow ist auf Azure Container Apps ausgerichtet.
Vorhandenes Bild verwaltet von azd image Kein Quellbuild Möglicherweise für Image-Lebenszyklusvorgänge erforderlich Bilder, die bereits lokal oder in einer Registry vorhanden sind oder die azd abrufen, taggen und pushen kann.
Durchleitung des Remote-Image image und docker.imagePassthrough: true Kein Build Nicht erforderlich Vollqualifizierte Remote-Images, die von der hostenden Ressource unverändert verwendet werden sollen.

Beachten Sie diese konzeptionellen Unterschiede, wenn Sie die Artikel zur Konfiguration pro Option lesen:

  • Ein vorerstelltes Image verwendet die image-Eigenschaft anstelle von project, und azd kann es trotzdem pullen, taggen und pushen.
  • Ein ACR-Remotebuild greift auf einen lokalen Docker- oder Podman-Build zurück, wenn der Remotebuild fehlschlägt und ein unterstütztes Containermodul verfügbar ist.
  • Image-Passthrough erfordert eine vollständig qualifizierte Remote-Image-Referenz, die eine Registry enthält, kann nicht mit remoteBuild kombiniert werden und unterstützt die Optionen azd publish --to oder azd publish --from-package nicht, da azd das Image nicht verwaltet.

Die vollständige Konfiguration jeder Option finden Sie unter Unterstützung für Remotebuilds mit Azure Container Registry, Verwenden von Containerregistrierungen von Drittanbietern, App Service-Containerbereitstellungen mit Azure Developer CLI und dem dockerSchema.

Containerbereitstellungs-Workflows vergleichen

Nachdem Sie die Hostingziele in Container-Hostingziele vergleichen und die Build-Optionen in Image-Build-Optionen vergleichen verglichen haben, verwenden Sie die folgende Tabelle, um die für Ihre Anforderungen wahrscheinlichsten Workflows zu ermitteln.

Wenn Sie Folgendes müssen: Mit Warum?
Bereitstellen einer containerisierten Anwendung auf einer serverlosen Plattform Azure Container Apps mit lokalem Build Dieser Workflow erstellt und stellt ein Dockerfile-basiertes Projekt in einem Entwicklungsworkflow bereit.
Erstellen ohne lokale Installation von Docker oder Podman Azure Container Apps mit einem ACR-Remote-Build ACR erstellt das Image aus Ihrem Projekt und dem Dockerfile in Azure.
Bereitstellen eines Images, das ein anderes Buildsystem erzeugt Azure Container Apps oder App Service mit einem vordefinierten Bild Die image Eigenschaft identifiziert das vorhandene Image anstelle des zu erstellenden Quellcodes.
Ein Remote-Image wiederverwenden, ohne es abzurufen, zu taggen oder hochzuladen Azure Container Apps mit Passthrough für Bilder azd übergibt den vollqualifizierten Bildverweis direkt an die Hostingressource.
Hosten einer herkömmlichen Webanwendung als Linux-Container Web App für Container auf Azure App Service App Service stellt eine integrierte Webhostingplattform bereit, während Ihre Infrastruktur die Konfiguration der containerbereiten Website steuert.
Steuern von Kubernetes-Manifesten und Clusterkonfiguration Azure Kubernetes Service (AKS) azd kann das Image erstellen und veröffentlichen und dann Kubernetes-Manifeste, Helmdiagramme oder Kustomize-Konfigurationen bereitstellen.
Einmal erstellen und dasselbe Image durch die Umgebungen weiterleiten azd publish, gefolgt von azd deploy --from-package Veröffentlichung und Bereitstellung sind getrennt, sodass jede Umgebung dasselbe Image empfängt.

Jede Zeile kombiniert die Hostingoptionen aus Container-Hostingziele vergleichen und die Optionen für die Imageerstellung aus Image-Buildoptionen vergleichen zu einem Ausgangspunkt. Konfigurieren Sie Ihre Wahl in azure.yaml, und lassen Sie Ihre Bicep- oder Terraform-Dateien die entsprechenden Hosting- und Registrierungsressourcen bereitstellen.

Eine minimale Dienstdefinition legt die host, die Buildquelle und das Dockerfile fest:

services:
  api:
    project: ./src/api
    language: docker
    host: containerapp
    docker:
      path: ./Dockerfile

Um diese Definition an einen anderen Host anzupassen, ändern Sie den Wert, und folgen Sie dem Vertrag für die host Konfiguration pro Host:

Vergleichen von Veröffentlichungs- und Bereitstellungsbefehlen

Nachdem Sie eine Host- und Buildoption ausgewählt haben, wählen Sie aus, ob Sie die Veröffentlichung und Bereitstellung von Images kombinieren oder trennen möchten.

Befehl Bild-Aktionen Aktion für Azure-Ressourcen Verwenden Sie, wenn
azd up Erstellen und Pushen Bereitstellen und implementieren Sie möchten die vollständige Umgebung erstellen oder aktualisieren und die Anwendung in einem Workflow bereitstellen.
azd deploy Erstellen und Pushen Bereitstellen Die Infrastruktur ist bereits vorhanden und Sie möchten Änderungen an der Anwendung bereitstellen.
azd publish Erstellen und Pushen Nichts Sie möchten ein Registrierungsartefakt erstellen, ohne es bereitzustellen. azd publish unterstützt Container-Apps und AKS-Dienste.
azd publish --from-package <image> Ein vorhandenes lokales Image hochladen Nichts Ein anderer Prozess hat das Image erstellt, und Sie möchten azd es veröffentlichen.
azd deploy --from-package <image> Nichts Bereitstellen Sie möchten ein bestimmtes Image bereitstellen, ohne es neu zu erstellen.

Veröffentlichen Sie z. B. ein versionsiertes Image, und stellen Sie dasselbe Image in einer anderen Umgebung bereit:

azd publish api --to myregistry.azurecr.io/my-api:v1.0.0
azd env select production
azd deploy api --from-package myregistry.azurecr.io/my-api:v1.0.0

Dieser Workflow verhindert Unterschiede, die auftreten können, wenn Sie ein Image für jede Umgebung neu erstellen. Einen vollständigen Promotion-Workflow finden Sie unter Azure Entwickler-CLI-Veröffentlichungsworkflows.

Verwandte Inhalte

  • Zuletzt aktualisiert um