aspire

Vue d’ensemble de la compétence aspire

Ce que la compétence aspire vous aide à faire

La compétence aspire s’adresse aux utilisateurs qui doivent créer, exécuter, déboguer, configurer ou publier une application distribuée basée sur Aspire sans devoir reconstituer le workflow à partir d’une documentation éparse. Elle est particulièrement utile lorsque votre besoin réel n’est pas de « comprendre Aspire en théorie », mais de « faire fonctionner un AppHost, raccorder correctement les services, analyser les échecs et préparer les artefacts pour le déploiement ».

À qui s’adresse aspire

Les profils pour lesquels aspire est le plus pertinent sont :

• les développeurs qui évaluent Aspire pour l’orchestration locale d’applications multi-services
• les équipes qui ajoutent un AppHost autour d’API, de conteneurs ou d’exécutables existants
• les utilisateurs qui veulent qu’un assistant IA les aide sur aspire install, la configuration initiale, le dépannage et la publication orientée déploiement
• les équipes polyglottes qui combinent un AppHost .NET avec des services Python, Node.js, Go, Java ou conteneurisés

Ce qui différencie cette compétence aspire

Cette compétence aspire est plus utile qu’un prompt générique, car elle oriente l’agent vers la bonne source de référence selon la tâche :

• utilisation de la CLI et détails d’installation dans references/cli-reference.md
• concepts AppHost et runtime dans references/architecture.md
• workflows de dashboard et d’observabilité dans references/dashboard.md
• conseils de publication selon la cible dans references/deployment.md
• découverte d’intégrations via MCP dans references/integrations-catalog.md

C’est important, car Aspire repose sur un modèle mental précis : l’AppHost définit les ressources et les dépendances, tandis que le runtime et le dashboard servent à les exploiter localement.

Point de décision clé avant d’installer aspire

Choisissez Aspire si vous voulez un point central défini en code pour orchestrer services, dépendances, endpoints, logs, traces et artefacts de publication vers une plateforme cible. En revanche, ne le choisissez pas si vous attendez un déploiement direct en production via une seule commande : le dépôt indique clairement qu’Aspire publie des manifests et des artefacts, puis laisse à votre CI/CD ou à votre plateforme le soin d’effectuer le déploiement réel.

Comment utiliser la compétence aspire

Contexte d’installation pour la compétence aspire

Un parcours d’installation pragmatique pour la compétence aspire consiste à ajouter la compétence, puis à utiliser ses références comme contexte ciblé selon la tâche :

1. Installez la compétence :
   npx skills add github/awesome-copilot --skill aspire
2. Ouvrez skills/aspire/SKILL.md
3. Chargez uniquement le fichier de référence correspondant à votre tâche au lieu de tout lire

Ordre de lecture conseillé :

• SKILL.md
• references/cli-reference.md
• references/architecture.md
• references/deployment.md
• references/troubleshooting.md

Comment installer Aspire lui-même

Si votre objectif est d’utiliser réellement Aspire, la compétence renvoie vers le flux CLI autonome :

# Linux / macOS
curl -sSL https://aspire.dev/install.sh | bash

# Windows PowerShell
irm https://aspire.dev/install.ps1 | iex

aspire --version

C’est un point important, car la CLI Aspire est une interface principale, et pas simplement une fonctionnalité secondaire de dotnet.

Bien cadrer la demande dès le départ

La compétence aspire fonctionne beaucoup mieux lorsque votre demande exprime clairement l’une de ces intentions :

• créer une nouvelle application Aspire
• ajouter un AppHost à une solution existante
• raccorder une dépendance comme Redis ou PostgreSQL
• exécuter et déboguer une application distribuée en local
• publier la sortie Aspire pour Docker ou Kubernetes
• diagnostiquer des problèmes de démarrage, de santé ou de découverte de services

Une demande vague comme « aide-moi avec Aspire » oblige l’agent à deviner. Une demande plus structurée comme « configure un AppHost pour mon API, Redis et un worker Python, puis prépare une sortie de publication Docker » lui donne suffisamment de contexte pour utiliser les bonnes références.

De quelles informations la compétence aspire a besoin

Pour obtenir une réponse de qualité, fournissez :

• la structure actuelle de votre dépôt
• les langages et runtimes visés
• si vous avez déjà un AppHost
• les contraintes de runtime local, comme la disponibilité de Docker ou Podman
• la plateforme cible de publication : Docker, Kubernetes ou une sortie orientée Azure
• les symptômes observés, si vous êtes en phase de dépannage

Exemple de demande utile :

I have a .NET API, a React frontend, and a Redis dependency. I want Aspire for local orchestration and Docker publish artifacts. I already use Docker Desktop. Show me the AppHost shape, CLI commands, and likely package choices.

Comment transformer un objectif flou en bon prompt aspire

Un bon prompt de guidage aspire comprend généralement cinq éléments :

1. la forme actuelle de l’application
2. les ressources souhaitées
3. les attentes pour l’exécution locale
4. la cible de déploiement
5. le format de réponse attendu

Exemple :

Use the aspire skill to propose an AppHost for:
- .NET API in src/Api
- Node frontend in src/Web
- PostgreSQL for local dev
Need:
- service startup order
- endpoint wiring
- environment variable strategy
- Aspire CLI commands
- publish path for Kubernetes
Return code snippets plus a short explanation of tradeoffs.

Fichiers du dépôt à lire en priorité pour un usage réel

Si vous évaluez l’adoption de la compétence aspire, voici les fichiers les plus importants :

• SKILL.md pour le périmètre et l’orientation
• references/cli-reference.md pour l’installation, aspire new, aspire run, aspire publish et les commandes selon la version
• references/deployment.md pour bien comprendre la frontière essentielle entre publication et déploiement
• references/polyglot-apis.md si tous vos services ne sont pas en .NET
• references/mcp-server.md si vous voulez une inspection pilotée par assistant et la consultation de documentation
• references/troubleshooting.md si l’orchestration locale échoue

Cette structure est pragmatique : la compétence est pilotée par des références, donc la qualité dépend du chargement du bon fichier, pas de tous les fichiers à la fois.

Comment l’usage d’aspire se déroule en pratique

Un usage typique d’aspire suit généralement cet ordre :

1. créer ou ouvrir l’AppHost
2. définir les ressources et leurs références
3. exécuter localement avec aspire run
4. inspecter l’état des ressources, les logs, les endpoints et les traces dans le dashboard
5. itérer sur la configuration
6. publier les artefacts pour votre cible de déploiement

Ce workflow est préférable à un passage direct au déploiement, car Aspire privilégie clairement d’abord l’orchestration locale et l’observabilité.

Bien utiliser aspire pour le déploiement

Avec aspire pour le déploiement, l’information la plus importante est que aspire publish génère des artefacts de déploiement ; il ne les déploie pas directement.

Exemples issus des références :

aspire publish -p docker -o ./docker-output
aspire publish -p kubernetes -o ./k8s-output

Conseil de décision :

• choisissez Aspire si vous voulez que vos artefacts de déploiement dérivent du même modèle AppHost que celui utilisé en local
• ne le choisissez pas si vous attendez d’un seul outil qu’il définisse l’application et gère entièrement sa mise en production

Quand passer par la voie MCP

La compétence aspire est particulièrement utile avec MCP lorsque vous voulez qu’un assistant inspecte une application en cours d’exécution ou récupère la documentation d’intégration sans recherche manuelle.

references/mcp-server.md présente aspire mcp init, qui configure des environnements IA pris en charge et peut créer .vscode/mcp.json ainsi que AGENTS.md. C’est un point important pour l’adoption, car cela réduit l’écart entre « l’assistant connaît les concepts Aspire » et « l’assistant peut voir mes ressources, logs et traces réels ».

Conseils pratiques qui améliorent réellement les résultats

• Indiquez si votre charge de travail est un .NET project, un container ou un executable ; Aspire les modélise différemment.
• Mentionnez dès le début la disponibilité du runtime local. Les applications polyglottes peuvent nécessiter l’installation du runtime du langage cible, même si l’AppHost est en .NET.
• Demandez explicitement l’ordre de démarrage et le raccordement des dépendances ; c’est là que la valeur de l’AppHost apparaît vraiment.
• Si le déploiement est l’objectif final, demandez à l’agent de séparer les choix d’orchestration locale des choix liés à la cible de publication.
• Si une commande échoue, incluez la commande complète ainsi que l’état observé dans le dashboard ou les logs, et pas seulement « ça ne marche pas ».

FAQ sur la compétence aspire

La compétence aspire est-elle adaptée aux débutants

Oui, à condition d’avoir déjà une compréhension de base des applications multi-services. La compétence aspire réduit les principaux points de friction des débutants : quelles commandes CLI comptent vraiment, de quoi l’AppHost est responsable, où regarder pour comprendre le comportement du dashboard et pourquoi publier n’est pas la même chose que déployer.

Quelle est la limite de la compétence aspire

La compétence aspire couvre l’orchestration locale, les concepts AppHost, la découverte d’intégrations, la configuration MCP, les workflows autour du dashboard, le dépannage et la préparation au déploiement orientée publication. Elle ne remplace pas entièrement votre CI/CD spécifique à la plateforme, vos opérations de cluster ni la conception de sécurité cloud.

En quoi la compétence aspire est-elle meilleure qu’un prompt classique

Un prompt classique peut produire des conseils d’installation plausibles, mais erronés. La compétence aspire est préférable lorsque vous avez besoin de :

• conseils CLI tenant compte des versions
• la bonne distinction entre publication et déploiement
• schémas d’hébergement polyglottes
• parcours de dashboard et de dépannage
• découverte d’intégrations via les outils MCP

aspire est-il réservé aux équipes .NET

Non. Les références couvrent explicitement les charges de travail polyglottes. L’AppHost reste basé sur .NET, mais les services orchestrés peuvent être des conteneurs ou des exécutables dans d’autres langages. Aspire convient donc aux stacks mixtes, pas uniquement aux solutions 100 % .NET.

Quand ne faut-il pas utiliser aspire

Évitez Aspire si :

• vous n’avez besoin que d’une application mono-processus
• votre équipe dispose déjà d’un standard d’orchestration locale bien adapté
• vous avez besoin d’une gestion directe du déploiement en production plutôt que d’artefacts générés
• votre environnement ne peut pas prendre en charge les runtimes locaux ou les outils de conteneurisation requis

L’installation d’aspire nécessite-t-elle Docker

Pas systématiquement, mais de nombreux workflows Aspire réellement utiles tirent parti du support des conteneurs. La référence d’architecture précise que les conteneurs peuvent s’exécuter via des runtimes locaux comme Docker ou Podman, tandis que les exécutables s’exécutent comme des processus natifs. L’exigence exacte dépend donc des ressources que vous prévoyez d’orchestrer.

Comment améliorer la compétence aspire

Donnez à la compétence aspire des entrées d’architecture concrètes

Le moyen le plus rapide d’améliorer les résultats de la compétence aspire est d’arrêter de demander des exemples abstraits et de fournir votre topologie réelle :

• noms des services
• ports ou attentes sur les endpoints
• graphe de dépendances
• contraintes de runtime local
• plateforme cible de publication

Cela conduit à de meilleures propositions d’AppHost, à un raccordement d’endpoints plus propre et à moins de placeholders génériques.

Demandez une réponse en blocs directement exploitables

Au lieu de « construis-moi une configuration Aspire », demandez :

• le code AppHost
• les commandes de packages et de templates
• les étapes d’exécution locale
• les étapes de vérification dans le dashboard
• les commandes de publication pour la plateforme cible

Cette structure correspond à la manière dont Aspire est réellement utilisé et rend la réponse plus facile à valider.

Utilisez le dossier references de façon intentionnelle

Pour améliorer la qualité, indiquez à l’agent sur quelle source s’appuyer :

• « use references/deployment.md for publish choices »
• « use references/polyglot-apis.md for Node and Python hosting options »
• « use references/troubleshooting.md to diagnose failed startup »

Cela évite les réponses hybrides qui mélangent architecture, comportement du runtime et déploiement.

Mode d’échec courant : confondre orchestration locale et déploiement en production

L’une des erreurs d’adoption les plus fréquentes consiste à supposer qu’Aspire déploie lui-même en production. Si la première réponse dérive dans cette direction, corrigez-la immédiatement : demandez des artefacts de publication, puis un plan séparé de relais vers le CI/CD. C’est ce qui permet de garder un guide aspire à la fois pratique et exact.

Mode d’échec courant : hypothèses manquantes sur les dépendances et la santé

Si les services démarrent dans le mauvais ordre ou échouent à se découvrir, demandez à l’agent de modéliser explicitement :

• les références entre ressources
• le comportement d’attente et de health
• les variables d’environnement dérivées des dépendances
• les besoins d’exposition d’endpoints externes

C’est typiquement sur ce point qu’une demande d’usage d’aspire trop vague donne des résultats médiocres.

Améliorez le dépannage en partageant des éléments observables

Lorsque vous voulez que la compétence aspire débogue un problème, fournissez :

• la commande aspire run utilisée
• l’état de chaque ressource dans le dashboard
• les logs de la ressource en échec
• si l’échec est lié au démarrage, à la connectivité ou à la publication

Les éléments observables comptent davantage qu’un gros dump de code.

Améliorez les sorties aspire pour le déploiement avec des contraintes de cible

Pour aspire pour le déploiement, précisez ce qu’attend votre plateforme :

• artefacts Docker Compose
• manifests Kubernetes
• sortie compatible Helm
• limites de configuration selon l’environnement
• attentes en matière de réplicas ou d’ingress

La référence de déploiement montre que la sortie de publication dépend de la cible, donc votre demande doit elle aussi être ciblée.

Itérez après la première réponse au lieu de repartir de zéro

Un bon prompt de second tour ressemble généralement à ceci :

Revise the Aspire plan using these constraints:
- frontend must stay outside Aspire
- API and worker should run under AppHost
- use PostgreSQL container locally
- produce Kubernetes publish output
- explain what must still be handled by CI/CD

Ce type d’itération améliore bien davantage l’adéquation que de redemander un tout nouveau guide aspire générique.