Vue d’ensemble des modèles Azure Developer CLI
Les modèles Azure Developer CLI (azd
) sont des référentiels de code standard qui incluent des exemples de code d’application, ainsi que des fichiers de configuration et d’infrastructure azd
. Les modèles azd
vous permettent de provisionner des ressources Azure, de déployer votre application, de configurer des pipelines CI/CD, etc. Vous pouvez créer vos propres modèles ou commencer à utiliser un modèle existant à partir d’un référentiel de modèles tel que Awesome AZD. Cet article porte sur les concepts suivants :
- Comment les modèles
azd
vous permettent de provisionner et de déployer des ressources d’application - Comment les modèles
azd
sont structurés - Comment décider s’il faut utiliser un modèle existant ou en créer un
- Découverte des des modèles de démarrage
azd
existants
Pourquoi utiliser les modèles Azure Developer CLI ?
Les développeurs sont souvent confrontés à de nombreuses tâches fastidieuses et difficiles lors de la création d’applications d’environnement correctement architecturées et configurées pour le cloud. Les équipes doivent prendre en compte de nombreuses problématiques différentes dans ces environnements, comme la création de ressources, l’application de configurations, la configuration de la supervision et de la journalisation, la création de pipelines CI/CD et d’autres tâches. Les modèles azd
réduisent et rationalisent ces responsabilités pour aider le développeur dans son parcours, du développement local au déploiement réussi d'une application sur Azure.
Par exemple, supposons que vous travaillez dans une entreprise qui exploite une plateforme de gestion des tickets et de communication client, ce qui nécessite les ressources Azure suivantes :
- Deux instances d'App Service et un plan App Service pour héberger une application web front-end et l’API back-end
- Une instance Key Vault pour stocker les secrets d’application sécurisés
- Une base de données Cosmos DB pour stocker les données d’application de manière permanente
- Des ressources Azure Monitor comme les tableaux de bord Application Insights
- Une instance Service Bus pour gérer une messagerie évolutive
- Des pipelines CI/CD pour s’assurer que les modifications peuvent être déployées de façon fiable via un processus automatisé et reproductible.
Au lieu de partir de zéro, avec azd
, vous pouvez utiliser les modèles d’architecture existants pour provisionner et déployer la plupart des ressources pour vous. L’équipe de développement peut ensuite se concentrer sur la création de l’application et sur des ajustements mineurs de l’architecture du modèle.
Fonctionnement des modèles Azure Developer CLI
Les modèles Azure Developer CLI sont conçus pour fonctionner avec des commandes azd
telles que azd init
et azd up
. Ces modèles incluent des fichiers de configuration et d’infrastructure en tant que code (IaC) que les commandes utilisent pour effectuer des tâches telles que le provisionnement de ressources Azure et le déploiement du code d’application sur ces dernières.
Par exemple, un workflow azd
classique utilisant un modèle existant comprend les phases suivantes :
Exécutez la commande
azd init
avec le paramètre--template
pour cloner un modèle existant à partir de GitHub.azd init --template todo-nodejs-mongo
Exécutez la commande
azd auth login
pour vous authentifier auprès de votre abonnement Azure.azd auth login
Exécutez la commande
azd up
pour provisionner et déployer les ressources de modèle sur Azure. La commandeazd up
utilise les fichiers de configuration et d’infrastructure en tant que code (IaC) de votre modèle pour provisionner des ressources Azure et déployer votre application sur ces ressources.azd up
Une fois votre environnement configuré dans Azure, vous pouvez modifier localement les fonctionnalités de l’application ou les modèles de ressources Azure, puis réexécuter
azd up
pour provisionner vos modifications.
Comprendre la structure du modèle Azure Developer CLI
Tous les modèles azd
partagent une structure de fichier similaire basée sur les conventions azd
. Les ressources minimales requises incluent généralement les éléments suivants :
Dossier
infra
- Contient l’ensemble de l’infrastructure Bicep ou Terraform en tant que fichiers de code pour le modèleazd
.azd
exécute ces fichiers pour créer les ressources Azure nécessaires à l’hébergement de votre application.Fichier
azure.yaml
: fichier de configuration qui définit un ou plusieurs services dans votre projet, et les mappe aux ressources Azure définies dans le dossierinfra
pour le déploiement. Par exemple, vous pouvez définir un service d’API et un service web front-end, puis les mapper à différentes ressources Azure pour le déploiement.Dossier
.azure
- Contient des configurations Azure et des variables d’environnement essentielles, comme l’emplacement de déploiement des ressources ou d’autres informations liées à l’abonnement.Dossier
src
- Contient tout le code source de l’application déployable. Certains modèlesazd
excluent le dossiersrc
et fournissent uniquement les ressources d'infrastructure nécessaires pour vous permettre d’ajouter votre propre code d’application.Remarque
Les modèles qui excluent le dossier
src
sont généralement conçus en tant que modèles de démarrage d’infrastructure.
Les modèles azd
incluent également en option un ou plusieurs des dossiers suivants :
- Dossier
.github
- Contient les fichiers de workflow CI/CD pour GitHub Actions, qui est le fournisseur CI/CD par défaut pour azd. - Dossier
.azdo
- Si vous décidez d’utiliser Azure Pipelines pour CI/CD, définissez les fichiers de configuration de workflow dans ce dossier. - Dossier
.devcontainer
- Vous permet de configurer un environnement de conteneurs de développement pour votre application.
Par exemple, un modèle azd
courant peut correspondre à la structure de dossier suivante :
Démarrer avec un modèle existant ou créer votre propre modèle
Il existe deux approches principales pour travailler avec des modèles azd
:
- Démarrer avec un modèle
azd
existant.- Il s’agit d’un choix judicieux si vous débutez avec
azd
ou si vous cherchez un modèle pour créer une nouvelle application avec une architecture et des frameworks similaires.
- Il s’agit d’un choix judicieux si vous débutez avec
- Convertissez un projet existant en modèle
azd
.- Il s’agit d’un choix judicieux lorsque vous disposez déjà d’une application existante, mais que vous souhaitez la rendre compatible avec les fonctionnalités
azd
.
- Il s’agit d’un choix judicieux lorsque vous disposez déjà d’une application existante, mais que vous souhaitez la rendre compatible avec les fonctionnalités
Les sections suivantes fournissent des informations supplémentaires sur ces deux options.
Démarrer avec un modèle existant
Un large choix de modèles azd
sont disponibles dans la galerie de modèles awesome-azd . Ces modèles fournissent du code d’infrastructure et d’application pour différents scénarios de développement, frameworks de langage et services Azure. Si vous trouvez un modèle conforme à votre pile d’applications locale ou à l’architecture souhaitée, vous pouvez étendre et remplacer le code du modèle par le vôtre.
Par exemple, les modèles azd
suivants fournissent des points de départ pour les architectures et frameworks d'application courants :
Créez un nouveau modèle azd
pour votre application
Vous pouvez également convertir une application existante en modèle azd
pour enrichir le référentiel avec des fonctionnalités de provisionnement et de déploiement. Cette approche est celle qui permet d'exercer le plus de contrôle et de produire une solution réutilisable pour les futurs travaux de développement de l'application. Les grandes étapes pour créer votre propre modèle sont les suivantes :
- Initialiser le modèle de projet avec
azd init
. - Créer les fichiers de l’infrastructure en tant que code Bicep ou Terraform dans le dossier
infra
. - Mettre à jour le fichier
azure.yaml
pour lier les services d’application avec les ressources Azure. - Approvisionner et déployer avec
azd up
.
Les ressources suivantes fournissent plus d'informations sur la création de vos propres modèles :
Instructions pour l’utilisation des modèles azd
Notez que chaque modèle que vous utilisez avec Azure Developer CLI est concédé sous licence par son propriétaire respectif (qui peut ou non être Microsoft) dans le cadre du contrat qui accompagne le modèle. Il vous incombe de déterminer quelle licence s’applique au modèle que vous choisissez d’utiliser.
Microsoft n'est pas responsable des modèles non Microsoft et n'examine pas ces modèles du point de vue de la sécurité, de la confidentialité, de la compatibilité ou des performances. Les modèles que vous utilisez avec Azure Developer CLI, y compris ceux fournis par Microsoft, ne sont pas pris en charge par un programme ou un service de support Microsoft. Tous les modèles fournis par Microsoft sont fournis EN L’ÉTAT sans garantie d’aucune sorte.