Intro To Aspire 9.5 - Démarrer rapidement avec cet outil essentiel

Démarrage et installation d'Aspire 9.5

Tim commence par expliquer l'objectif d'Aspire. Tout développeur .NET qui crée des API ou des applications web doit comprendre cet outil essentiel de Microsoft. Il y a eu une certaine confusion quant aux fonctionnalités d'Aspire, c'est pourquoi Tim entreprend de démontrer son objectif, sa configuration et son utilisation à partir de zéro.

Il ouvre Visual Studio et démarre un nouveau projet en utilisant le modèle d'application de démarrage Aspire. Si vous n'avez pas installé Aspire, il vous renvoie au site web de Microsoft pour l'installation et l'outillage d'Aspire, en précisant que vous pouvez l'installer via l'interface CLI .NET, Visual Studio ou VS Code. Pour plus de simplicité, Tim recommande d'utiliser la commande CLI :

dotnet new install aspire.templates

Cela permet d'installer les derniers modèles de projet, y compris Aspire 9.5. Après l'installation, Visual Studio peut nécessiter un redémarrage pour que les modèles apparaissent.

Tim sélectionne l'application de démonstration Aspire, choisit .NET 9, active HTTPS et utilise l'intégration Redis pour la mise en cache. Il s'agit d'un scénario réel dans lequel Aspire gère localement une application complète. Il saute les tests unitaires et procède à la création des fichiers de solution.

Explorer la structure du projet et le modèle d'application

Une fois le projet généré, Tim décompose les fichiers de projet créés par le modèle d'application d'Aspire. La solution comprend quatre projets principaux qui reflètent à la fois des projets .NET typiques et des projets spécifiques à Aspire :

1. Projet web - une application web basée sur Blazor.

2. Service API - service d'arrière-plan pour les données ou la logique d'entreprise.

3. AppHost - le fichier unique AppHost qui lance l'ensemble de l'application.

4. ServiceDefaults - une bibliothèque contenant des contrôles de santé, la découverte de services et la configuration de la télémétrie.

Les deux premiers représentent un système distribué normal (frontend et backend), tandis que les deux autres représentent la chaîne d'outils unifiée d'Aspire pour la gestion des variables d'environnement, des dépendances et des API d'événements du cycle de vie des ressources.

Tim souligne que ce nouveau modèle d'application offre une prise en charge de premier ordre pour l'orchestration multi-projets, permettant aux développeurs d'exécuter l'ensemble de leur application à l'aide d'une seule commande. AppHost contrôle l'ordre de démarrage et les dépendances, tandis que ServiceDefaults injecte automatiquement les valeurs par défaut de la configuration, les contrôles de santé et l'intégration de la télémétrie.

Pourquoi Aspire simplifie le développement local

Tim explique les difficultés liées à la gestion locale d'un système distribué sans Aspire. Traditionnellement, les développeurs doivent configurer manuellement les paramètres d'exécution des conteneurs, la redirection des ports et les chaînes de connexion pour chaque service. Chaque développeur doit reproduire individuellement les variables d'environnement, les secrets d'utilisateur et les connexions redis ou API.

Avec Aspire, le CLI d'Aspire s'en charge automatiquement. Il fait tourner les dépendances telles que les conteneurs Redis par le biais d'un conteneur de développement ou d'une instance Docker, gère la découverte des points d'extrémité et fournit un accès privé entre les services à l'aide de la découverte des services.

Aspire utilise un proxy inverse et un système de résolution des points d'extrémité afin que le frontend web n'ait pas besoin de connaître les numéros de port codés en dur. Elle fait simplement référence à l'API par son nom (comme "apiservice") - Aspire se charge du reste.

Ces outils améliorent considérablement l'expérience des développeurs en supprimant les étapes d'installation fastidieuses, ce qui leur permet de se concentrer sur le code et non sur l'infrastructure.

Définition des services et des dépendances dans AppHost

Tim montre le cœur de la configuration d'Aspire : le fichier Program.cs de l'AppHost. En utilisant un modèle de construction de var, Aspire définit chaque service à l'aide de commandes simples telles que :

var cache = builder.AddRedis("cache");
var api = builder.AddProject<Projects.ApiService>("apiservice");
var web = builder.AddProject<Projects.Web>("webfrontend")
    .WithReference(cache)
    .WithReference(api);

var cache = builder.AddRedis("cache");
var api = builder.AddProject<Projects.ApiService>("apiservice");
var web = builder.AddProject<Projects.Web>("webfrontend")
    .WithReference(cache)
    .WithReference(api);

Cette syntaxe définit chaque ressource, établit l'ordre des dépendances et crée un cycle de vie des ressources clair. Aspire gère automatiquement l'attente des dépendances, en veillant à ce que le cache démarre en premier, puis l'API et enfin le frontend web.

Ce petit ensemble d'instructions permet aux développeurs d'exercer un contrôle granulaire sur le comportement au démarrage, reflétant ainsi le fonctionnement d'applications distribuées prêtes à la production.

Exécuter Aspire et comprendre le tableau de bord

Lorsque Tim exécute le projet, Aspire lance son propre moteur d'exécution de conteneur et ouvre le tableau de bord Aspire, une interface centrale permettant de tout contrôler. Au départ, une erreur apparaît : "Container runtime unhealthy"-Docker n'était pas en cours d'exécution. Une fois Docker lancé, Aspire initialise automatiquement une ressource exécutable Redis et la connecte au reste de l'application.

Le tableau de bord affiche des icônes d'état codées par couleur, indiquant la santé de chaque ressource. Une fois que Redis, l'API et l'interface web fonctionnent, le tableau de bord devient vert, montrant que l'application entière est en bonne santé.

Ce système de notification reflète instantanément les états en temps réel, fournissant des messages d'erreur plus clairs que les journaux de console standard. Les développeurs peuvent visualiser les relations entre les services, surveiller les mesures et même accéder aux points d'extrémité des ressources directement à partir de l'interface utilisateur.

Visualisation du tableau de bord Aspire

La vue graphique du tableau de bord permet de visualiser la façon dont les services se connectent. Par exemple, l'interface web se connecte à la fois à Redis et au service API, tandis que l'API est indépendante. Cette vue de la trace permet de comprendre le flux interne des appels et des dépendances.

Tim souligne que le tableau de bord comprend des améliorations au niveau des détails des traces, telles que l'affichage des options de filtrage des traces et des ventilations temporelles. Les développeurs peuvent suivre les requêtes HTTP à travers les services et voir l'impact sur les performances à l'aide de la vue des traces d'Aspire.

Logging centralisé et logs structurés

Aspire unifie les journaux de console de tous les fichiers de projet en une seule vue. Au lieu de jongler avec plusieurs fenêtres de journaux, les développeurs peuvent utiliser le tableau de bord pour afficher les journaux de tous les services (application web, API et intégration Redis) en une seule fois.

Tim montre qu'Aspire utilise une journalisation structurée, permettant des entrées riches en contexte telles que les ID, les paramètres et les balises. Les développeurs peuvent filtrer les journaux par niveau (Info, Avertissement, Erreur) ou par valeur de propriété.

Par exemple, un développeur ne peut consulter que les entrées pour lesquelles "evenOddResult" == "odd". Ce filtrage avancé des journaux, associé aux préfixes à code couleur d'Aspire, rend le débogage intuitif et visuel.

Travailler avec les traces et la télémétrie

Dans l'onglet Traces, Tim montre comment Aspire suit les requêtes à travers les services de l'application. Chaque trace contient des indications de temps, d'état et de durée, montrant quel service a traité quoi.

Par exemple, une requête "GetWeather" indique quand le cache a été atteint ou manqué, quand l'appel à l'API a eu lieu et combien de temps chaque action a pris. Ce filtrage des traces permet d'identifier avec précision les goulets d'étranglement et les dépendances.

Aspire prend également en charge OpenTelemetry pour l'exportation de données de suivi vers d'autres outils ou systèmes, ce qui permet aux développeurs de bénéficier d'une observabilité totale des services distribués.

Métriques en temps réel et surveillance des performances

Tim explore des mesures telles que la durée des requêtes, les connexions actives de SignalR et le nombre de requêtes actives. Ces mesures permettent de visualiser l'état réel de votre application et de détecter rapidement les problèmes de connexion ou de latence.

Les données métriques d'Aspire 9.5 bénéficient également d'améliorations au niveau des détails des traces et d'un meilleur filtrage des traces, ce qui permet aux développeurs de localiser les baisses de performance en temps réel.

Aspire est destiné au développement local, pas à la production

Tim indique clairement que le tableau de bord d'Aspire n'est pas destiné à être déployé sur des serveurs de production. Le déploiement de la traduction exposerait les détails du système interne et les variables d'environnement, ce qui pourrait être risqué.

Toutefois, les développeurs peuvent toujours utiliser la commande Aspire deploy pour publier des services dans Azure Container Apps, Azure Container App Jobs ou d'autres intégrations Aspire. Ces options de déploiement se développent mais restent distinctes du tableau de bord.

L'objectif d'Aspire est de reproduire localement un environnement similaire à celui de la production, avec des mises à jour sûres et une assistance préalable, et non de remplacer les systèmes de surveillance de la production.

Expérimenter avec la journalisation et le traitement des exceptions

Tim ajoute la journalisation structurée dans la page Compteur et introduit délibérément une exception NotImplementedException dans la page Météo. Lors de la réexécution, le tableau de bord capture immédiatement les journaux structurés et les exceptions non gérées.

Il montre comment les journaux d'Aspire affichent tous les détails, y compris le nom du paramètre, les valeurs et la pile d'appels. L'intégration avec GitHub Models et Copilot AI permet d'expliquer automatiquement les exceptions et de suggérer des codes pour les corriger - un exemple des premiers services d'IA et de l'intégration d'un visualiseur d'IA générative dans l'expérience du développeur.

Analyse des erreurs avec le filtrage des traces

Dans l'onglet Traces, Tim montre comment les appels d'API qui échouent apparaissent avec des icônes d'exclamation rouges. En cliquant sur l'un d'entre eux, on peut voir tous les journaux connexes filtrés par identifiant de portée, reliant chaque demande à plusieurs projets .NET.

Cette vue unifiée - journaux, traces et bilans de santé combinés - fournit des invites interactives pour le débogage et la construction de systèmes observables sans configuration externe.

Intégration d'Aspire dans les projets .NET existants

Tim explique ensuite comment intégrer Aspire dans une application existante. Les développeurs n'ont que deux choses à ajouter :

• Le projet AppHost, qui contrôle le démarrage des services et leurs dépendances.

• Le projet ServiceDefaults, qui fournit des indicateurs de fonctionnalités, des contrôles de santé, de la télémétrie et de la découverte de services.

En référençant ServiceDefaults dans chaque fichier de projet, les développeurs obtiennent automatiquement les variables d'environnement par défaut, la configuration de la journalisation et la télémétrie. Le système de résolution des points d'extrémité d'Aspire élimine la nécessité de transférer manuellement les ports ou de gérer les chaînes de connexion.

Expansion d'Aspire au-delà de l'utilisation locale

Tim aborde la manière dont les capacités d'Aspire s'étendent au-delà de l'utilisation locale. Grâce aux intégrations Azure Container Apps et Azure AI Foundry, les développeurs peuvent utiliser l'interface CLI d'Aspire pour déployer des systèmes distribués avec une configuration minimale.

Le système prend déjà en charge les icônes de ressources personnalisées, les propriétés des noms et la prise en charge de la prévisualisation pour les services IA tels que les points d'extrémité OpenAI ou les connexions Azure PostgreSQL.

La chaîne d'outils unifiée d'Aspire prend également en charge le contrôle des versions et les mises à niveau sécurisées entre les versions majeures et les versions mineures, ce qui permet aux équipes d'adopter en toute confiance des mises à jour telles qu'Aspire 9.5.

Réflexions finales et perspectives d'avenir

En conclusion de la vidéo, Tim qualifie Aspire de "mine d'or pour les développeurs" Le tableau de bord combine la vue des traces, les contrôles de santé, les journaux et les mesures en un seul panneau unifié - quelque chose qui n'existait pas auparavant dans le développement local.

Pour Tim et son équipe, chaque nouveau projet .NET Aspire utilise désormais ce système par défaut. La traduction doit rester professionnelle et préserver l'exactitude technique tout en expliquant les caractéristiques et les avantages de ces outils de développement.

Il note que les principales versions d'Aspire continueront d'affiner le filtrage des traces, la résolution des points de terminaison et les intégrations d'applications aériennes, tout en se concentrant sur des mises à niveau sûres et une disponibilité générale.

Tim encourage tout le monde à explorer Aspire 9.5, à l'utiliser dans leurs prochains projets .NET et à tirer parti de la simplicité de sa commande unique pour afficher les journaux, gérer les tunnels de développement et tester l'ensemble de l'application localement en toute confiance.