Partager via

Vue d’ensemble de l’orchestration .NET.NET Aspire

  • Article

.NET .NET Aspire fournit des API pour exprimer des ressources et des dépendances au sein de votre application distribuée. En plus de ces API, il existe des outils qui permettent plusieurs scénarios attrayants. L’orchestrateur est destiné à des de développement local et n’est pas pris en charge dans les environnements de production.

Avant de continuer, tenez compte de certaines terminologies courantes utilisées dans .NET.NET Aspire:

  • modèle d’application: collection de ressources qui composent votre application distribuée (DistributedApplication), définie dans l’espace de noms Aspire.Hosting.ApplicationModel. Pour obtenir une définition plus formelle, consultez Définir le modèle d’application.
  • projet hôte/orchestrateurd'application : le projet .NET qui orchestre le modèle d'application , nommé avec le suffixe *.AppHost (par convention).
  • Ressource: Une ressource est une partie dépendante d’une application, telle qu’un .NET projet, un conteneur, un exécutable, une base de données, un cache ou un service cloud. Il représente toute partie de l’application qui peut être gérée ou référencée.
  • d’intégration : une intégration est un package NuGet pour l’hôte d’application qui modélise une ressource ou un package qui configure un client à utiliser dans une application consommatrice. Pour plus d’informations, consultez .NET.NET Aspire vue d’ensemble des intégrations.
  • référence: une référence définit une connexion entre les ressources, exprimée en tant que dépendance à l’aide de l’API WithReference. Pour plus d’informations, consultez Ressources de référence ou Référencer les ressources existantes.

Note

L'orchestration de .NET.NET Aspireest conçue pour améliorer votre expérience de développement local en simplifiant la gestion de la configuration et des liaisons de votre application cloud natif. Bien qu’il s’agit d’un outil précieux pour le développement, il n’est pas destiné à remplacer les systèmes d’environnement de production comme Kubernetes, qui sont spécifiquement conçus pour exceller dans ce contexte.

Définir le modèle d’application

.NET .NET Aspire vous permet de créer, provisionner, déployer, configurer, tester, exécuter et observer vos applications distribuées en toute transparence. Toutes ces fonctionnalités sont obtenues grâce à l’utilisation d’un modèle d’application qui décrit les ressources de votre solution .NET.NET Aspire et leurs relations. Ces ressources englobent des projets, des exécutables, des conteneurs et des services externes et des ressources cloud dont dépend votre application. Dans chaque solution .NET.NET Aspire, il existe un projet hôte d’application désigné, où le modèle d’application est défini avec précision à l’aide de méthodes disponibles sur le IDistributedApplicationBuilder. Ce générateur est obtenu en appelant DistributedApplication.CreateBuilder.

// Create a new app model builder
var builder = DistributedApplication.CreateBuilder(args);

// TODO:
//   Add resources to the app model
//   Express dependencies between resources

builder.Build().Run();

Projet hôte d’application

Le projet hôte d’application gère l’exécution de tous les projets qui font partie du projet .NET.NET Aspire. En d’autres termes, il est responsable de l’orchestration de toutes les applications au sein du modèle d’application. Le projet est un projet exécutable .NET qui fait référence au package NuGet 📦Aspire.Hosting.AppHost, définit la propriété IsAspireHost sur trueet fait référence au SDK .NET.NET Aspire:

<Project Sdk="Microsoft.NET.Sdk">

    <Sdk Name="Aspire.AppHost.Sdk" Version="9.0.0" />
    
    <PropertyGroup>
        <OutputType>Exe</OutputType>
        <TargetFramework>net9.0</TargetFramework>
        <IsAspireHost>true</IsAspireHost>
        <!-- Omitted for brevity -->
    </PropertyGroup>

    <ItemGroup>
        <PackageReference Include="Aspire.Hosting.AppHost" Version="9.0.0" />
    </ItemGroup>

    <!-- Omitted for brevity -->

</Project>

Le code suivant décrit un hôte d’application Program avec deux références de projet et un cache Redis :

var builder = DistributedApplication.CreateBuilder(args);

var cache = builder.AddRedis("cache");

var apiservice = builder.AddProject<Projects.AspireApp_ApiService>("apiservice");

builder.AddProject<Projects.AspireApp_Web>("webfrontend")
       .WithExternalHttpEndpoints()
       .WithReference(cache)
       .WaitFor(cache)
       .WithReference(apiService)
       .WaitFor(apiService);

builder.Build().Run();

Code précédent :

  • Crée un générateur de modèles d’application à l’aide de la méthode CreateBuilder.
  • Ajoute une ressource Rediscache nommée « cache » à l’aide de la méthode AddRedis.
  • Ajoute une ressource de projet nommée « apiservice » à l’aide de la méthode AddProject.
  • Ajoute une ressource de projet nommée « webfrontend » à l’aide de la méthode AddProject.
    • Spécifie que le projet a des points de terminaison HTTP externes à l’aide de la méthode WithExternalHttpEndpoints.
    • Ajoute une référence à la ressource cache et attend qu’elle soit prête à utiliser les méthodes WithReference et WaitFor.
    • Ajoute une référence à la ressource apiservice et attend qu’elle soit prête à utiliser les méthodes WithReference et WaitFor.
  • Génère et exécute le modèle d’application à l’aide des méthodes Build et Run.

L’exemple de code utilise l'intégration de l'hébergement .NET AspireRedis.

Pour vous aider à visualiser la relation entre le projet hôte d’application et les ressources qu’il décrit, tenez compte du diagramme suivant :

La relation entre les projets dans le modèle d’application de démarrage .NET.NET Aspire.

Chaque ressource doit être nommée de manière unique. Ce diagramme montre chaque ressource et les relations entre elles. La ressource de conteneur est nommée « cache » et les ressources du projet sont nommées « apiservice » et « webfrontend ». Le projet web d'interface fait référence aux projets de cache et d'API. Lorsque vous exprimez des références de cette façon, le projet front-end web dit qu’il dépend de ces deux ressources, le « cache » et « apiservice » respectivement.

Types de ressources intégrés

Les projets .NET.NET Aspire sont constitués d'un ensemble de ressources. Types de ressources de base principaux dans le 📦Aspire. Hosting.AppHost package NuGet sont décrits dans le tableau suivant :

Méthode Type de ressource Description
AddProject ProjectResource Un projet .NET, par exemple, une application web ASP.NET Core.
AddContainer ContainerResource Image conteneur, telle qu’une image Docker.
AddExecutable ExecutableResource Fichier exécutable, tel qu’une application Node.js.
AddParameter ParameterResource Ressource de paramètre qui peut être utilisée pour des paramètres externes express.

Les ressources de projet représentent .NET projets qui font partie du modèle d’application. Lorsque vous ajoutez une référence de projet au projet hôte d’application, le sdk .NET.NET Aspire génère un type dans l’espace de noms Projects pour chaque projet référencé. Pour plus d’informations, consultez .NET.NET Aspire SDK : Références de projet.

Pour ajouter un projet au modèle d’application, utilisez la méthode AddProject :

var builder = DistributedApplication.CreateBuilder(args);

// Adds the project "apiservice" of type "Projects.AspireApp_ApiService".
var apiservice = builder.AddProject<Projects.AspireApp_ApiService>("apiservice");

Les projets peuvent être répliqués et mis à l’échelle en ajoutant plusieurs instances du même projet au modèle d’application. Pour configurer des réplicas, utilisez la méthode WithReplicas :

var builder = DistributedApplication.CreateBuilder(args);

// Adds the project "apiservice" of type "Projects.AspireApp_ApiService".
var apiservice = builder.AddProject<Projects.AspireApp_ApiService>("apiservice")
                        .WithReplicas(3);

Le code précédent ajoute trois réplicas de la ressource de projet « apiservice » au modèle d’application. Pour plus d’informations, consultez .NET.NET Aspire tableau de bord : Réplicas de ressources.

Ressources de référence

Une référence représente une dépendance entre les ressources. Par exemple, vous pouvez probablement imaginer un scénario où un frontend web dépend d’un cache Redis. Considérez l’exemple d’hôte d’application suivant Program code C# :

var builder = DistributedApplication.CreateBuilder(args);

var cache = builder.AddRedis("cache");

builder.AddProject<Projects.AspireApp_Web>("webfrontend")
       .WithReference(cache);

La ressource de projet « webfrontend » utilise WithReference pour ajouter une dépendance à la ressource de conteneur « cache ». Ces dépendances peuvent représenter des chaînes de connexion ou informations de découverte de service. Dans l’exemple précédent, une variable d’environnement est injectée dans la ressource « webfronend » avec le nom ConnectionStrings__cache. Cette variable d’environnement contient une chaîne de connexion qu'webfrontend utilise pour se connecter à Redis via l'intégration .NET AspireRedis, par exemple ConnectionStrings__cache="localhost:62354".

En attente de ressources

Dans certains cas, vous pouvez attendre qu’une ressource soit prête avant de démarrer une autre ressource. Par exemple, vous pouvez attendre qu’une base de données soit prête avant de démarrer une API qui dépend de celle-ci. Pour exprimer cette dépendance, utilisez la méthode WaitFor :

var builder = DistributedApplication.CreateBuilder(args);

var postgres = builder.AddPostgres("postgres");
var postgresdb = postgres.AddDatabase("postgresdb");

builder.AddProject<Projects.AspireApp_ApiService>("apiservice")
       .WithReference(postgresdb)
       .WaitFor(postgresdb);

Dans le code précédent, la ressource de projet « apiservice » attend que la ressource de base de données « postgresdb » entre dans le KnownResourceStates.Running. L’exemple de code montre l'intégration .NET AspirePostgreSQL, mais le même modèle peut être appliqué à d’autres ressources.

D'autres cas peuvent justifier d'attendre qu'une ressource se termine, soit KnownResourceStates.Exited soit KnownResourceStates.Finished, avant le démarrage de la ressource dépendante. Pour attendre qu’une ressource s’exécute jusqu’à la fin, utilisez la méthode WaitForCompletion :

var builder = DistributedApplication.CreateBuilder(args);

var postgres = builder.AddPostgres("postgres");
var postgresdb = postgres.AddDatabase("postgresdb");

var migration = builder.AddProject<Projects.AspireApp_Migration>("migration")
                       .WithReference(postgresdb)
                       .WaitFor(postgresdb);

builder.AddProject<Projects.AspireApp_ApiService>("apiservice")
       .WithReference(postgresdb)
       .WaitForCompletion(migration);

Dans le code précédent, la ressource de projet « apiservice » attend que la ressource de projet « migration » s’exécute jusqu’à la fin avant de commencer. La ressource de projet « migration » est en attente que la ressource de base de données « postgresdb » entre dans le KnownResourceStates.Running. Cela peut être utile dans les scénarios où vous souhaitez exécuter une migration de base de données avant de démarrer le service d’API, par exemple.

API pour l’ajout et l’expression de ressources

.NET .NET Aspire les intégrations d’hébergement et les intégrations client sont fournies en tant que packages NuGet, mais elles servent à des fins différentes. Bien que les intégrations client fournissent client configuration de bibliothèque pour consommer des applications en dehors de l’étendue de l’hôte d’application, intégrations d’hébergement fournir des API pour exprimer des ressources et des dépendances au sein de l’hôte d’application. Pour plus d’informations, consultez .NET.NET Aspire vue d’ensemble des intégrations : responsabilités d’intégration.

Ressources de conteneur Express

Pour exprimer un ContainerResource vous l’ajoutez à une instance de IDistributedApplicationBuilder en appelant la méthode AddContainer :

var builder = DistributedApplication.CreateBuilder(args);

var ollama = builder.AddContainer("ollama", "ollama/ollama")
    .WithBindMount("ollama", "/root/.ollama")
    .WithBindMount("./ollamaconfig", "/usr/config")
    .WithHttpEndpoint(port: 11434, targetPort: 11434, name: "ollama")
    .WithEntrypoint("/usr/config/entrypoint.sh")
    .WithContainerRuntimeArgs("--gpus=all");

Pour plus d’informations, consultez prise en charge du GPU dans Docker Desktop.

Le code précédent ajoute une ressource conteneur nommée « ollama » avec l’image ollama/ollama. La ressource de conteneur est configurée avec plusieurs montages de liaison, un point de terminaison HTTP nommé, un point d'entrée qui se résout vers le script shell Unix, et des arguments d'exécution de conteneur utilisant la méthode WithContainerRuntimeArgs.

Personnaliser les ressources de conteneur

Toutes les sous-classes ContainerResource peuvent être personnalisées pour répondre à vos besoins spécifiques. Cela peut être utile lors de l’utilisation d’une intégration d’hébergement qui modélise une ressource de conteneur, mais nécessite des modifications. Lorsque vous disposez d’un IResourceBuilder<ContainerResource> vous pouvez chaîner des appels à l’une des API disponibles pour modifier la ressource de conteneur. .NET .NET Aspire ressources de conteneur pointent généralement vers des balises épinglées, mais vous pouvez utiliser la balise latest à la place.

Pour vous aider à illustrer cela, imaginez un scénario dans lequel vous utilisez l’intégration .NET AspireRedis. Si l’intégration Redis s’appuie sur la balise 7.4 et que vous souhaitez utiliser la balise latest à la place, vous pouvez chaîner un appel à l’API WithImageTag :

var builder = DistributedApplication.CreateBuilder(args);

var cache = builder.AddRedis("cache")
                   .WithImageTag("latest");

// Instead of using the "7.4" tag, the "cache" 
// container resource now uses the "latest" tag.

Pour plus d’informations et des API supplémentaires disponibles, consultez ContainerResourceBuilderExtensions.

Cycle de vie des ressources de conteneur

Lorsque l’hôte de l’application est exécuté, le ContainerResource est utilisé pour déterminer l’image du conteneur à créer et à démarrer. Sous le capot, .NET Aspire exécute le conteneur à l’aide de l’image conteneur définie en déléguant les appels au runtime de conteneur approprié et conforme à l’OCI, Docker ou Podman. Les commandes suivantes sont utilisées :

Tout d’abord, le conteneur est créé à l’aide de la commande docker container create. Ensuite, le conteneur est démarré à l’aide de la commande docker container start.

Ces commandes sont utilisées au lieu de docker run pour gérer les réseaux de conteneurs, les volumes et les ports attachés. L’appel de ces commandes dans cet ordre permet à n’importe quelle adresse IP (configuration réseau) d’être déjà présente au démarrage initial.

Au-delà des types de ressources de base, ProjectResource, ContainerResourceet ExecutableResource, .NET.NET Aspire fournit des méthodes d’extension pour ajouter des ressources courantes à votre modèle d’application. Pour plus d’informations, consultez intégrations d’hébergement.

Durée de vie des ressources de conteneur

Par défaut, les ressources de conteneur utilisent la durée de vie d'un conteneur de session . Cela signifie que chaque fois que le processus hôte de l’application est démarré, le conteneur est créé et démarré. Lorsque l’hôte de l’application s’arrête, le conteneur est arrêté et supprimé. Les ressources de conteneur peuvent opter pour une durée de vie persistante afin d’éviter les redémarrages inutiles et d’utiliser l’état du conteneur persistant. Pour ce faire, chaînez un appel à l’API ContainerResourceBuilderExtensions.WithLifetime et passez ContainerLifetime.Persistent:

var builder = DistributedApplication.CreateBuilder(args);

var ollama = builder.AddContainer("ollama", "ollama/ollama")
    .WithLifetime(ContainerLifetime.Persistent);

Le code précédent ajoute une ressource conteneur nommée « ollama » avec l’image « ollama/ollama » et une durée de vie persistante.

Références de chaîne de connexion et de point de terminaison

Il est courant d’exprimer des dépendances entre les ressources du projet. Considérez l’exemple de code suivant :

var builder = DistributedApplication.CreateBuilder(args);

var cache = builder.AddRedis("cache");

var apiservice = builder.AddProject<Projects.AspireApp_ApiService>("apiservice");

builder.AddProject<Projects.AspireApp_Web>("webfrontend")
       .WithReference(cache)
       .WithReference(apiservice);

Les références de projet à projet sont gérées différemment des ressources qui ont des chaînes de connexion bien définies. Au lieu d’injecter une chaîne de connexion dans la ressource « webfrontend », les variables d’environnement pour prendre en charge la découverte de service sont injectées.

Méthode Variable d’environnement
WithReference(cache) ConnectionStrings__cache="localhost:62354"
WithReference(apiservice) services__apiservice__http__0="http://localhost:5455"
services__apiservice__https__0="https://localhost:7356"

L’ajout d’une référence au projet « apiservice » entraîne l’ajout de variables d’environnement de découverte de service au serveur frontal. En règle générale, la communication projet-à-projet se produit sur HTTP/gRPC. Pour plus d'informations, consultez le service de découverte .NET.NET Aspire.

Pour obtenir des points de terminaison spécifiques à partir d’un ContainerResource ou d’un ExecutableResource, utilisez l’une des API de point de terminaison suivantes :

Appelez ensuite l’API GetEndpoint pour obtenir le point de terminaison qui peut être utilisé pour référencer le point de terminaison dans la méthode WithReference :

var builder = DistributedApplication.CreateBuilder(args);

var customContainer = builder.AddContainer("myapp", "mycustomcontainer")
                             .WithHttpEndpoint(port: 9043, name: "endpoint");

var endpoint = customContainer.GetEndpoint("endpoint");

var apiservice = builder.AddProject<Projects.AspireApp_ApiService>("apiservice")
                        .WithReference(endpoint);
Méthode Variable d’environnement
WithReference(endpoint) services__myapp__endpoint__0=https://localhost:9043

Le paramètre port est le port sur lequel le conteneur écoute. Pour plus d’informations sur les ports de conteneur, consultez ports de conteneur. Pour plus d’informations sur la découverte de services, consultez .NET Aspire.

Format de variable d’environnement de point de terminaison de service

Dans la section précédente, la méthode WithReference est utilisée pour exprimer des dépendances entre les ressources. Lorsque les points de terminaison de service entraînent l’injection de variables d’environnement dans la ressource dépendante, le format peut ne pas être évident. Cette section fournit des détails sur ce format.

Quand une ressource dépend d’une autre ressource, l’hôte de l’application injecte des variables d’environnement dans la ressource dépendante. Ces variables d’environnement configurent la ressource dépendante pour qu’elle se connecte à la ressource dont elle dépend. Le format des variables d’environnement est spécifique à .NET.NET Aspire et exprime les points de terminaison de service d’une manière compatible avec Service Discovery.

Les noms des variables d’environnement de point de terminaison de service sont précédés de services__ (trait de soulignement double), puis du nom du service, du nom du point de terminaison et enfin de l’index. L’index prend en charge plusieurs points de terminaison pour un seul service, en commençant par 0 pour le premier point de terminaison et l’incrémentation pour chaque point de terminaison.

Tenez compte des exemples de variables d’environnement suivants :

services__apiservice__http__0

La variable d’environnement précédente exprime le premier point de terminaison HTTP pour le service apiservice. La valeur de la variable d’environnement est l’URL du point de terminaison de service. Un point de terminaison nommé peut être exprimé comme suit :

services__apiservice__myendpoint__0

Dans l’exemple précédent, le service apiservice a un point de terminaison nommé appelé myendpoint. La valeur de la variable d’environnement est l’URL du point de terminaison de service.

Référencer les ressources existantes

Certaines situations vous justifient de référencer une ressource existante, peut-être une ressource déployée sur un fournisseur de cloud. Par exemple, vous pouvez référencer une base de données Azure. Dans ce cas, vous devez vous appuyer sur le contexte d’exécution pour déterminer dynamiquement si l’hôte de l’application s’exécute en mode « Exécuter » ou en mode « publier ». Si vous exécutez localement et que vous souhaitez vous appuyer sur une ressource cloud, vous pouvez utiliser la propriété IsRunMode pour ajouter conditionnellement la référence. Vous pouvez choisir de créer plutôt la ressource en mode publication. Certaines intégrations d’hébergement prise en charge de fournir directement une chaîne de connexion, qui peut être utilisée pour référencer une ressource existante.

De même, il peut y avoir des cas d’usage où vous souhaitez intégrer .NET.NET Aspire dans une solution existante. Une approche courante consiste à ajouter le projet hôte d’application .NET.NET Aspire à une solution existante. Dans votre hôte d’application, vous exprimez des dépendances en ajoutant des références de projet à l’hôte de l’application et générer le modèle d’application. Par exemple, un projet peut dépendre d’un autre projet. Ces dépendances sont exprimées à l’aide de la méthode WithReference. Pour plus d’informations, consultez Ajouter .NET Aspire à une application .NET existante.

Cycles de vie de l’hôte d’application

L’hôte d’application .NET.NET Aspire expose plusieurs cycles de vie auxquels vous pouvez vous connecter en implémentant l’interface IDistributedApplicationLifecycleHook. Les méthodes de cycle de vie suivantes sont disponibles :

Commande Méthode Description
1 BeforeStartAsync S’exécute avant le démarrage de l’application distribuée.
2 AfterEndpointsAllocatedAsync S’exécute une fois que l’orchestrateur alloue des points de terminaison pour les ressources dans le modèle d’application.
3 AfterResourcesCreatedAsync S’exécute une fois la ressource créée par l’orchestrateur.

Bien que l’hôte de l’application fournit des hooks de cycle de vie, vous souhaiterez peut-être inscrire des événements personnalisés. Pour plus d’informations, consultez Eventing dans .NET.NET Aspire.

Configurer un point d'entrée de cycle de vie

Pour inscrire un hook de cycle de vie, implémentez l’interface de IDistributedApplicationLifecycleHook et inscrivez le hook auprès de l’hôte de l’application à l’aide de l’API AddLifecycleHook :

using Aspire.Hosting.Lifecycle;
using Microsoft.Extensions.Logging;

var builder = DistributedApplication.CreateBuilder(args);

builder.Services.AddLifecycleHook<LifecycleLogger>();

builder.Build().Run();

internal sealed class LifecycleLogger(ILogger<LifecycleLogger> logger)
    : IDistributedApplicationLifecycleHook
{
    public Task BeforeStartAsync(
        DistributedApplicationModel appModel, CancellationToken cancellationToken = default)
    {
        logger.LogInformation("BeforeStartAsync");
        return Task.CompletedTask;
    }

    public Task AfterEndpointsAllocatedAsync(
        DistributedApplicationModel appModel, CancellationToken cancellationToken = default)
    {
        logger.LogInformation("AfterEndpointsAllocatedAsync");
        return Task.CompletedTask;
    }

    public Task AfterResourcesCreatedAsync(
        DistributedApplicationModel appModel, CancellationToken cancellationToken = default)
    {
        logger.LogInformation("AfterResourcesCreatedAsync");
        return Task.CompletedTask;
    }
}

Code précédent :

  • Implémente l’interface IDistributedApplicationLifecycleHook en tant que LifecycleLogger.
  • Inscrit le point d'ancrage du cycle de vie auprès de l’hôte de l’application à l’aide de l’API AddLifecycleHook.
  • Enregistre un message pour tous les événements.

Lorsque cet hôte d'application est exécuté, le hook (point d'ancrage) du cycle de vie s'exécute pour chaque événement. La sortie suivante est générée :

info: LifecycleLogger[0]
      BeforeStartAsync
info: Aspire.Hosting.DistributedApplication[0]
      Aspire version: 9.0.0
info: Aspire.Hosting.DistributedApplication[0]
      Distributed application starting.
info: Aspire.Hosting.DistributedApplication[0]
      Application host directory is: ..\AspireApp\AspireApp.AppHost
info: LifecycleLogger[0]
      AfterEndpointsAllocatedAsync
info: Aspire.Hosting.DistributedApplication[0]
      Now listening on: https://localhost:17043
info: Aspire.Hosting.DistributedApplication[0]
      Login to the dashboard at https://localhost:17043/login?t=d80f598bc8a64c7ee97328a1cbd55d72
info: LifecycleLogger[0]
      AfterResourcesCreatedAsync
info: Aspire.Hosting.DistributedApplication[0]
      Distributed application started. Press Ctrl+C to shut down.

La méthode recommandée pour se connecter au cycle de vie de l’hôte de l’application consiste à utiliser l’API événementielle. Pour plus d’informations, consultez Eventing dans .NET.NET Aspire.

Contexte d’exécution

Le IDistributedApplicationBuilder expose un contexte d’exécution (DistributedApplicationExecutionContext), qui fournit des informations sur l’exécution actuelle de l’hôte d’application. Ce contexte peut être utilisé pour déterminer si l’hôte de l’application s’exécute en mode « exécuter » ou dans le cadre d’une opération de publication. Tenez compte des propriétés suivantes :

  • IsRunMode: retourne true si l’opération actuelle est en cours d’exécution.
  • IsPublishMode: retourne true si l’opération en cours est une publication.

Ces informations peuvent être utiles lorsque vous souhaitez exécuter du code de manière conditionnelle en fonction de l’opération actuelle. Prenons l’exemple suivant qui illustre l’utilisation de la propriété IsRunMode. Dans ce cas, une méthode d’extension est utilisée pour générer un nom de nœud stable pour RabbitMQ pour les exécutions de développement local.

private static IResourceBuilder<RabbitMQServerResource> RunWithStableNodeName(
    this IResourceBuilder<RabbitMQServerResource> builder)
{
    if (builder.ApplicationBuilder.ExecutionContext.IsRunMode)
    {
        builder.WithEnvironment(context =>
        {
            // Set a stable node name so queue storage is consistent between sessions
            var nodeName = $"{builder.Resource.Name}@localhost";
            context.EnvironmentVariables["RABBITMQ_NODENAME"] = nodeName;
        });
    }

    return builder;
}

Le contexte d’exécution est souvent utilisé pour ajouter conditionnellement des ressources ou des chaînes de connexion qui pointent vers des ressources existantes. Prenons l’exemple suivant qui illustre l’ajout conditionnel de Redis ou d’une chaîne de connexion en fonction du contexte d’exécution :

var builder = DistributedApplication.CreateBuilder(args);

var redis = builder.ExecutionContext.IsRunMode
    ? builder.AddRedis("redis")
    : builder.AddConnectionString("redis");

builder.AddProject<Projects.WebApplication>("api")
       .WithReference(redis);

builder.Build().Run();

Dans le code précédent :

  • Si l’hôte de l’application s’exécute en mode « Exécuter », une ressource de conteneur Redis est ajoutée.
  • Si l’hôte de l’application s’exécute en mode « publier », une chaîne de connexion est ajoutée.

Cette logique peut facilement être inversée pour se connecter à une ressource Redis existante lorsque vous exécutez localement et créer une ressource Redis lors de la publication.

Important

.NET .NET Aspire fournit des API courantes pour contrôler la modalité des générateurs de ressources, ce qui permet aux ressources de se comporter différemment en fonction du mode d’exécution. Les API Fluent sont précédées de RunAs* et de PublishAs*. Les API RunAs* influencent le comportement de développement local (ou mode d’exécution), tandis que les API PublishAs* influencent la publication de la ressource.

Voir aussi