Partager via

Schéma Azure Developer CLI azure.yaml

  • Article

azd les modèles sont des référentiels de blueprint qui incluent du code d’application de preuve de concept, des configurations d’éditeur/IDE et du code d’infrastructure écrit dans Bicep ou Terraform. Ces modèles sont destinés à être modifiés et adaptés à vos exigences d’application spécifiques, puis utilisés pour obtenir votre application sur Azure à l’aide d’Azure Developer CLI (azd). Le schéma azure.yaml définit et décrit les applications et les types de ressources Azure incluses dans ces modèles.

Exemple

Vous trouverez ci-dessous un exemple générique d’un azure.yaml modèle requis azd .

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

Comparez avec le azure.yamlmodèle ToDo NodeJs Mongo :

name: todo-nodejs-mongo
metadata:
  template: todo-nodejs-mongo@0.0.1-beta
services:
  web:
    project: ./src/web
    dist: build
    language: js
    host: appservice
  api:
    project: ./src/api
    language: js
    host: appservice

Description des propriétés

Nom de l’élément Obligatoire Description
name Y (chaîne) Nom de l’application.
resourceGroup N (chaîne) Nom du groupe de ressources Azure. Une fois spécifié, remplace le nom du groupe de ressources utilisé pour l’approvisionnement d’infrastructure.
metadata N (objet) Pour plus d’informations, consultez les propriétés des métadonnées.
infra N (objet) Fournit une configuration supplémentaire pour l’approvisionnement d’infrastructure Azure. Pour plus d’informations, consultez les propriétés infra.
services Y (objet) Définition des services qui composent l’application. Pour plus d’informations, consultez les propriétés des services.
pipeline N (objet) Définition du pipeline d’intégration continue. Pour plus d’informations, consultez les propriétés du pipeline.
hooks N Crochets au niveau de la commande. Les hooks doivent correspondre aux azd noms de commandes préfixés pre ou post selon le moment où le script doit s’exécuter. Lors de la spécification de chemins d’accès, ils doivent être relatifs au chemin du projet. Pour plus d’informations, consultez Personnaliser vos flux de travail Azure Developer CLI à l’aide des hooks de commande et d’événements .
requiredVersions N Plage de versions prises en charge pour azd ce projet. Si la version de azd cette plage est en dehors de cette plage, le projet ne peut pas être chargé. Facultatif (autorise toutes les versions en cas d’absence). Exemple : >= 0.6.0-beta.3

Propriétés de metadata

Nom de l’élément Obligatoire Description Exemple
template N (chaîne) Identificateur du modèle à partir duquel l’application a été créée. todo-nodejs-mongo@0.0.1-beta

Propriétés de infra

Nom de l’élément Obligatoire Description Exemple
provider N (chaîne) Fournisseur d’infrastructure pour les ressources Azure de l’application. (Par défaut : bicep). Consultez l’exemple Terraform ci-dessous. bicep, terraform
path N (chaîne) Chemin d’accès du dossier relatif à l’emplacement contenant des modèles d’approvisionnement Azure pour le fournisseur spécifié. (Valeur par défaut : infra).
module N (chaîne) Nom du module par défaut avec les modèles d’approvisionnement Azure. (Valeur par défaut : main).

Terraform en tant qu’exemple de fournisseur IaC

name: yourApp-terraform
metadata:
  template: yourApp-terraform@0.0.1-beta
services:
  web:
    project: ./src/web
    dist: build
    language: js
    host: appservice
  api:
    project: ./src/api
      language: js
      host: appservice
infra:
  provider: terraform

Propriétés de services

Nom de l’élément Obligatoire Description Exemple
resourceName N (chaîne) Nom de la ressource Azure qui implémente le service. S’il n’est pas spécifié, azd recherche une ressource par azd-env-name et azd-service-name des balises. S’il est introuvable, il recherche un nom de ressource construit à partir du nom de l’environnement actuel, concaténé avec le nom du service (<environment-name><resource-name>). prodapi
project Y (chaîne) Chemin d’accès au répertoire de code source du service.
host Y (chaîne) Type de ressource Azure utilisée pour l’implémentation de service. S’il est omis, App Service est supposé. appservice, , , , , (uniquement pour les projets déployables via kubectl apply -f), springapp (quand activé - en savoir plus sur les fonctionnalités alpha) aksstaticwebappfunctioncontainerapp
language Y (chaîne) Langage d’implémentation de service. dotnet, csharp, fsharp, py, python, js, ts, java
module Y (chaîne) Chemin du module d’infrastructure utilisé pour déployer le service par rapport au dossier infra racine. Si elle est omise, l’interface CLI suppose que le nom du module est identique au nom du service.
dist Y (chaîne) Chemin relatif des artefacts de déploiement de service. L’interface CLI utilise des fichiers sous ce chemin d’accès pour créer l’artefact de déploiement (fichier .zip). S’il est omis, tous les fichiers sous le répertoire du projet de service sont inclus. build
docker N Applicable uniquement lorsque host c’est containerapp. Impossible de contenir des propriétés supplémentaires. Consultez l’exemple Docker personnalisé ci-dessous. path(chaîne) : chemin d’accès au fichier Dockerfile. Valeur par défaut : ; ./Dockerfilecontext(chaîne) : contexte de build Docker. Quand elle est spécifiée, remplace le contexte par défaut. Valeur par défaut : ; .platform(chaîne) : cible de la plateforme. Valeur par défaut : amd64
k8s N Options de configuration d’Azure Kubernetes Service (AKS). Consultez l’exemple AKS ci-dessous. deploymentPath(chaîne) : Facultatif. Chemin relatif du chemin d’accès du service aux manifestes de déploiement k8s. Quand elle est définie, elle remplace l’emplacement du chemin de déploiement par défaut pour les manifestes de déploiement k8s. Valeur par défaut : ; manifestsnamespace(chaîne) : Facultatif. Espace de noms k8s des ressources déployées. Une fois spécifié, un nouvel espace de noms k8s est créé s’il n’existe pas déjà. Valeur par défaut : ; Project namedeployment(objet) : Voir les propriétés de déploiement ; service(objet) : Voir les propriétés du service ; ingress(objet) : voir les propriétés d’entrée.
hooks N Crochets de niveau de service. Les hooks doivent correspondre aux service noms d’événements précédés pre ou post en fonction du moment où le script doit s’exécuter. Lorsque vous spécifiez des chemins d’accès, ils doivent être relatifs au chemin du service. Pour plus d’informations, consultez Personnaliser vos flux de travail Azure Developer CLI à l’aide des hooks de commande et d’événements .

Exemple d’options Docker

Dans l’exemple suivant, nous déclarons les options Docker pour une application conteneur.

name: yourApp-aca
metadata:
    template: yourApp-aca@0.0.1-beta
services:
  api:
    project: ./src/api
    language: js
    host: containerapp
    docker:
      path: ./Dockerfile
      context: ../
  web:
    project: ./src/web
    language: js
    host: containerapp

Propriétés AKS deployment

Nom de l’élément Obligatoire Description Exemple
name N (chaîne) Optionnel. Nom de la ressource de déploiement k8s à utiliser pendant le déploiement. Utilisé pendant le déploiement pour vous assurer que le déploiement du déploiement de k8s a été terminé. S’il n’est pas défini, recherche une ressource de déploiement dans le même espace de noms que celui qui contient le nom du service. Valeur par défaut : Service name api

Propriétés AKS service

Nom de l’élément Obligatoire Description Exemple
name N (chaîne) Optionnel. Nom de la ressource de service k8s à utiliser comme point de terminaison de service par défaut. Utilisé lors de la détermination des points de terminaison pour la ressource de service par défaut. S’il n’est pas défini, recherche une ressource de déploiement dans le même espace de noms que celui qui contient le nom du service. (Valeur par défaut : Nom du service) api

Propriétés AKS ingress

Nom de l’élément Obligatoire Description Exemple
name N (chaîne) Optionnel. Nom de la ressource d’entrée k8s à utiliser comme point de terminaison de service par défaut. Utilisé lors de la détermination des points de terminaison pour la ressource d’entrée par défaut. S’il n’est pas défini, recherche une ressource de déploiement dans le même espace de noms que celui qui contient le nom du service. Valeur par défaut : Service name api
relativePath N (chaîne) Optionnel. Chemin d’accès relatif au service à partir de la racine de votre contrôleur d’entrée. Quand elle est définie, elle est ajoutée à la racine de votre chemin d’accès à la ressource d’entrée.

Exemple AKS avec des hooks de niveau de service

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}

Propriétés de pipeline

Nom de l’élément Obligatoire Description Exemple
provider N (chaîne) Fournisseur de pipeline à utiliser pour l’intégration continue. (Par défaut : github). github, azdo

Azure Pipelines (AzDo) en tant qu’exemple de pipeline CI/CD

name: yourApp
services:  
  web:    
    project: src/web
    dist: build
    language: js
    host: appservice
pipeline: 
  provider: azdo

Demander de l’aide

Pour plus d’informations sur la façon de déposer un bogue, de demander de l’aide ou de proposer une nouvelle fonctionnalité pour l’interface CLI développeur Azure, visitez la page de dépannage et de support .

Étapes suivantes