Ce qu'Aspire 9 faisait bien
.NET Aspire 9 résolvait un vrai problème : orchestrer localement des applications .NET distribuées était pénible. Exécuter plusieurs services, une base de données, un message broker et un frontend en même temps impliquait de jongler avec des scripts, des fichiers docker-compose et des variables d'environnement configurées manuellement.
Aspire 9 a introduit l'AppHost : un projet C# qui décrit toute la structure de l'application sous forme de code :
var builder = DistributedApplication.CreateBuilder(args);
var postgres = builder.AddPostgres("db");
var api = builder.AddProject<Projects.Api>("api")
.WithReference(postgres);
var frontend = builder.AddProject<Projects.Frontend>("frontend")
.WithReference(api);
builder.Build().Run();
Le développement local, la découverte de services, le tableau de bord intégré pour les logs et les traces, tout cela fonctionnait bien. L'AppHost savait quels services dépendaient les uns des autres, définissait automatiquement les chaînes de connexion et démarrait tout dans le bon ordre.
Le problème commençait au moment où vous vouliez réellement déployer quelque part cette application qui fonctionnait localement.
Le problème de déploiement dans Aspire 9
La voie principale : azd et Azure Container Apps
Le modèle de déploiement officiel et entièrement pris en charge dans Aspire 9 passait par l'Azure Developer CLI (azd). Vous génériez un manifest : un fichier JSON décrivant toutes les ressources et leurs connexions comme un instantané statique, puis vous le transmettiez à azd, qui le traduisait en templates Azure Bicep et provisionnait l'ensemble sous forme d'Azure Container Apps.
azd up
Pour Azure, c'était un chemin fonctionnel. Toute personne travaillant sur AWS, GCP ou sa propre infrastructure ne trouvait rien de comparable dans la documentation officielle. Le manifest pouvait théoriquement être lu par d'autres outils, mais cela relevait de l'initiative personnelle, pas d'un workflow pris en charge.
Le modèle du manifest et ses limites structurelles
Le manifest était un instantané statique du modèle AppHost au moment de sa génération. Les dépendances complexes, les configurations conditionnelles ou les ressources qui ne reçoivent des valeurs concrètes qu'à l'exécution, rien de tout cela ne pouvait être entièrement exprimé dans un document JSON statique. Ce qui fonctionnait localement dans l'AppHost devait parfois être simplifié ou omis lors de l'export vers le manifest.
En plus de cela, chaque azd up repartait de zéro. L'outil ne gardait aucune mémoire du dernier abonnement, de la dernière région ou du dernier groupe de ressources utilisés. Toute personne déployant régulièrement répondait aux mêmes questions à chaque exécution.
Kubernetes : charts Helm oui, déploiement non
À partir d'Aspire 9.2 (avril 2025), Aspire.Hosting.Kubernetes fournissait un publisher Kubernetes officiel, mais en preview, avec une limitation critique : il pouvait générer des charts Helm, mais pas les déployer.
Le publisher produisait une structure complète de chart Helm à partir de l'AppHost :
Chart.yaml ← metadata
values.yaml ← configuration parameters
templates/
deployment.yaml ← per service
service.yaml
configmap.yaml
secret.yaml
L'étape suivante, helm install ou helm upgrade contre un vrai cluster, restait entièrement à la charge du développeur. aspire deploy pour Kubernetes n'existait nulle part dans la série 9.x. Il y avait un trou au milieu du workflow.
Des bugs concrets rendaient encore plus difficile une utilisation pratique. Les champs de port étaient sérialisés comme des chaînes au lieu de int32, ce qui faisait échouer helm upgrade. Les init containers, par exemple pour les migrations de base de données, n'étaient pas correctement inclus dans les manifests générés. Le values.yaml central nécessitait des surcharges manuelles avec --set au moment du déploiement, parce que la configuration n'était pas directement embarquée dans les ConfigMaps ou les Secrets.
Docker Compose était lui aussi disponible comme publisher à partir de la 9.2, mais également seulement en preview et sans prise en charge de aspire deploy.
La communauté comme solution de secours : aspirate
Comme le chemin Kubernetes officiel était incomplet, la communauté a construit aspirate (également connu sous le nom d'Aspir8). L'outil lisait le manifest Aspire et prenait en charge ce que le publisher officiel laissait de côté : push vers le registre, gestion des secrets et déploiement direct sur cluster via aspirate apply.
aspirate fonctionnait, mais c'était une solution de contournement. Les mises à jour étaient en retard par rapport au développement d'Aspire, et les nouvelles fonctionnalités d'Aspire mettaient du temps à arriver dans l'outil communautaire.
Le fait qu'un outil communautaire soit nécessaire pour quelque chose d'aussi fondamental que le déploiement Kubernetes en disait long sur les limites d'Aspire 9.
Résumé : ce qui manquait à Aspire 9
- Azure Container Apps était la seule cible de déploiement entièrement prise en charge
- Kubernetes : génération de charts Helm possible (preview à partir de 9.2), mais pas de
aspire deploy,helm installmanuel requis - Docker Compose : publisher disponible (preview à partir de 9.2), mais pas de chemin de déploiement complet
- Azure App Service : disponible uniquement à partir de 9.3 en preview, pas stable
- Pas d'AWS, pas de GCP, pas d'on-premises : ni officiellement, ni pensé pour l'extensibilité
- Modèle de manifest statique sans mémoire d'état et avec des limites d'expression structurelles
- Pas de modèle d'extension pour des cibles de déploiement personnalisées
Comment Aspire 13 a changé cela
13.0 : la base, modèle pipeline et persistance d'état (novembre 2025)
Le plus grand changement était architectural. Le modèle de publisher basé sur le manifest a été entièrement remplacé par un modèle pipeline : chaque ressource dans l'AppHost apporte ses propres objets PipelineStep, qui déclarent leurs dépendances entre eux, s'exécutent en parallèle quand c'est possible et sont observables comme des unités individuelles. Les anciennes API (IDistributedApplicationPublisher, WithPublishingCallback, PublishingContext) ont été supprimées.
aspire deploy # or: aspire do deploy
Pour la première fois, Aspire mémorisait l'état entre les déploiements : abonnement, groupe de ressources, région et valeurs de paramètres sont enregistrés par développeur et par environnement, puis préremplis à l'exécution suivante.
Les cibles prises en charge de manière stable en 13.0 étaient Azure Container Apps et Azure App Service. Docker Compose et Kubernetes étaient présents, mais encore en cours de finalisation.
13.1 : registre de conteneurs et déploiement Docker Compose (décembre 2025)
Les registres de conteneurs sont devenus un concept autonome dans l'AppHost en 13.1 :
var registry = builder.AddContainerRegistry("myregistry", "registry.example.com");
var api = builder.AddProject<Projects.Api>("api")
.WithContainerRegistry(registry);
Au lieu d'être implicitement lié à un Azure Container Registry, le registre pouvait désormais être provisionné séparément, réutilisé ou pointer vers des registres externes (Docker Hub, GHCR). Le pipeline de déploiement a gagné une étape explicite push pouvant s'exécuter en parallèle avec d'autres étapes.
Docker Compose a reçu pour la première fois une prise en charge complète du déploiement en 13.1 : aspire deploy fonctionnait de bout en bout sans intervention manuelle de la Docker CLI.
Azure App Service a gagné les deployment slots : des déploiements sans interruption via un slot de staging et un swap automatique pouvaient être configurés directement depuis l'AppHost.
13.2 : Docker Compose devient stable, isolation réseau Azure (mars 2026)
Docker Compose a quitté le statut preview en 13.2 et est devenu stable. Pour la première fois, il existait un chemin de déploiement non Azure entièrement pris en charge.
De nouvelles API infrastructure-as-code pour l'isolation réseau dans les déploiements Azure ont été ajoutées :
builder.AddAzureVirtualNetwork("vnet")
.AddSubnet("app-subnet")
.AddPrivateEndpoint(postgres);
Les Azure Virtual Networks, les private endpoints avec configuration automatique des zones DNS et les network security groups pouvaient être déclarés directement dans l'AppHost. Kubernetes a lui aussi reçu des correctifs sur la sérialisation YAML qui avaient provoqué des échecs helm upgrade en 9.x.
13.3 : Kubernetes de bout en bout, AKS et aspire destroy (mai 2026)
L'étape décisive pour Kubernetes : aspire deploy fonctionnait désormais entièrement contre de vrais clusters. Le workflow passait en interne par helm install ou helm upgrade, sans intervention manuelle. aspire destroy exécutait en parallèle helm uninstall et supprimait les namespaces.
Azure Kubernetes Service (AKS) a reçu son propre package d'hébergement (Aspire.Hosting.Azure.Kubernetes) :
builder.AddAzureKubernetesEnvironment("prod-aks")
.WithHelm();
Aspire générait un pipeline combiné Bicep et Helm : provisionnement du cluster, push d'image et déploiement Helm en une seule exécution. Ingress et Gateway API sont devenus des concepts de premier niveau : les règles de routage, la terminaison TLS via cert-manager et l'attribution de FQDN pouvaient être exprimées directement dans l'AppHost sans fichiers YAML Kubernetes séparés.
13.4 : disponibilité générale et charts Helm externes (juin 2026)
Avec 13.4, aspire publish, aspire deploy et aspire destroy ont quitté le statut preview. La prise en charge Kubernetes a gagné cert-manager avec intégration Let's Encrypt sous forme d'API typée, ainsi qu'Azure Application Gateway for Containers (AGC) pour les déploiements AKS.
Nouveauté : AddHelmChart permet d'installer des charts Helm externes arbitraires comme partie du pipeline de déploiement :
builder.AddHelmChart("nginx-ingress", "ingress-nginx/ingress-nginx", "4.10.0");
Cela signifie que des ressources Aspire personnalisées peuvent être déployées aux côtés de charts standards de l'écosystème, comme les ingress controllers ou les stacks de monitoring, sans sortir du pipeline.
Toujours pas officiellement pris en charge : AWS, GCP et les déploiements on-premises. Le modèle pipeline est extensible via WithPipelineStepFactory, mais les providers personnalisés doivent être construits entièrement depuis zéro.
Besoin d'aide ?
Vous évaluez Aspire pour votre projet ou préparez une migration d'Aspire 9 vers 13, mais vous ne savez pas quel chemin de déploiement correspond à votre infrastructure ? Nous pouvons vous aider. Contactez-nous via notre page de contact et nous travaillerons ensemble pour définir la bonne stratégie Aspire pour votre environnement.
