Isolation réseau, private endpoints, abstraction du registre de conteneurs et Azure Front Door : Aspire 13 répond directement aux exigences d'entreprise dans l'AppHost, sans configuration d'infrastructure séparée.

Les environnements d'entreprise imposent des exigences qui vont au-delà de "démarrer des conteneurs et les connecter" : isolation réseau, connexions privées aux bases de données, accès contrôlé aux registres de conteneurs et distribution globale du trafic. Dans Aspire 9, tous ces aspects restaient entièrement en dehors de l'AppHost. Aspire 13 les fait entrer dedans.

Le registre de conteneurs comme concept explicite

Dans Aspire 9, le registre de conteneurs était implicite : Azure Container Apps venait avec un registre, point final. Toute personne souhaitant réutiliser un registre existant, faire pointer plusieurs environnements vers le même registre ou utiliser Docker Hub ou GHCR ne disposait d'aucune abstraction propre.

À partir d'Aspire 13.1, le registre devient une ressource autonome :

// External registry (Docker Hub, GHCR, custom)
var registry = builder.AddContainerRegistry("prod-registry", "registry.example.com");

// Azure Container Registry with automatic provisioning
var acr = builder.AddAzureContainerRegistry("acr");

builder.AddProject<Projects.Api>("api")
    .WithContainerRegistry(registry);

Cela a des conséquences pratiques pour le flux de déploiement : l'étape de push d'image est désormais explicite dans le pipeline et peut s'exécuter en parallèle avec d'autres étapes de provisionnement. Toute personne disposant d'un ACR et d'identités de pull existantes peut les référencer directement :

env.WithAcrPullIdentity(existingAcr);

Azure Virtual Network et private endpoints

À partir d'Aspire 13.2, l'isolation réseau peut être déclarée directement dans l'AppHost. Au lieu d'écrire des templates Bicep à la main, les VNets, subnets et private endpoints émergent du modèle applicatif :

var vnet = builder.AddAzureVirtualNetwork("vnet");

var appSubnet = vnet.AddSubnet("app-subnet");
var dataSubnet = vnet.AddSubnet("data-subnet");

var postgres = builder.AddAzurePostgresFlexibleServer("db")
    .RunAsContainer()
    .WithSubnet(dataSubnet)
    .AddPrivateEndpoint();

var api = builder.AddProject<Projects.Api>("api")
    .WithSubnet(appSubnet)
    .WithReference(postgres);

Aspire génère automatiquement la configuration de zone DNS pour les private endpoints, de sorte que les services puissent communiquer via leurs noms Aspire même lorsqu'ils résident dans des subnets isolés. Les NAT gateways et network security groups sont configurables via des méthodes raccourcies au niveau du subnet :

vnet.AddSubnet("app-subnet")
    .WithNatGateway()
    .WithNsg(nsg => nsg
        .DenyAllInbound()
        .AllowInboundFrom(appSubnet));

Important : toutes les APIs VNet restent marquées [Experimental("ASPIREAZURE003")]. Vous pouvez utiliser un warning suppressor dans le projet pour l'accepter explicitement, à vos risques et périls :

#pragma warning disable ASPIREAZURE003
var vnet = builder.AddAzureVirtualNetwork("vnet");
#pragma warning restore ASPIREAZURE003

Piège connu : Azure SQL Server + private endpoints. Lorsque AddPrivateEndpoint est défini sur un SQL Server, Aspire désactive l'accès réseau public. Mais Aspire doit aussi exécuter un script de déploiement, Azure PowerShell, qui se connecte au SQL Server pour attribuer des rôles à une managed identity. Ce conteneur de script tourne hors du VNet et ne peut alors plus atteindre le SQL Server.

Jusqu'à 13.1, cela provoquait une erreur DeploymentFailed sans logs explicatifs. Aspire 13.2 résout ce problème en intégrant le conteneur de script de déploiement dans le VNet et en provisionnant automatiquement un storage account nécessaire comme file share pour ce conteneur. Cela se produit de façon transparente, mais ajoute un storage account Azure provisionné par déploiement (microsoft/aspire#14421). Toute personne déployant SQL Server avec private endpoints sur Aspire 13.1 ou plus ancien rencontrera cette erreur de manière reproductible.

Network Security Perimeters

À partir d'Aspire 13.3, les Azure Network Security Perimeters sont intégrables, un concept qui permet de regrouper plusieurs ressources Azure, storage accounts, Service Bus, Key Vault, sous un périmètre réseau partagé imposant des règles d'accès uniformes :

var perimeter = builder.AddAzureNetworkSecurityPerimeter("nsp");

builder.AddAzureStorage("storage")
    .WithNetworkSecurityPerimeter(perimeter);

builder.AddAzureServiceBus("bus")
    .WithNetworkSecurityPerimeter(perimeter);

Le trafic entre ressources d'un même périmètre est autorisé sans configuration explicite ; les accès externes sont gérés de manière centralisée.

Azure Front Door

Pour les déploiements distribués mondialement, Azure Front Door est modélisable directement dans l'AppHost à partir de 13.3 :

var frontDoor = builder.AddAzureFrontDoor("cdn");

builder.AddProject<Projects.Api>("api")
    .WithExternalHttpEndpoints()
    .WithAzureFrontDoor(frontDoor, route => route
        .WithPath("/api/*")
        .WithCaching());

builder.AddProject<Projects.Frontend>("frontend")
    .WithExternalHttpEndpoints()
    .WithAzureFrontDoor(frontDoor, route => route
        .WithPath("/*"));

Aspire provisionne le profil Front Door, les origins et les règles de routage dans le flux normal de aspire deploy. La configuration du cache, les politiques WAF et les health probes sont configurables directement sur la route.

Prudence lors d'une mise à niveau vers 13.4 : les conventions de nommage Front Door ont changé entre 13.3 et 13.4 d'une manière qui peut créer des doublons de noms de ressources dans des déploiements existants. Les ressources Front Door existantes doivent être relues manuellement avant la montée de version.

Charts Helm externes comme étapes de déploiement

Pour les déploiements Kubernetes en environnement d'entreprise, il existe souvent déjà une infrastructure : ingress controller, secrets manager, monitoring stack. Aspire 13.4 permet de les inclure comme étapes de chart Helm dans le pipeline de déploiement :

builder.AddHelmChart("cert-manager", "cert-manager/cert-manager", "v1.16.0",
    values => values.Set("installCRDs", true));

builder.AddHelmChart("prometheus", "prometheus-community/kube-prometheus-stack", "65.1.0");

Ces charts sont installés dans aspire deploy, avec le même ordonnancement de dépendances que les ressources natives Aspire. aspire destroy exécute helm uninstall pour tous les charts enregistrés.

Managed identities par service

Introduit dès Aspire 9.x, mais important ici : chaque Azure Container App reçoit une managed identity dédiée depuis Aspire 9.3. En environnement d'entreprise, c'est le fondement d'une gestion fine des accès : au lieu d'une identité partagée avec un large périmètre de droits, chaque service reçoit exactement les permissions dont il a besoin. Aspire génère automatiquement les role assignments correspondants au moment du déploiement.

Aspire 13 pour l'entreprise : réseau, registre et sécurité