Informations de référence sur le schéma Azure Developer CLI

Le azure.yaml fichier est le fichier de configuration pour les projets Azure Developer CLI (azd). Placez-le à la racine de votre projet pour définir les services, les ressources Azure, l’infrastructure, les hooks et le pipeline CI/CD qui composent votre application. Lorsque vous exécutez des commandes telles que azd up, azd provisionou azd deploy, l’interface CLI lit ce fichier pour comprendre la structure de votre application et comment la déployer sur Azure.

Cet article est une référence complète pour le schéma azure.yaml. Pour bien démarrer avec azd les modèles, consultez la vue d’ensemble des modèles CLI pour développeurs Azure.

Échantillon

Voici un exemple générique de azure.yaml fichier pour un azd modèle. Pour obtenir un exemple réel, consultez le azure.yamlmodèle Mongo ToDo NodeJs :

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

Propriétés de niveau supérieur

name

(chaîne, obligatoire) Nom de l’application. Seules les lettres minuscules, les chiffres et les traits d’union (-) sont autorisés. Le nom doit commencer et se terminer par une lettre ou un chiffre. Longueur minimale : 2 caractères.

name: my-app

resourceGroup

(chaîne) Nom du groupe de ressources Azure. Lorsqu’il est spécifié, remplace le nom du groupe de ressources utilisé pour l’approvisionnement d’infrastructure. Prend en charge la substitution de variable d’environnement. Doit être compris entre 3 et 64 caractères.

resourceGroup: rg-my-app-${AZURE_ENV_NAME}

metadata

(objet) Métadonnées relatives au modèle d’application.

metadata:
  template: todo-nodejs-mongo@0.0.1-beta

infra

(objet) Fournit une configuration supplémentaire pour l’approvisionnement d’infrastructure Azure.

infra.layers

(tableau d’objets) Définit des couches d’approvisionnement pour l’infrastructure Azure. Chaque couche représente une unité indépendante d’approvisionnement.

infra:
  provider: bicep
  layers:
    - name: core
      path: ./infra/core
    - name: services
      path: ./infra/services
      hooks:
        postprovision:
          shell: sh
          run: ./scripts/post-provision.sh

Terraform en tant qu’exemple de fournisseur IaC

Pour utiliser Terraform au lieu de Bicep, définissez la valeur providerterraform. Pour plus d’informations, consultez Utiliser Terraform comme 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

services

(objet) Définition des services qui composent l’application. Chaque clé est un nom de service et la valeur est un objet de configuration de service.

Propriétés du service

Types d’hôtes

La host propriété détermine le type de ressource Azure utilisé pour l’implémentation de service et les contrôles qui sont valides.

ai.endpoint Config

(objet, obligatoire quand host c’est ai.endpoint) Fournit une configuration supplémentaire pour le déploiement de points de terminaison en ligne Azure AI.

Configuration des composants IA

Configuration du déploiement d’IA

Hérite de toutes les propriétés de la configuration du composant IA, ainsi que :

services:
  myendpoint:
    project: ./src/endpoint
    host: ai.endpoint
    config:
      workspace: my-ai-project
      deployment:
        path: ./deployment
        environment:
          MODEL_NAME: ${AZURE_OPENAI_MODEL}

docker

(objet) Configuration Docker pour un service. Applicable uniquement aux hôtes qui prennent en charge les conteneurs (containerapp, aks, ai.endpoint, azure.ai.agent).

k8s

(objet) Options de configuration d’Azure Kubernetes Service (AKS). Valide uniquement quand host est aks.

Configuration du déploiement

Configuration du service

Configuration d’entrée

Configuration Helm

repositories éléments de tableau :

releases éléments de tableau :

Configuration Kustomize

Crochets de service

Les hooks de niveau de service s’exécutent pendant les événements de cycle de vie du service. Les hooks doivent correspondre aux noms d’événements de service précédés pre ou post. 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.

Crochets de service pris en charge : prerestore, , , prepublishpostrestorepredeploypostpublishpostbuildprebuildprepackagepostpackage. postdeploy

Chaque hook utilise le format de définition de hook .

Exemples de service

Applications conteneur avec les options Docker

services:
  api:
    project: ./src/api
    language: js
    host: containerapp
    docker:
      path: ./Dockerfile
      context: ../
  web:
    project: ./src/web
    language: js
    host: containerapp
    docker:
      remoteBuild: true

Container Apps à partir d’une image prédéfinie

services:
  api:
    image: myregistry.azurecr.io/myapp:latest
    host: containerapp

AKS avec des hooks de niveau de service

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}

resources

(objet) Définition des ressources Azure utilisées par l’application. Chaque clé est un nom de ressource et la valeur est un objet de configuration de ressource. Les ressources peuvent être référencées par les services via la uses propriété.

Propriétés de ressources courantes

Types de ressource

La type propriété détermine le type de ressource Azure et contrôle les propriétés supplémentaires disponibles.

propriétés host.appservice

runtime Objet:

resources:
  web:
    type: host.appservice
    port: 8080
    runtime:
      stack: node
      version: 22-lts
    uses:
      - db

propriétés host.containerapp

propriétés ai.openai.model

model Objet:

resources:
  chatModel:
    type: ai.openai.model
    model:
      name: gpt-4o
      version: "2024-08-06"

propriétés ai.project

models éléments de tableau :

sku Objet:

propriétés ai.search

propriétés db.cosmos

containers éléments de tableau :

propriétés messaging.eventhubs

propriétés messaging.servicebus

propriétés storage

propriétés keyvault

Exemple de ressources

resources:
  db:
    type: db.postgres
  cache:
    type: db.redis
  chatModel:
    type: ai.openai.model
    model:
      name: gpt-4o
      version: "2024-08-06"
  web:
    type: host.containerapp
    port: 3100
    uses:
      - db
      - chatModel

pipeline

(objet) Définition du pipeline d’intégration continue.

pipeline:
  provider: azdo
  variables:
    - CUSTOM_SETTING
  secrets:
    - API_KEY

hooks

(objet) 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. Lorsque vous spécifiez des 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.

Crochets de commande pris en charge : preprovision, , , predownprerestoreprepublishpostrestorepostdeploypredeploypostpublishpostpackageprepackagepostuppreuppostinfradeletepostinfracreatepostdownpostprovisionpreinfracreatepreinfradelete.

Chaque hook utilise le format de définition de hook .

hooks:
  preprovision:
    shell: sh
    run: ./scripts/setup.sh
  postdeploy:
    shell: sh
    run: azd env set APP_URL ${SERVICE_WEB_ENDPOINT_URL}

Définition de hook

Un hook peut être un objet de crochet unique ou un tableau d’objets de crochet. Chaque objet hook a les propriétés suivantes :

Configuration de l’exécuteur de hook

La config propriété accepte différentes propriétés en fonction de la kind valeur.

Configuration JavaScript et TypeScript (js, ts)

Configuration Python

Configuration .NET (dotnet)

Shell (sh, pwsh) config

Les exécuteurs shell ne prennent actuellement pas en charge config les propriétés.

Exemples de crochets

Crochets spécifiques à la plateforme

hooks:
  preprovision:
    windows:
      shell: pwsh
      run: ./scripts/setup.ps1
    posix:
      shell: sh
      run: ./scripts/setup.sh

Crochet Python avec un type

hooks:
  postprovision:
    kind: python
    run: ./scripts/seed-data.py
    dir: ./scripts
    config:
      virtualEnvName: .venv

Crochets multiples pour un seul événement

hooks:
  postprovision:
    - shell: sh
      run: ./scripts/step1.sh
    - shell: sh
      run: ./scripts/step2.sh

requiredVersions

(objet) Fournit une configuration supplémentaire pour les versions azd et extensions requises.

requiredVersions:
  azd: ">= 0.6.0-beta.3"
  extensions:
    azure.ai.agents: ">=1.0.0"
    my-extension: latest

state

(objet) Fournit une configuration supplémentaire pour la gestion de l’état.

state.remote

Configuration du Stockage Blob Azure

state:
  remote:
    backend: AzureBlobStorage
    config:
      accountName: mystorageaccount
      containerName: azd-state

platform

(objet) Fournit une configuration supplémentaire pour les fonctionnalités spécifiques à la plateforme, telles que le Centre de développement Azure.

Configuration du Centre de développement

Disponible quand type est devcenter:

platform:
  type: devcenter
  config:
    name: my-devcenter
    project: my-project
    catalog: my-catalog
    environmentDefinition: my-env-def
    environmentType: dev

workflows

(objet) Fournit une configuration supplémentaire pour les flux de travail tels que le comportement de azd up substitution.

Étapes de workflow

Le up flux de travail accepte un steps tableau (ou peut être spécifié directement en tant que tableau). Chaque étape exécute une azd commande.

Configurer l’ordre des étapes du flux de travail

Le fichier suivant azure.yaml modifie le comportement par défaut de déplacer azd up l’étape azd package après l’étape azd provision . Utilisez cette approche dans les 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: package
      - azd: deploy --all

cloud

(objet) Fournit une configuration supplémentaire pour le déploiement sur des clouds souverains tels qu’Azure Government. Le cloud par défaut est AzureCloud.

cloud:
  name: AzureUSGovernment

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

• Personnaliser des flux de travail à l’aide de hooks de commande et d’événements
• Vue d’ensemble des modèles AZURE Developer CLI
• Utiliser Terraform comme fournisseur IaC
• Gérer les variables d’environnement