Vue d’ensemble des modèles Azure Developer CLI

Un modèle Azure Developer CLI (azd) est un dépôt de code qui respecte les conventions azd. Il combine la configuration du projet, l’infrastructure en tant que code et la source d’application facultative afin de créer des environnements et des déploiements Azure reproductibles.

Les modèles peuvent prendre en charge différents types de projets, notamment :

  • Une application complète avec un ou plusieurs services déployables.
  • Solution d’infrastructure uniquement sans code d’application.
  • Point de départ réutilisable que un autre développeur peut initialiser et étendre.
  • Projet existant que vous préparez pour la mise en service et le déploiement avec azd.

Cet article explique la structure d’un modèle et la façon dont azd les commandes utilisent ses fichiers.

Pourquoi utiliser un modèle ?

Un modèle capture les décisions requises pour exécuter un projet sur Azure. Selon le projet, il peut définir :

  • Azure ressources et leur configuration.
  • Services applicatifs déployables et instructions de packaging.
  • Connexions entre les services d’application et les ressources Azure.
  • Paramètres et sorties spécifiques à l’environnement.
  • Développement local, intégration continue et configuration de la livraison continue.

Étant donné que la configuration est stockée avec le projet, les équipes peuvent examiner les modifications apportées au contrôle de code source et créer des environnements de développement, de test et de production cohérents.

Comment azd utilise un modèle

Les fichiers d’un modèle prennent en charge différentes étapes du azd flux de travail :

  • azd init initialise le projet et crée un azd environnement. Il peut également utiliser GitHub Copilot pour générer un modèle initial ou copier un modèle existant.
  • azd provisionévalue les définitions d’infrastructure et crée ou met à jour des ressources Azure.
  • azd package prépare les services d’application déployables en fonction de azure.yaml.
  • azd deployassocie chaque service à son hôte Azure et déploie le package d’application.
  • azd up exécute les étapes d’approvisionnement, d’empaquetage et de déploiement en tant que flux de travail combiné.

Les fichiers de modèle restent des fichiers sources réguliers tout au long de ce processus. Vous pouvez les consulter, les modifier et les versionr avec le reste du projet.

Explorer la structure du modèle Azure Developer CLI

azd les modèles sont des référentiels de code standard avec des ressources de configuration et d’infrastructure supplémentaires. La plupart des modèles utilisent la structure suivante :

  • azure.yaml fichier : définit le projet et mappe les répertoires sources déployables aux ressources Azure.
  • infra dossier : contient les fichiers d’infrastructure en tant que code Bicep ou Terraform qui créent les ressources Azure.
  • src dossier : contient généralement du code source d’application déployable. Les modèles d’infrastructure uniquement peuvent omettre la source de l’application et les modèles d’application peuvent utiliser d’autres noms de répertoires sources.
  • .azure dossier : contient des environnements et des valeurs locaux créés par azd. Ce dossier est l’état du projet local et n’est normalement pas partagé dans le cadre d’un modèle réutilisable.

Par exemple, un modèle azd courant peut correspondre à la structure de dossier suivante :

contoso-project/
├── azure.yaml                 # azd project and service configuration
├── infra/
│   ├── main.bicep            # Infrastructure entry point
│   └── main.parameters.json  # Maps azd values to Bicep parameters
├── src/                      # Optional application source
│   ├── api/
│   └── web/
├── .github/workflows/        # Optional GitHub Actions pipelines
└── .azure/                   # Local environment state; don't distribute

Les modèles azd incluent également en option un ou plusieurs des dossiers suivants :

  • .github dossier : contient les fichiers de flux de travail CI/CD pour GitHub Actions.
  • .azdo Dossier - Si vous décidez d’utiliser Azure Pipelines pour CI/CD, définissez les fichiers de configuration de workflow dans ce dossier.
  • .devcontainer dossier : définit un environnement de conteneur de développement pour le projet.

Le diagramme suivant montre comment les ressources du modèle principal fonctionnent ensemble :

flowchart LR
AZ[azure.yaml] -->|Defines services| SRC[Application source]
AZ -->|Selects provider and path| INFRA[Infrastructure as code]
INFRA -->|Provisions| RES[Azure resources]
INFRA -->|Exports values| ENV[azd environment]
ENV -->|Configures| SRC
AZ -->|Maps services to| RES

Ressources obligatoires et facultatives

La structure exacte varie selon le projet, mais la plupart des modèles utilisent les ressources suivantes.

azure.yaml

Le azure.yaml fichier est le fichier de configuration du projet principal. Il définit le nom du projet et peut définir des services déployables, des fournisseurs d’infrastructure, des hooks, des flux de travail et d’autres azd comportements.

Pour un service d’application, azure.yaml identifie généralement :

  • Chemin d’accès à la source de l’application.
  • Langage de programmation ou stratégie d’empaquetage.
  • Service Azure qui héberge l’application.
  • Paramètres de génération, de déploiement, de conteneur ou de Kubernetes.

Les modèles d’infrastructure uniquement peuvent omettre les services d’application. Pour obtenir le modèle de configuration complet, consultez le azure.yaml schéma.

L’exemple suivant définit deux services d’application. Les noms de service, les chemins d’accès source, les langues et les cibles d’hébergement indiquent azd ce qu’il faut empaqueter et où le déployer :

name: store
services:
  api:
    project: ./src/api
    language: js
    host: containerapp
  web:
    project: ./src/web
    language: js
    host: staticwebapp

Infrastructure en tant que code

La plupart des modèles contiennent un infra répertoire avec des fichiers Bicep ou Terraform. Ces fichiers définissent les ressources Azure, les attributions de rôles, la mise en réseau, les paramètres d’application et les sorties de déploiement requises par le projet.

Pour le fournisseur de Bicep par défaut, azd utilise infra/main.bicep généralement comme point d’entrée de déploiement et infra/main.parameters.json pour mapper azd les valeurs d’environnement aux paramètres Bicep. Les modèles Terraform utilisent infra/main.tf généralement et les fichiers Terraform associés.

Par exemple, un fichier de paramètres Bicep peut transmettre au déploiement de l’infrastructure des valeurs sélectionnées par azd :

{
  "parameters": {
    "environmentName": { "value": "${AZURE_ENV_NAME}" },
    "location": { "value": "${AZURE_LOCATION}" }
  }
}

Lorsque le provisionnement Bicep se termine, azd stocke les données de sortie du point d’entrée comme valeurs d’environnement. Les services d’application et les hooks peuvent utiliser ces valeurs pour les points de terminaison de ressources, les noms et d’autres configurations d’exécution.

output API_ENDPOINT string = api.outputs.uri

Source de l’application

La source de l’application est facultative. Lorsqu’un modèle contient des services déployables, chaque définition de service pointe vers azure.yaml son répertoire source. Un modèle peut organiser les services sous src, utiliser des répertoires ailleurs dans le référentiel ou pointer un service à la racine du référentiel.

Le nom du dossier lui-même n’est pas significatif. La project valeur dans azure.yaml détermine où azd se trouve chaque service.

Configuration de l’environnement

Le répertoire contient l’état .azure et les valeurs de l’environnement local créés par azd. Il peut contenir des valeurs d’abonnement, d’emplacement, de nom de ressource, de point de terminaison et de sortie de déploiement pour plusieurs environnements.

Traitez ce répertoire comme un état local plutôt qu’une ressource de modèle réutilisable. Ne validez pas les fichiers d’environnement qui contiennent des secrets ou des valeurs propres à l’environnement.

Ressources d’accompagnement

Les modèles peuvent également contenir les éléments suivants :

  • définitions de GitHub Actions ou d’Azure Pipelines.
  • Fichiers Dockerfile et configuration des conteneurs.
  • Configuration du conteneur de développement.
  • Hooks de commande et de service.
  • Tests, scripts et documentation de projet.

Ces ressources sont facultatives et doivent être incluses uniquement lorsqu’elles prennent en charge l’expérience de modèle prévue.

Association de services et de ressources

Pour déployer un service d’application, azd devez associer sa définition à azure.yaml une ressource de Azure provisionnée. Par défaut, azd recherche une ressource dont azd-service-name l’étiquette correspond au nom du service.

Par exemple, un service nommé api correspond à une ressource étiquetée avec azd-service-name: api. Vous pouvez utiliser plutôt la propriété de resourceName service pour identifier explicitement la cible de déploiement.

L'expression Bicep suivante ajoute la balise de découverte aux balises existantes d'une ressource :

tags: union(tags, {
  'azd-service-name': 'api'
})

Conservez les noms de service, les paramètres de découverte des ressources, les sorties d’infrastructure et les variables d’environnement d’application alignées lorsque vous modifiez un modèle.

Créer ou adapter un modèle

L’expérience de création recommandée consiste à exécuter azd init et à sélectionner Configurer avec GitHub Copilot (aperçu). La session de assistant Copilot dédiée peut analyser les fichiers existants, planifier un nouveau projet, générer des ressources de modèle et valider le résultat. Pour ce flux de travail et d’autres méthodes de création, consultez Démarrer avec un nouveau modèle.

Les fichiers générés ne sont pas liés à Copilot. Vous pouvez explorer et modifier les fichiers de modèle directement après l’initialisation. Vous pouvez également créer les mêmes fichiers manuellement ou avec un autre agent de codage IA.

Si un modèle de Microsoft, votre organisation ou la communauté des développeurs fournit déjà une architecture utile, commencez par le modèle existant et adaptez-le à votre projet. Parcourez les modèles disponibles dans les galeries de modèles.

Recommandations relatives à l’utilisation des modèles

Chaque modèle est concédé sous licence par son propriétaire sous le contrat qui accompagne le modèle. Déterminez la licence qui s’applique avant d’utiliser ou de distribuer un modèle.

Microsoft n'est pas responsable des modèles non Microsoft et ne les détecte pas pour des problèmes de sécurité, de confidentialité, de compatibilité ou de performances. Les modèles, y compris les modèles Microsoft fournis, ne sont pas pris en charge par un programme ou un service de support Microsoft et sont fournis tel quel sans garantie.

Passez en revue tous les fichiers de modèle avant l’approvisionnement. En particulier, évaluez les attributions de rôles, l’exposition réseau, les méthodes d’authentification, les niveaux de service, les emplacements de ressources et les coûts attendus.

Étapes suivantes

Vue d’ensemble du développement de modèles

  • Last updated on