azd Vorlagen sind Blaupausenrepositorys, die Code für Anwendungsprüfung, 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 mit der Azure Developer CLI (azdAzure Developer CLI) auf Azure angewendet werden. Das Azure.yaml-Schema definiert und beschreibt die Apps und Typen von Azure-Ressourcen, die in diesen Vorlagen enthalten sind.
Beispiel
Nachfolgend finden Sie ein generisches Beispiel für azd eine azure.yaml erforderliche Vorlage.
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 Details finden Sie in den Infrastruktureigenschaften .
services
J
(Objekt) Definition der Dienste, die die Anwendung umfassen. Weitere Informationen finden Sie in den Diensteigenschaften .
pipeline
N
(Objekt) Definition der kontinuierlichen Integrationspipeline. Weitere Details finden Sie unter Pipelineeigenschaften .
hooks
N
Hooks auf Befehlsebene. Hooks sollten befehlsnamen mit dem Präfix pre oder post abhängig vom Ausführen des Skripts übereinstimmenazd. Beim Angeben von Pfaden sollten sie relativ zum Projektpfad sein. Weitere Details finden Sie unter Anpassen Ihrer Azure Developer CLI-Workflows mit Befehls- und Ereignishaken .
requiredVersions
N
Eine Reihe unterstützter Versionen für azd dieses Projekt. Wenn sich die Version außerhalb azd 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, azd wird nach einer Ressource nach azd-env-name und azd-service-name tags gesucht. Wenn sie nicht gefunden wird, wird nach einem Ressourcennamen gesucht, der aus dem aktuellen Umgebungsnamen erstellt wurde und mit dem Dienstnamen (<environment-name><resource-name>) verkettet ist.
prodapi
project
J
(Zeichenfolge) Pfad zum Dienstquellcodeverzeichnis.
host
J
(Zeichenfolge) Typ der Azure-Ressource, die für die Dienstimplementierung verwendet wird. Wenn diese Angabe weggelassen wird, wird der App-Dienst angenommen.
appservice, , functioncontainerapp, staticwebapp, aks ( nur für Projekte, die über ) bereitgestellt werden können kubectl apply -f), springapp (wenn aktiviert – weitere Informationen zu Alpha-Features)
language
J
(Zeichenfolge) Dienstimplementierungssprache.
dotnet, csharp, fsharp, py, python, js, ts, java
module
J
(Zeichenfolge) Pfad des Infrastrukturmoduls, das zum Bereitstellen des Diensts relativ zum Stamm-Infrastrukturordner verwendet wird. Wenn dies nicht angegeben wird, geht die CLI davon aus, dass der Modulname mit dem Dienstnamen identisch ist.
dist
J
(Zeichenfolge) Relativer 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 host dies der Fall ist containerapp. Keine zusätzlichen Eigenschaften enthalten.
Sehen Sie sich das benutzerdefinierte Docker-Beispiel unten an. path(string): Pfad zur Dockerfile-Datei. Standard: ./Dockerfile; context(string): Der Docker-Buildkontext. Wenn angegeben, überschreibt der Standardkontext. Standard: .; platform(string): Das Plattformziel. Standard: amd64
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 Ingresseigenschaften.
hooks
N
Hooks auf Dienstebene. Hooks sollten ereignisnamen mit pre dem Präfix oder post abhängig vom Ausführen des Skripts übereinstimmenservice. Wenn Sie Pfade angeben, sollten sie relativ zum Dienstpfad sein.
(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-Eigenschaften service
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-Eigenschaften ingress
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).
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 ".