Configuration de .NET Aspire sur Linux

Installation de l'outil CLI Aspire

[0:48 - 2:20] Tim commence sur aspire.dev, en notant que le projet s'est récemment renommé de "Aspire.NET" à simplement "Aspire". Ce changement de nom reflète l'élargissement de la portée de l'outil : bien qu'Aspire soit encore construit sur .NET et que son principal public soit les développeurs .NET, il prend désormais en charge les hôtes d'applications TypeScript et d'autres intégrations de langages sont en cours de route.

L'installation elle-même est une seule commande bash copiée depuis la documentation Aspire pour la version 9.2 :

dotnet tool install -g aspirate

dotnet tool install -g aspirate

Après avoir exécuté l'installateur, redémarrez votre session de terminal pour que l'outil soit enregistré dans votre PATH. Sans redémarrage, votre shell ne reconnaîtra pas la nouvelle commande.

Ensuite, confirmez que l'installation s'est terminée correctement :

aspire --version

aspire --version

Si le numéro de version s'affiche, le CLI est prêt. Ce processus en deux étapes (installer, vérifier) constitue toute la configuration côté terminal.

Configurer l'extension VS Code

[2:23 - 3:30] Avec l'installation de la CLI, l'étape suivante est l'extension VS Code. Ouvrez le panneau Extensions, recherchez "Aspire", et installez l'extension officielle publiée par Microsoft. L'extension ajoute une structure de projet, un support de configuration de lancement, et une intégration avec le tableau de bord Aspire.

Après l'installation, VS Code effectue une étape de vérification pour s'assurer que le CLI et l'extension sont alignés. Tim note que l'extension peut également créer un nouveau projet directement par le biais de la palette de commande, bien qu'il opte plutôt pour l'approche CLI. Ce choix est délibéré : connaître le CLI signifie que vous n'êtes jamais coincé lorsqu'un outil GUI se comporte mal. Quand le sélecteur de modèle VS Code échouait à afficher les modèles Aspire après l'installation, le CLI fournissait une solution immédiate.

Structurer le projet de départ

[3:30 - 6:42] Plutôt que d'utiliser la commande "Créer un nouveau projet .NET" de VS Code (qui manquait parfois de découvrir les modèles Aspire), Tim passe au terminal et exécute :

aspire new

aspire new

Plusieurs choix de modèles apparaissent dans l'invite interactive. Pour une application de production, vous sélectionneriez généralement l'hôte d'application C# vide et construiriez à partir de là. À des fins d'apprentissage, Tim sélectionne l'Application de démarrage, qui génère un front-end Blazor soutenu par une API minimale. Le modèle de démarrage comprend un point d'extrémité de prévisions météorologiques, une page compteur, et des vérifications de santé pré-câblées, vous donnant quelque chose de fonctionnel à explorer immédiatement.

Les invites successives guident à travers les autres configurations :

Nom du projet : TinyTicket
Chemin de sortie : TinyTicket
Utilisation de localhost dev : Oui
Cache Redis : Non
Projet de test : Non
Environnement de l'agent IA : Non

Tim garde chaque fonctionnalité optionnelle désactivée pour minimiser la complexité. L'objectif est un point de départ allégé que les futurs épisodes élargiront progressivement. Une fois la structure terminée, ouvrez le dossier dans VS Code et faites confiance à l'espace de travail lorsque vous y êtes invité.

Comprendre la structure du projet

[6:42 - 10:00] La solution générée contient quatre projets, et les relations entre eux révèlent comment Aspire fonctionne. Le projet App Host est la couche d'orchestration. Son Program.cs est d'environ douze lignes de code :

var builder = DistributedApplication.CreateBuilder(args);

var api = builder.AddProject<Projects.TinyTicket_ApiService>("api")
    .WithHttpHealthCheck("/health");

builder.AddProject<Projects.TinyTicket_Web>("frontend")
    .WithExternalHttpEndpoints()
    .WithHttpHealthCheck("/health")
    .WithReference(api)
    .WaitFor(api);

builder.Build().Run();

var builder = DistributedApplication.CreateBuilder(args);

var api = builder.AddProject<Projects.TinyTicket_ApiService>("api")
    .WithHttpHealthCheck("/health");

builder.AddProject<Projects.TinyTicket_Web>("frontend")
    .WithExternalHttpEndpoints()
    .WithHttpHealthCheck("/health")
    .WithReference(api)
    .WaitFor(api);

builder.Build().Run();

Notez comment le front-end déclare une référence à l'API et attend qu'il devienne sain avant de démarrer. Cet ordre de dépendance, la découverte de service, et les vérifications de santé sont tout ce qu'Aspire fournit au niveau du code. Il n'y a pas de magie cachée au-delà de ce que vous voyez dans ce fichier.

À côté de l'hôte app se trouve le projet Service Defaults, qui contient des méthodes d'extension pour la télémétrie, la journalisation structurée, et l'enregistrement des vérifications de santé. Ce sont des commodités à opt-in : si vous n'avez pas encore configuré OpenTelemetry ou des points de terminaison de santé dans vos services, les défauts les connectent pour vous.

Le projet API Service a un seul point d'extrémité qui retourne des prévisions météorologiques générées aléatoirement. Le projet Web est une application Blazor qui appelle l'API à travers un HttpClient configuré avec seulement un nom de service ("api"). Aspire résout ce nom à l'URL correcte à l'exécution, donc l'application Blazor ne code jamais en dur un numéro de port ou un nom d'hôte.

Tim souligne un détail de déploiement important : Aspire lui-même n'est pas déployé en production. L'orchestration est un outil de temps de développement. En production, les URL de service proviennent de la configuration (variables d'environnement, paramètres de l'application, ou un pipeline de déploiement), et les applications fonctionnent indépendamment sans l'hôte d'app.

Exécuter et explorer le tableau de bord

[10:59 - 14:46] Lancez l'hôte app par le biais du panneau Exécuter et Déboguer dans VS Code, en sélectionnant le profil de lancement HTTPS. Après la restauration et la construction initiales, le tableau de bord Aspire s'ouvre dans le navigateur. La première fois que vous vous connectez, vous devez coller un jeton de connexion à partir de la sortie du terminal.

Le tableau de bord fournit quatre catégories de données d'observabilité sans configuration supplémentaire :

Sortie de console agrège la sortie stdout de chaque service dans une vue unique. Au lieu de passer d'un onglet de terminal à l'autre, vous voyez toute la sortie entrelacée et filtrable par service.

Journaux structurés affichent les entrées de journal avec leurs propriétés structurées intactes. L'avertissement de confiance de certificat que Tim rencontre, par exemple, apparaît ici avec un contexte complet sur quel service l'a généré et à quel niveau de gravité.

Traces montrent les chaînes d'appels distribués. Quand le front-end Blazor demande des données météo, la trace montre le GET HTTP du front-end, le saut au service API (qui a pris 7,35 millisecondes dans la vidéo), et le temps total de rendu de la page. Tim souligne que les chiffres absolus importent moins que les comparaisons relatives : si un appel prend normalement 5 secondes et prend soudainement 10, vous avez trouvé votre régression sans attacher un profileur.

Métriques fournissent des compteurs de service par requête, des taux d'erreur, et des niveaux de consommation de ressources. Le tableau de bord expose également les variables d'environnement et les informations d'identification du point de terminaison pour chaque service, ce qui est utile pour vérifier que les valeurs de configuration circulent correctement.

Présentation de Tiny Ticket : le projet de la série

[14:46 - 17:17] Tim décrit le plan pour le projet qui sera traité dans le reste de la série. Tiny Ticket est une application de support au bureau d'aide allégée : les utilisateurs soumettent des tickets de support, et le système suit la priorité et l'état. Le modèle de données peut être aussi petit qu'une seule table SQL. Le but n'est pas de créer un produit riche en fonctionnalités mais de créer une tranche verticale qui touche chaque partie du cycle de développement sur Linux : construction, test, déploiement, et connexion à des services externes.

Les pages de prévisions météorologiques et de compteur du modèle de démarrage seront remplacées par des vues de tickets, mais l'orchestration Aspire, le modèle d'API au front-end, et les défauts de service resteront. Les épisodes futurs ajouteront Microsoft SQL Server comme base de données, avec Tim répondant à une objection courante : les développeurs qui ne peuvent pas exécuter SQL Server localement (processeurs ARM, par exemple) se tournent parfois vers une autre base de données. Sa réponse est que l'environnement de développement doit répliquer la production. Si la base de données de production est SQL Server, l'environnement de développement doit correspondre, même si cela signifie exécuter la base de données dans un conteneur.

Conclusion : De zéro à tableau de bord

[17:17 - 18:20] En moins de vingt minutes, la vidéo couvre la mise en place complète d'Aspire sur Linux : une installation CLI, une extension VS Code, un projet structuré, et un tableau de bord qui fournit une journalisation structurée, des traces distribuées et des métriques sans configuration personnalisée. La vraie valeur d'Aspire n'est pas une seule fonctionnalité mais la réduction des frictions : un processus à lancer, un tableau de bord à surveiller, et un endroit pour voir comment les services interagissent.

Conclusion

[18:20 - 18:53] Mettre en place Aspire sur Linux nécessite l'outil CLI, l'extension VS Code, et un projet structuré. À partir de là, le tableau de bord vous offre une observabilité à travers chaque service sans écrire de code de télémétrie. Le fichier hôte d'app définit votre graphe de service en une douzaine de lignes, et les défauts de service gèrent le câblage que vous configureriez autrement manuellement.

Le projet Tiny Ticket introduit ici servira de base aux prochains épisodes sur l'intégration de base de données, le déploiement Azure, et les flux de travail interplateformes. Suivre à partir de ce point de départ signifie que chaque nouveau concept se base sur une infrastructure que vous avez déjà vérifiée.

Navigation de la série : Cet article fait partie de la série C# sur Linux construisant l'application Tiny Ticket. Précédent : SQL Server dans Docker sur Linux. Next: Adding Swagger UI to .NET Aspire on Linux.

Astuce Exemple : Lorsque le sélecteur de modèles VS Code ne parvient pas à découvrir les modèles Aspire après l'installation de l'extension, utilisez aspire new depuis le terminal comme une solution fiable, puis redémarrez VS Code ensuite pour synchroniser l'état de l'extension.

Regardez la vidéo complète sur sa chaîne YouTube Channel pour obtenir plus d'informations sur la configuration de .NET Aspire pour le développement Linux.