.NET .NET Aspire översikt över nätverk i inre loopar

En av fördelarna med att utveckla med .NET.NET Aspire är att du kan utveckla, testa och felsöka molnbaserade appar lokalt. Nätverk med inre loopar är en viktig aspekt av .NET.NET Aspire som gör att dina appar kan kommunicera med varandra i utvecklingsmiljön. I den här artikeln får du lära dig hur .NET.NET Aspire hanterar olika nätverksscenarier med proxyservrar, slutpunkter, slutpunktskonfigurationer och startprofiler.

Nätverk i den inre slingan

Den inre loopen är processen att utveckla och testa din app lokalt innan du distribuerar den till en målmiljö. .NET .NET Aspire innehåller flera verktyg och funktioner för att förenkla och förbättra nätverksupplevelsen i den inre loopen, till exempel:

• Starta profiler: Startprofiler är konfigurationsfiler som anger hur appen ska köras lokalt. Du kan använda startprofiler (till exempel launchSettings.json fil) för att definiera slutpunkter, miljövariabler och starta inställningar för din app.
• Kestrel-konfiguration: Med Kestrel-konfigurationen kan du ange de slutpunkter som Kestrel-webben server lyssnar på. Du kan konfigurera Kestrel-slutpunkter i appinställningarna och .NET.NET Aspire automatiskt använder de här inställningarna för att skapa slutpunkter.
• slutpunkter/slutpunktskonfigurationer: Slutpunkter är anslutningarna mellan din app och de tjänster som den är beroende av, till exempel databaser, meddelandeköer eller API:er. Slutpunkter innehåller information som tjänstnamn, värdport, schema och miljövariabel. Du kan lägga till slutpunkter i appen antingen implicit (via startprofiler) eller explicit genom att anropa WithEndpoint.
• Proxyservrar: .NET.NET Aspire startar automatiskt en proxy för varje tjänstbindning som du lägger till i din app och tilldelar en port som proxyn ska lyssna på. Proxyn vidarebefordrar sedan begäranden till porten som appen lyssnar på, vilket kan skilja sig från proxyporten. På så sätt kan du undvika portkonflikter och komma åt din app och dina tjänster med hjälp av konsekventa och förutsägbara URL:er.

Så här fungerar slutpunkter

En tjänstbindning i .NET.NET Aspire omfattar två integreringar: en tjänst som representerar en extern resurs som din app kräver (till exempel en databas, meddelandekö eller API) och en bindning som upprättar en anslutning mellan din app och tjänsten och tillhandahåller nödvändig information.

.NET .NET Aspire stöder två tjänstbindningstyper: implicit, skapas automatiskt baserat på angivna startprofiler som definierar appbeteende i olika miljöer och explicit, som skapas manuellt med hjälp av WithEndpoint.

När du skapar en bindning, oavsett om den är implicit eller explicit, startar .NET.NET Aspire en enkel omvänd proxy på en angiven port, hanterar routning och belastningsutjämning för begäranden från din app till tjänsten. Proxyn är en .NET.NET Aspire implementeringsdetalj som inte kräver någon konfiguration eller hantering.

För att visualisera hur slutpunkter fungerar, tänk på .NET.NET Aspire startmallarnas diagram för nätverk i intern slinga.

Starta profiler

När du anropar AddProjectletar programvärden efter Properties/launchSettings.json för att fastställa standarduppsättningen av slutpunkter. Appvärden väljer en specifik startprofil med hjälp av följande regler:

1. Ett tydligt launchProfileName-argument skickades när AddProjectanropades.
2. Miljövariabeln DOTNET_LAUNCH_PROFILE. Mer information finns i .NET miljövariabler.
3. Den första startprofilen som definierats i launchSettings.json.

Överväg följande launchSettings.json fil:

{
  "$schema": "http://json.schemastore.org/launchsettings.json",
  "profiles": {
    "http": {
      "commandName": "Project",
      "dotnetRunMessages": true,
      "launchBrowser": false,
      "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },
    "https": {
      "commandName": "Project",
      "dotnetRunMessages": true,
      "launchBrowser": true,
      "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}",
      "applicationUrl": "https://localhost:7239;http://localhost:5066",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    }
  }
}

För resten av den här artikeln kan du anta att du har skapat en IDistributedApplicationBuilder tilldelad till en variabel med namnet builder med CreateBuilder() API:

var builder = DistributedApplication.CreateBuilder(args);

Om du vill ange http och https starta profiler konfigurerar du applicationUrl-värdena för båda i launchSettings.json fil. Dessa URL:er används för att skapa slutpunkter för det här projektet. Detta motsvarar:

builder.AddProject<Projects.Networking_Frontend>("frontend")
       .WithHttpEndpoint(port: 5066)
       .WithHttpsEndpoint(port: 7239);

Viktig

Om det inte finns någon startinställningar.json (eller startprofil) finns det inga standardbindningar.

För mer information, se .NET.NET Aspire och startprofiler.

Slutpunkter konfigurerade av Kestrel

.NET .NET Aspire stöder Kestrel-slutpunktskonfiguration. Överväg till exempel en appsettings-fil.json fil för ett projekt som definierar en Kestrel-endpoint med HTTPS-schemat och port 5271.

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "Kestrel": {
    "Endpoints": {
      "Https": {
        "Url": "https://*:5271"
      }
    }
  }
}

Föregående konfiguration anger en Https slutpunkt. Egenskapen Url är inställd på https://*:5271, vilket innebär att slutpunkten lyssnar på alla gränssnitt på port 5271. För mer information, se Konfigurera slutpunkter för ASP.NET Core Kestrel-webbserver server.

Med Kestrel-slutpunkten konfigurerad bör projektet ta bort alla konfigurerade applicationUrl från launchSettings.json fil.

Not

Om applicationUrl finns i launchSettings.json fil och Kestrel-slutpunkten har konfigurerats utlöser appvärden ett undantag.

När du lägger till en projektresurs finns det en överlagring som gör att du kan ange att Kestrel-slutpunkten ska användas i stället för launchSettings.json fil:

builder.AddProject<Projects.Networking_ApiService>(
    name: "apiservice",
    configure: static project =>
    {
        project.ExcludeLaunchProfile = true;
        project.ExcludeKestrelEndpoints = false;
    })
    .WithHttpsEndpoint();

Mer information finns i AddProject.

Portar och proxyservrar

När du definierar en tjänstbindning är värdporten alltid ges till proxyn som finns framför tjänsten. På så sätt kan en eller flera repliker av en tjänst bete sig på samma sätt. Dessutom förlitar sig alla resursberoenden som använder WithReference API för proxyslutpunkten från miljövariabeln.

Överväg följande metodkedja som anropar AddProject, WithHttpEndpointoch sedan WithReplicas:

builder.AddProject<Projects.Networking_Frontend>("frontend")
       .WithHttpEndpoint(port: 5066)
       .WithReplicas(2);

Föregående kod resulterar i följande nätverksdiagram:

Föregående diagram visar följande:

• En webbläsare som en startpunkt för appen.
• En värdport på 5066.
• Klientdelsproxyn som sitter mellan webbläsaren och klientdelstjänstreplikerna och lyssnar på port 5066.
• Den frontend_0-klientdelstjänstreplika som lyssnar på det slumpmässigt tilldelade porten 65001.
• Frontendtjänstrepliken frontend_1 som lyssnar på den slumpmässigt tilldelade porten 65002.

Utan anropet till WithReplicasfinns det bara en klientdelstjänst. Proxyn lyssnar fortfarande på port 5066, men klientdelstjänsten lyssnar på en slumpmässig port:

builder.AddProject<Projects.Networking_Frontend>("frontend")
       .WithHttpEndpoint(port: 5066);

Det finns två definierade portar:

• En värdport på 5066.
• En slumpmässig proxyport som den underliggande tjänsten är bunden till.

Föregående diagram visar följande:

• En webbläsare som en startpunkt för appen.
• En värdport på 5066.
• Klientdelsproxyn sitter mellan webbläsaren och klientdelstjänsten och lyssnar på port 5066.
• Frontend-tjänsten lyssnar på en slumpmässig port, såsom 65001.

Den underliggande tjänsten matas denna port genom ASPNETCORE_URLS för projektresurser. Andra resurser har åtkomst till den här porten genom att ange en miljövariabel för tjänstbindningen:

builder.AddNpmApp("frontend", "../NodeFrontend", "watch")
       .WithHttpEndpoint(port: 5067, env: "PORT");

Den tidigare koden gör den slumpmässiga porten tillgänglig i miljövariabeln PORT. Appen använder den här porten för att lyssna på inkommande anslutningar från proxyn. Tänk på följande diagram:

Föregående diagram visar följande:

• En webbläsare som en startpunkt för appen.
• En värdport på 5067.
• Klientdelsproxyn sitter mellan webbläsaren och klientdelstjänsten och lyssnar på port 5067.
• Frontend-tjänsten övervakar port 65001.

Tips

För att undvika att en slutpunkt proxieras, ange egenskapen IsProxied till false när du anropar metoden WithEndpoint-tillägg. För mer information, se Slutpunktstillägg: ytterligare överväganden.

Utelämna värdporten

När du utelämnar värdporten genererar .NET.NET Aspire en slumpmässig port för både värd- och tjänstporten. Detta är användbart när du vill undvika portkonflikter och inte bryr dig om värd- eller tjänstporten. Överväg följande kod:

builder.AddProject<Projects.Networking_Frontend>("frontend")
       .WithHttpEndpoint();

I det här scenariot är både värd- och tjänstportarna slumpmässiga, vilket visas i följande diagram:

Föregående diagram visar följande:

• En webbläsare som en startpunkt för appen.
• En slumpmässig värdport på 65000.
• Klientdelsproxyn sitter mellan webbläsaren och klientdelstjänsten och lyssnar på port 65000.
• Klientdelstjänsten lyssnar på en slumpmässig port på 65001.

Containerportar

När du lägger till en containerresurs tilldelar .NET.NET Aspire automatiskt en slumpmässig port till containern. Om du vill ange en containerport konfigurerar du containerresursen med önskad port:

builder.AddContainer("frontend", "mcr.microsoft.com/dotnet/samples", "aspnetapp")
       .WithHttpEndpoint(port: 8000, targetPort: 8080);

Föregående kod:

• Skapar en containerresurs med namnet frontendfrån avbildningen mcr.microsoft.com/dotnet/samples:aspnetapp.
• Exponerar en http-slutpunkt genom att binda värd till port 8000 och mappa den till containerns port 8080.

Tänk på följande diagram:

Metoder för slutpunktsutökning

Alla resurser som implementerar IResourceWithEndpoints-gränssnittet kan använda WithEndpoint tilläggsmetoder. Det finns flera överbelastningar av det här tillägget, vilket låter dig specificera schemat, containerporten, värdporten, namnet på miljövariabeln och om slutpunkten går via en proxy.

Det finns också en överlagring som gör att du kan ange ett ombud för att konfigurera slutpunkten. Detta är användbart när du behöver konfigurera slutpunkten baserat på miljön eller andra faktorer. Överväg följande kod:

builder.AddProject<Projects.Networking_ApiService>("apiService")
       .WithEndpoint(
            endpointName: "admin",
            callback: static endpoint =>
       {
           endpoint.Port = 17003;
           endpoint.UriScheme = "http";
           endpoint.Transport = "http";
       });

Föregående kod innehåller ett återanropsdelegat för att konfigurera slutpunkten. Slutpunkten heter admin och är konfigurerad för att använda http-schemat och transporten, samt port 17003. Konsumenten refererar till den här slutpunkten efter namn, tänk på följande AddHttpClient anrop:

builder.Services.AddHttpClient<WeatherApiClient>(
    client => client.BaseAddress = new Uri("http://_admin.apiservice"));

Uri skapas med hjälp av det admin slutpunktsnamnet som prefixet med _ sentinel. Det här är en konvention som anger att admin-segmentet är slutpunktsnamnet som tillhör apiservice-tjänsten. För mer information, se .NET.NET Aspire tjänstupptäckt.

Ytterligare överväganden

När du anropar WithEndpoint-tilläggsmetoden exponerar callback överlagring rå-EndpointAnnotation, vilket gör att konsumenten kan anpassa många aspekter av slutpunkten.

Med egenskapen AllocatedEndpoint kan du hämta eller ange slutpunkten för en tjänst. Egenskaperna IsExternal och IsProxied avgör hur slutpunkten hanteras och exponeras: IsExternal avgör om den ska vara offentligt tillgänglig, medan IsProxied säkerställer att DCP hanterar den, vilket möjliggör interna portskillnader och replikering.

Tips

Om du är värd för en extern körbar fil som kör en egen proxy och stöter på problem med portbindning på grund av att DCP redan binder porten kan du prova att ange egenskapen IsProxied till false. Detta hindrar DCP från att hantera proxyn, vilket gör att din körbara fil kan binda porten framgångsrikt.

Egenskapen Name identifierar tjänsten, medan egenskaperna Port och TargetPort anger önskade respektive lyssnande portar.

För nätverkskommunikation stöder egenskapen ProtocolTCP och UDP, med potential för mer i framtiden, och egenskapen Transport anger transportprotokollet (HTTP, HTTP2, HTTP3). Om tjänsten slutligen är URI-adresserbar tillhandahåller egenskapen UriScheme URI-schemat för att konstruera tjänstens URI.

För mer information, se de tillgängliga egenskaperna hos EndpointAnnotation-egenskaperna.

Slutpunktsfiltrering

Alla .NET.NET Aspire projektresursslutpunkter följer en uppsättning standard-heuristik. Vissa slutpunkter ingår i ASPNETCORE_URLS vid körning, vissa publiceras som HTTP/HTTPS_PORTS, och vissa konfigurationer hämtas från Kestrel-konfigurationen. Oavsett standardbeteende kan du filtrera slutpunkterna som ingår i miljövariabler med hjälp av WithEndpointsInEnvironment tilläggsmetod:

builder.AddProject<Projects.Networking_ApiService>("apiservice")
    .WithHttpsEndpoint() // Adds a default "https" endpoint
    .WithHttpsEndpoint(port: 19227, name: "admin")
    .WithEndpointsInEnvironment(
        filter: static endpoint =>
        {
            return endpoint.Name is not "admin";
        });

Föregående kod lägger till en HTTPS-standardslutpunkt samt en admin slutpunkt på port 19227. Den admin slutpunkten undantas dock från miljövariablerna. Detta är användbart när du endast vill exponera en slutpunkt för internt bruk.