Personnaliser des chaînes de connexion en utilisant des manifestes .NET Aspire

7 minutes

Les outils de déploiement tels que Visual Studio ou l’interface Azure Developer CLI créent des fichiers manifeste qui décrivent le contenu d’une solution .NET Aspire. Si vous souhaitez personnaliser votre déploiement, vous pouvez directement apporter des modifications au fichier manifeste.

Dans votre revendeur d’équipements de plein air, vous avez décidé d’utiliser une instance Azure Cache pour Redis existante pour héberger le cache de sortie pour votre microservice d’application web. Vous souhaitez vérifier que le service d’application web se connecte à l’instance appropriée d’Azure Cache pour Redis.

Dans cette unité, vous allez découvrir comment modifier des chaînes de connexion aux services de stockage dans le fichier manifeste .NET Aspire.

Générer un fichier manifeste en utilisant l’interface CLI .NET

Pendant le débogage et le développement locaux, .NET Aspire ne crée aucun fichier manifeste. Lorsqu’il s’agit d’un déploiement, .NET doit décrire le contenu de la solution .NET Aspire, notamment ses microservices, services de stockage et configuration. Le fichier manifeste répond à ce besoin. Il décrit la solution au format JSON.

Pour créer le fichier manifeste, Visual Studio et le produit Azure Developer CLI exécute une commande run .NET CLI avec une cible spécifique. Vous pouvez exécuter manuellement la même commande pour créer votre fichier manifeste comme suit :

dotnet run --project eShop.AppHost\eShop.AppHost.csproj `
    --publisher manifest `
    --output-path ../aspire-manifest.json

Remarque

Veillez à spécifier le projet d’hôte d’application avec l’option --project.

La commande génère une sortie similaire à ce texte :

Building...
info: Aspire.Hosting.DistributedApplication[0]
      Aspire version: 8.0.1+a6e341ebbf956bbcec0dda304109815fcbae70c9
info: Aspire.Hosting.Publishing.ManifestPublisher[0]
      Published manifest to: C:\repos\eShop\aspire-manifest.json

Vous pouvez également utiliser un profil de lancement pour exécuter la commande dotnet. Un profil de lancement est un groupe de paramètres qui configurent un projet .NET lors de son exécution. Par exemple, le modèle Démarrage .NET Aspire crée ces profils de lancement :

"profiles": {
  "https": {
    "commandName": "Project",
    "dotnetRunMessages": true,
    "launchBrowser": true,
    "applicationUrl": "https://localhost:17170;http://localhost:15281",
    "environmentVariables": {
      "ASPNETCORE_ENVIRONMENT": "Development",
      "DOTNET_ENVIRONMENT": "Development",
      "DOTNET_DASHBOARD_OTLP_ENDPOINT_URL": "https://localhost:21147",
      "DOTNET_RESOURCE_SERVICE_ENDPOINT_URL": "https://localhost:22239"
    }
  },
  "http": {
    "commandName": "Project",
    "dotnetRunMessages": true,
    "launchBrowser": true,
    "applicationUrl": "http://localhost:15281",
    "environmentVariables": {
      "ASPNETCORE_ENVIRONMENT": "Development",
      "DOTNET_ENVIRONMENT": "Development",
      "DOTNET_DASHBOARD_OTLP_ENDPOINT_URL": "http://localhost:19197",
      "DOTNET_RESOURCE_SERVICE_ENDPOINT_URL": "http://localhost:20233"
    }
  }
}

Ajoutez un profil de lancement pour créer un fichier manifeste avec un code JSON similaire à ce texte :

"profiles": {
  "generate-manifest": {
    "commandName": "Project",
    "launchBrowser": false,
    "dotnetRunMessages": true,
    "commandLineArgs": "--publisher manifest --output-path aspire-manifest.json"
  }
}

Dans Visual Studio, vous pouvez ensuite choisir le profil generate-manifest quand vous commencez le débogage. Sur la ligne de commande, utilisez l’option --launch-profile :

dotnet run --launch-profile generate-manifest

Format du fichier manifeste

Le manifeste est un fichier JSON avec un seul élément de niveau supérieur nommé resources. Au sein de cet objet, vous trouvez un objet pour chaque microservice et service de stockage. Pour chacun de ces objets, les paramètres incluent des chaînes de connexion, des variables d’environnement et des noms d’image conteneur.

Voici un exemple de manifeste pour le modèle Démarrage .NET Aspire sans aucune modification. La solution utilise un cache Redis :

{
  "resources": {
    "cache": {
      "type": "container.v0",
      "connectionString": "{cache.bindings.tcp.host}:{cache.bindings.tcp.port}",
      "image": "docker.io/library/redis:7.2",
      "bindings": {
        "tcp": {
          "scheme": "tcp",
          "protocol": "tcp",
          "transport": "tcp",
          "targetPort": 6379
        }
      }
    },
    "apiservice": {
      "type": "project.v0",
      "path": "AspireStarter.ApiService/AspireStarter.ApiService.csproj",
      "env": {
        "OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EXCEPTION_LOG_ATTRIBUTES": "true",
        "OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EVENT_LOG_ATTRIBUTES": "true",
        "OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY": "in_memory",
        "ASPNETCORE_FORWARDEDHEADERS_ENABLED": "true"
      },
      "bindings": {
        "http": {
          "scheme": "http",
          "protocol": "tcp",
          "transport": "http"
        },
        "https": {
          "scheme": "https",
          "protocol": "tcp",
          "transport": "http"
        }
      }
    },
    "webfrontend": {
      "type": "project.v0",
      "path": "AspireStarter.Web/AspireStarter.Web.csproj",
      "env": {
        "OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EXCEPTION_LOG_ATTRIBUTES": "true",
        "OTEL_DOTNET_EXPERIMENTAL_OTLP_EMIT_EVENT_LOG_ATTRIBUTES": "true",
        "OTEL_DOTNET_EXPERIMENTAL_OTLP_RETRY": "in_memory",
        "ASPNETCORE_FORWARDEDHEADERS_ENABLED": "true",
        "ConnectionStrings__cache": "{cache.connectionString}",
        "services__apiservice__http__0": "{apiservice.bindings.http.url}",
        "services__apiservice__https__0": "{apiservice.bindings.https.url}"
      },
      "bindings": {
        "http": {
          "scheme": "http",
          "protocol": "tcp",
          "transport": "http",
          "external": true
        },
        "https": {
          "scheme": "https",
          "protocol": "tcp",
          "transport": "http",
          "external": true
        }
      }
    }
  }
}

Chaînes de connexion et références de liaison

Dans l’exemple de manifeste, il existe trois ressources :

webfrontend : Cette ressource est le microservice présentant une interface web aux clients.
apiservice : Cette ressource est l’API REST que webfrontend appelle. Dans le modèle, cet appel est destiné à obtenir des données météorologiques.
cache : Cette ressource est le cache Redis utilisé pour optimiser les performances du microservice webfrontend.

Notez que chacune des trois ressources inclut une section bindings qui spécifie des protocoles que vous pouvez utiliser pour vous connecter à cette ressource.

Dans le fichier Program.cs de l’hôte d’application, le projet webfrontend dépend du cache et du apiservice :

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

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

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

Dans le fichier manifeste, ces dépendances sont exprimées comme variables d’environnement :

"env": {
  "ConnectionStrings__cache": "{cache.connectionString}",
  "services__apiservice__http__0": "{apiservice.bindings.http.url}",
  "services__apiservice__https__0": "{apiservice.bindings.https.url}"
}

Les dépendances utilisent des chaînes d’espace réservé qui font référence à la structure du fichier manifeste. Par exemple, la troisième dépendance fait référence à la liaison HTTPS du service d’API :

En savoir plus

Continuer

Personnaliser des chaînes de connexion en utilisant des manifestes .NET Aspire

Générer un fichier manifeste en utilisant l’interface CLI .NET

Format du fichier manifeste

Chaînes de connexion et références de liaison

En savoir plus

Commentaires