Partager via

Schéma Azure Developer CLI azure.yaml

  • Article

azd modèles sont des référentiels de blueprints 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.

Échantillon

Vous trouverez ci-dessous un exemple générique d’une azure.yaml requise pour votre modèle de 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 les azure.yaml à partir de notre modè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

Descriptions 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) Voir propriétés de métadonnées pour plus d’informations.
infra N (objet) Fournit une configuration supplémentaire pour l’approvisionnement d’infrastructure Azure. Pour plus d’informations, consultez propriétés infra.
services Y (objet) Définition des services qui composent l’application. Pour plus d’informations, consultez propriétés des services.
pipeline N (objet) Définition du pipeline d’intégration continue. Pour plus d’informations, consultez propriétés de pipeline.
hooks N Crochets au niveau de la commande. Les hooks doivent correspondre azd noms de commandes précédés de pre ou de post en fonction du 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 de commandes et de hooks d’événements.
requiredVersions N Plage de versions prises en charge de azd pour ce projet. Si la version de azd se trouve 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 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 infra

Nom de l’élément Obligatoire Description Exemple
provider N (chaîne) Le 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) Le chemin d’accès relatif au 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) Le 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 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 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é pour l’implémentation de service. S’il est omis, App Service est supposé. appservice, containerapp, function, staticwebapp, aks (uniquement pour les projets déployables via kubectl apply -f), springapp (quand activé - en savoir plus sur les fonctionnalités alpha )
language Y (chaîne) langage d’implémentation de service. dotnet, csharp, fsharp, py, python, js, ts, java
module Y (chaîne) chemin d’accès 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 aux 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 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. Par défaut : ./Dockerfile; context(chaîne): contexte de build Docker. Quand elle est spécifiée, remplace le contexte par défaut. Par défaut : .; platform(chaîne): cible de la plateforme. Par défaut : amd64; remoteBuild(booléen): active les builds ACR distantes. Par défaut : false
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. Par défaut : manifests; namespace(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à. Par défaut : Project name; deployment(objet): consultez propriétés de déploiement;service(objet) : voir propriétés du service; ingress(objet): voir propriétés d’entrée.
hooks N Crochets de niveau de service. Les hooks doivent correspondre service noms d’événements précédés de pre ou de 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 de commandes et de hooks d’événements.
apiVersion N Spécifiez une api-version explicite lors du déploiement de services hébergés par Azure Container Apps (ACA). Cette fonctionnalité vous permet d’éviter d’utiliser une version incompatible de l’API et rend le déploiement plus faiblement couplé pour éviter de perdre des données de configuration personnalisées pendant le marshaling JSON vers une version codée en dur de la bibliothèque du Kit de développement logiciel (SDK) Azure. apiVersion: 2024-02-02-preview

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
    docker:
      remoteBuild: true

Propriétés de deployment AKS

Nom de l’élément Obligatoire Description Exemple
name N (chaîne) Facultatif. 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. Par défaut : Service name api

Propriétés de service AKS

Nom de l’élément Obligatoire Description Exemple
name N (chaîne) Facultatif. 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 de ingress AKS

Nom de l’élément Obligatoire Description Exemple
name N (chaîne) Facultatif. 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. Par défaut : Service name api
relativePath N (chaîne) Facultatif. 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 pipeline

Nom de l’élément Obligatoire Description Exemple
provider N (chaîne) Le 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

propriétés workflows

Nom de l’élément Type Obligatoire Description
en haut objet Non Lorsque spécifié, le comportement par défaut du flux de travail azd up est substitué.

propriétés up

Nom de l’élément Type Obligatoire Description
escalier tableau Oui Étapes à exécuter dans le flux de travail.

propriétés steps

Nom de l’élément Type Obligatoire Description
azd corde Oui Nom et arguments de la commande azd à exécuter.

Exemple de flux de travail

Le fichier azure.yaml suivant modifie le comportement par défaut de azd up pour déplacer l’étape de azd package après l’étape de azd provision à l’aide d’un flux de travail. Cet exemple peut être utilisé dans des scénarios où vous devez connaître les URL des ressources pendant le processus de génération ou d’empaquetage.

name: todo-nodejs-mongo
metadata:
  template: todo-nodejs-mongo@0.0.1-beta
workflows:
  up: 
    steps:
      - azd: provision
      - azd: deploy --all

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 Azure Developer CLI, consultez la page résolution des problèmes et de support.

Étapes suivantes