azd Vorlagen sind Blaupausenrepositorys, die App-Code für die Proof-of-Concept-Anwendung, Editor-/IDE-Konfigurationen und Infrastrukturcode enthalten, der in Bicep oder Terraform geschrieben wurde. Diese Vorlagen sollen für Ihre spezifischen Anwendungsanforderungen geändert und angepasst werden und dann verwendet werden, um Ihre Anwendung mit der Azure Developer CLI (azd) auf Azure zu beziehen. Das azure.yaml- Schema definiert und beschreibt die Apps und Typen von Azure-Ressourcen, die in diesen Vorlagen enthalten sind.
Probe
Nachfolgend finden Sie ein allgemeines Beispiel für eine azure.yaml, die für Ihre azd Vorlage erforderlich ist.
name: yourApp
metadata:
template: yourApp@0.0.1-beta
services:
web:
project: ./src/web # path to your web project
dist: build # relative path to service deployment artifacts
language: js # one of the supported languages
host: appservice # one of the supported Azure services
(Zeichenfolge) Name der Azure-Ressourcengruppe. Wenn angegeben, überschreiben Sie den Ressourcengruppennamen, der für die Infrastrukturbereitstellung verwendet wird.
(Objekt) bietet zusätzliche Konfiguration für die Bereitstellung der Azure-Infrastruktur. Weitere Informationen finden Sie unter Infrastruktureigenschaften.
services
Y
(Objekt) Definition der Dienste, die die Anwendung umfassen. Weitere Informationen finden Sie unter Eigenschaften von Diensten.
pipeline
N
(Objekt) Definition der kontinuierlichen Integrationspipeline. Weitere Informationen finden Sie unter Pipelineeigenschaften.
hooks
N
Hooks auf Befehlsebene. Hooks sollten azd Befehlsnamen mit dem Präfix pre oder post übereinstimmen, je nachdem, wann das Skript ausgeführt werden soll. Beim Angeben von Pfaden sollten sie relativ zum Projektpfad sein. Weitere Informationen finden Sie unter Anpassen Ihrer Azure Developer CLI-Workflows mithilfe von Befehls- und Ereignishaken.
requiredVersions
N
Eine Reihe unterstützter Versionen von azd für dieses Projekt. Wenn sich die Version von azd außerhalb dieses Bereichs befindet, wird das Projekt nicht geladen. Optional (lässt alle Versionen zu, falls nicht vorhanden). Beispiel: >= 0.6.0-beta.3
metadata-Eigenschaften
Elementname
Erforderlich
Beschreibung
Beispiel
template
N
(Zeichenfolge) Bezeichner der Vorlage, aus der die Anwendung erstellt wurde.
todo-nodejs-mongo@0.0.1-beta
infra-Eigenschaften
Elementname
Erforderlich
Beschreibung
Beispiel
provider
N
(Zeichenfolge) Der Infrastrukturanbieter für die Azure-Ressourcen der Anwendung. (Standard: Bicep).
(Zeichenfolge) Name der Azure-Ressource, die den Dienst implementiert. Wenn nicht angegeben, sucht azd nach einer Ressource nach azd-env-name und azd-service-name Tags. Wenn sie nicht gefunden wird, wird nach einem Ressourcennamen gesucht, der aus dem aktuellen Umgebungsnamen erstellt wurde, verkettet mit dem Dienstnamen (<environment-name><resource-name>).
prodapi
project
Y
(Zeichenfolge) Pfad zum Quellcodeverzeichnis des Diensts.
host
Y
(Zeichenfolge) Typ der Azure-Ressource, die für die Dienstimplementierung verwendet wird. Wenn diese Angabe weggelassen wird, wird der App-Dienst angenommen.
appservice, containerapp, function, staticwebapp, aks (nur für Projekte, die über kubectl apply -fbereitgestellt werden können ), springapp (wenn aktiviert ist - erfahren Sie mehr über Alphafeatures)
language
Y
(Zeichenfolge) Dienstimplementierungssprache.
dotnet, csharp, fsharp, py, python, js, ts, java
module
Y
(Zeichenfolge) Pfad des Infrastrukturmoduls, das zum Bereitstellen des Diensts relativ zum Stamminfrastrukturordner verwendet wird. Wenn dies nicht angegeben wird, geht die CLI davon aus, dass der Modulname mit dem Dienstnamen identisch ist.
dist
Y
(Zeichenfolge) relativen Pfad zu den Dienstbereitstellungsartefakten. Die CLI verwendet Dateien unter diesem Pfad, um das Bereitstellungsartefakt (.zip Datei) zu erstellen. Wenn nicht angegeben, werden alle Dateien unter dem Dienstprojektverzeichnis eingeschlossen.
build
docker
N
Gilt nur, wenn hostcontainerappist. Keine zusätzlichen Eigenschaften enthalten.
Sehen Sie sich das benutzerdefinierte Docker-Beispiel unten an.
path(Zeichenfolge): Pfad zur Dockerfile-Datei. Standard: ./Dockerfile; context(Zeichenfolge): Der Docker-Buildkontext. Wenn angegeben, überschreibt der Standardkontext. Standard: .; platform(Zeichenfolge): Das Plattformziel. Standard: amd64; remoteBuild(boolean): Ermöglicht Remote-ACR-Builds. Standard: false
k8s
N
Die Azure Kubernetes Service (AKS)-Konfigurationsoptionen.
Sehen Sie sich das AKS-Beispiel unten an.
deploymentPath(Zeichenfolge): Optional. Der relative Pfad vom Dienstpfad zu den k8s-Bereitstellungsmanifesten. Wenn diese Einstellung festgelegt ist, überschreibt sie den Standardmäßigen Bereitstellungspfadspeicherort für k8s-Bereitstellungsmanifeste. Standard: manifests; namespace(Zeichenfolge): Optional. Der k8s-Namespace der bereitgestellten Ressourcen. Wenn angegeben, wird ein neuer k8s-Namespace erstellt, wenn er noch nicht vorhanden ist. Standard: Project name; deployment(Objekt): Siehe Bereitstellungseigenschaften; service(Objekt): Siehe Diensteigenschaften; ingress(Objekt): Siehe Eingangseigenschaften.
hooks
N
Hooks auf Dienstebene. Hooks sollten service Ereignisnamen mit dem Präfix pre oder post übereinstimmen, je nachdem, wann das Skript ausgeführt werden soll. Wenn Sie Pfade angeben, sollten sie relativ zum Dienstpfad sein.
Geben Sie eine explizite api-version beim Bereitstellen von Diensten an, die von Azure Container Apps (ACA) gehostet werden. Dieses Feature hilft Ihnen, die Verwendung einer inkompatiblen API-Version zu vermeiden und die Bereitstellung lose gekoppelt zu machen, um zu vermeiden, dass während des JSON-Marshallings benutzerdefinierte Konfigurationsdaten an eine hartcodierte Azure SDK-Bibliotheksversion verloren gehen.
apiVersion: 2024-02-02-preview
Beispiel für Docker-Optionen
Im folgenden Beispiel deklarieren wir Docker-Optionen für eine Container-App.
(Zeichenfolge) Optional. Der Name der k8s-Bereitstellungsressource, die während der Bereitstellung verwendet werden soll. Wird während der Bereitstellung verwendet, um sicherzustellen, ob das Rollout der k8s-Bereitstellung abgeschlossen wurde. Wenn sie nicht festgelegt ist, wird nach einer Bereitstellungsressource im selben Namespace gesucht, der den Dienstnamen enthält. Standard: Service name
api
AKS-service-Eigenschaften
Elementname
Erforderlich
Beschreibung
Beispiel
name
N
(Zeichenfolge) Optional. Der Name der k8s-Dienstressource, die als Standarddienstendpunkt verwendet werden soll. Wird beim Ermitteln von Endpunkten für die Standarddienstressource verwendet. Wenn sie nicht festgelegt ist, wird nach einer Bereitstellungsressource im selben Namespace gesucht, der den Dienstnamen enthält. (Standard: Dienstname)
api
AKS-ingress-Eigenschaften
Elementname
Erforderlich
Beschreibung
Beispiel
name
N
(Zeichenfolge) Optional. Der Name der k8s-Eingangsressource, die als Standarddienstendpunkt verwendet werden soll. Wird beim Ermitteln von Endpunkten für die Standardeinstiegsressource verwendet. Wenn sie nicht festgelegt ist, wird nach einer Bereitstellungsressource im selben Namespace gesucht, der den Dienstnamen enthält. Standard: Service name
api
relativePath
N
(Zeichenfolge) Optional. Der relative Pfad zum Dienst vom Stamm des Eingangscontrollers. Wenn festgelegt, wird an den Stamm des Eingangsressourcenpfads angefügt.
AKS-Beispiel mit Hooks auf Dienstebene
metadata:
template: todo-nodejs-mongo-aks@0.0.1-beta
services:
web:
project: ./src/web
dist: build
language: js
host: aks
hooks:
postdeploy:
shell: sh
run: azd env set REACT_APP_WEB_BASE_URL ${SERVICE_WEB_ENDPOINT_URL}
api:
project: ./src/api
language: js
host: aks
k8s:
ingress:
relativePath: api
hooks:
postdeploy:
shell: sh
run: azd env set REACT_APP_API_BASE_URL ${SERVICE_API_ENDPOINT_URL}
pipeline-Eigenschaften
Elementname
Erforderlich
Beschreibung
Beispiel
provider
N
(Zeichenfolge) Der Pipelineanbieter, der für die kontinuierliche Integration verwendet werden soll. (Standard: github).
Wenn angegeben, wird das Standardverhalten für den Azd up-Workflow außer Kraft setzen.
up-Eigenschaften
Elementname
Art
Erforderlich
Beschreibung
Schritte
Anordnung
Ja
Die Schritte, die im Workflow ausgeführt werden sollen.
steps-Eigenschaften
Elementname
Art
Erforderlich
Beschreibung
azd
Schnur
Ja
Der Name und die Argumente des auszuführenden Azd-Befehls.
Beispielworkflow
Im folgenden azure.yaml Datei wird das Standardverhalten von azd up geändert, um den azd package Schritt nach dem azd provision Schritt mithilfe eines Workflows zu verschieben. Dieses Beispiel kann in Szenarien verwendet werden, in denen Sie die URLs von Ressourcen während des Build- oder Verpackungsprozesses kennen müssen.
Informationen zum Ablegen eines Fehlers, Anfordern von Hilfe oder Vorschlagen eines neuen Features für die Azure Developer CLI finden Sie auf der Seite Problembehandlung und Support.